Recent

Author Topic: Wish: stop the race after Delphi  (Read 2638 times)

funlw65

  • New Member
  • *
  • Posts: 47
    • Visual Pin Configurator for Nucleo-L152RE
Re: Wish: stop the race after Delphi
« Reply #45 on: January 05, 2021, 08:13:10 pm »
Read the topic and you will see that others accepted that is not from me. No dynamic memory allocations from my part. I use the objects as they are, transferring the values to global variables then writing the C files and other types of text files.

"Up to a point, Lord Copper".

From what I've seen you've provided some of the info, but are still being asked for details. However I think your comments about it depending on the widget set and apparently happening on multiple distreaux etc. are interesting.

MarkMLl

I don't know if this is what you requested, I run the app with following parameters:
valgrind --tool=memcheck --num-callers=50 --track-origins=yes --leak-check=full --log-file=vpc_val.txt ./vpc

Not yet a crash, only vertical labels trimmed at first two chars in one of the dialogs (the only where I have those vertical labels)...

funlw65

  • New Member
  • *
  • Posts: 47
    • Visual Pin Configurator for Nucleo-L152RE
Re: Wish: stop the race after Delphi
« Reply #46 on: January 06, 2021, 07:14:50 am »
BTW, that last crash is Lazarus crash, in designer mode...
Can you please provide a debugger backtrace preferably using Lazarus trunk.
Get trunk sources from SVN server or Git mirror on Linux. First time build with "make".
Then in Tools -> Configure build Lazarus ... select profile "Debug IDE". It has all the needed flags for debugging and checking.
Build. Your selection of packages is remembered if you use the same configuration as before.
No installation is needed. Start if from the same location under gdb.
 $ gdb ./lazarus
When it crashes, type "bt" for backtrace.
A backtrace from your application crash would be helpful, too. Then all libraries (LCL, LazUtils etc.) must have debug info. The above process includes that.

The form designer in Lazarus trunk got optimized and improved a little. However I didn't know of any crashes even before that.
QT5 has occasional problem with ToolButton's Hint. If you can reproduce it with a backtrace, good.

Quote
No code executed from my project. In the same area it crashes my app.
What area?
Do I understand right that you have only tested with Lazarus release versions without debug info so far?
As nobody can reproduce, you should help in debugging.

Juha, I did your steps and I will continue to use it like this, doesn't slow my computer. Once I get a crash, I'll report as is firstly my interest. It is a new IDE version, hopefully better. 

funlw65

  • New Member
  • *
  • Posts: 47
    • Visual Pin Configurator for Nucleo-L152RE
Re: Wish: stop the race after Delphi
« Reply #47 on: January 06, 2021, 05:36:41 pm »
Quote
What area?
Do I understand right that you have only tested with Lazarus release versions without debug info so far?
As nobody can reproduce, you should help in debugging.

Oh, I was talking about the Lazarus crashing when hovering with the mouse over the toolbutton area. In the same area I get the crash on my app - hovering with the mouse over those speedbuttons from the toolbutton.

Yes, Lazarus 2.0.10, with no debug info, I guess... Do you mean, continue to run the 2,0,10 version with debug info? Using the 2.0.10 sources from Sourceforge to compile it with debug info? Or is enough to use 2.1.0 as I do now?

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 6823
  • Debugger - SynEdit - and more
    • wiki
Re: Wish: stop the race after Delphi
« Reply #48 on: January 06, 2021, 06:17:51 pm »
I don't know if this is what you requested, I run the app with following parameters:
valgrind --tool=memcheck --num-callers=50 --track-origins=yes --leak-check=full --log-file=vpc_val.txt ./vpc

Not yet a crash, only vertical labels trimmed at first two chars in one of the dialogs (the only where I have those vertical labels)...

I was interested in it, to see if the "is ... bytes inside a block of size ... free'd"  could be traced.
Unfortunately it did not occur in your latest run.

It's not super important, since it is not even clear if it would lead to anything....
So it depends if you have the time to spend, running valgrind until the message appears in the log. (the message can appear with or without the crash happening)

JuhaManninen

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3939
  • I like bugs.
Re: Wish: stop the race after Delphi
« Reply #49 on: January 07, 2021, 05:15:01 pm »
Oh, I was talking about the Lazarus crashing when hovering with the mouse over the toolbutton area. In the same area I get the crash on my app - hovering with the mouse over those speedbuttons from the toolbutton.
It could be the LCL-QT5 SpeedButton Hint problem I have seen. It would be nice to reproduce it properly.

Quote
Yes, Lazarus 2.0.10, with no debug info, I guess... Do you mean, continue to run the 2,0,10 version with debug info? Using the 2.0.10 sources from Sourceforge to compile it with debug info? Or is enough to use 2.1.0 as I do now?
Trunk 2.1.0 is perfect! Actually all changes happen in trunk. If a bug cannot be reproduced in trunk, it will not be fixed.
Trunk is already way ahead of  2.0.x. Soon a branch for 2.2 will be forked.

GDB is the right tool when tracing crashes. It does not slow down the execution much. When a crash happens without GDB and you have debug info included, a kind of backtrace is shown in console but it is limited. It has no parameter info and often leaves out the last function call.

valgrind --tool=memcheck gives deep analysis of memory problems.
I have recently used the callgrind tool for optimization.
valgrind --tool=callgrind
Together with KCachegrind it makes a nice tool chain. Wow! You can see some results in trunk already.
Mostly Lazarus trunk and FPC 3.2 on Manjaro Linux 64-bit.

 

TinyPortal © 2005-2018