Recent

Author Topic: [Problem solved] Wish: stop the race after Delphi  (Read 5918 times)

funlw65

  • Jr. Member
  • **
  • Posts: 70
    • 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

  • Jr. Member
  • **
  • Posts: 70
    • 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

  • Jr. Member
  • **
  • Posts: 70
    • 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: 7032
  • 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: 4001
  • 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.

funlw65

  • Jr. Member
  • **
  • Posts: 70
    • Visual Pin Configurator for Nucleo-L152RE
Re: Wish: stop the race after Delphi
« Reply #50 on: February 27, 2021, 01:34:21 pm »
In microcontrollers, when you don't have a debugger, you use a LED to figure which parts of your program don't execute.

I disabled parts of code in the "main procedure" (that would be FormShow of the main form) until I got no memory leaks.

If I enable this function, I get memory leaks:

Code: Pascal  [Select][+][-]
  1. function check_toolchain_folder:boolean;
  2. var b1 : boolean;
  3. begin
  4.   {$I-}
  5.   chdir(getenvironmentvariable('HOME'));
  6.   b1 := DirectoryExists(v_toolchain_folder);
  7.   if (b1) then begin
  8.     //
  9.     chdir(getenvironmentvariable('HOME'));
  10.     chdir(v_toolchain_folder+'/lib/gcc/arm-none-eabi');
  11.     if(IOresult = 0) then begin
  12.       if(FindFirst('*',faDirectory, _fsearch) <> 0) then
  13.         result := FALSE
  14.       else
  15.         result := TRUE;
  16.     end
  17.     else
  18.       result := FALSE;
  19.   end
  20.   else result := b1;
  21.   {$I+}
  22. end;
 

MarkMLl

  • Hero Member
  • *****
  • Posts: 2415
Re: Wish: stop the race after Delphi
« Reply #51 on: February 27, 2021, 01:47:50 pm »
In microcontrollers, when you don't have a debugger, you use a LED to figure which parts of your program don't execute.

I disabled parts of code in the "main procedure" (that would be FormShow of the main form) until I got no memory leaks.

If I enable this function, I get memory leaks:

Code: Pascal  [Select][+][-]
  1. function check_toolchain_folder:boolean;
  2. var b1 : boolean;
  3. begin
  4.   {$I-}
  5.   chdir(getenvironmentvariable('HOME'));
  6.   b1 := DirectoryExists(v_toolchain_folder);
  7.   if (b1) then begin
  8.     //
  9.     chdir(getenvironmentvariable('HOME'));
  10.     chdir(v_toolchain_folder+'/lib/gcc/arm-none-eabi');
  11.     if(IOresult = 0) then begin
  12.       if(FindFirst('*',faDirectory, _fsearch) <> 0) then
  13.         result := FALSE
  14.       else
  15.         result := TRUE;
  16.     end
  17.     else
  18.       result := FALSE;
  19.   end
  20.   else result := b1;
  21.   {$I+}
  22. end;


Of course you do. It's as-expected and documented:

https://www.freepascal.org/docs-html/current/rtl/sysutils/findfirst.html

MarkMLl
Turbo Pascal v1 on CCP/M-86, multitasking with LAN and graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

funlw65

  • Jr. Member
  • **
  • Posts: 70
    • Visual Pin Configurator for Nucleo-L152RE
Re: Wish: stop the race after Delphi
« Reply #52 on: February 27, 2021, 01:56:47 pm »
Shock! It was my fault all along  :o

Didn't know that... thank you very much for the solution!

MarkMLl

  • Hero Member
  • *****
  • Posts: 2415
Re: Wish: stop the race after Delphi
« Reply #53 on: February 27, 2021, 02:09:16 pm »
Shock! It was my fault all along  :o

Didn't know that... thank you very much for the solution!

Sorry if I was a bit brutal. However the point I'd make is that while I'm sympathetic to a "let's slow down and sort out some of the backlog" approach it's really not fair blaming Lazarus/FPC for something which has, basically, been unchanged since the earliest days of Turbo Pascal.

MarkMLl
Turbo Pascal v1 on CCP/M-86, multitasking with LAN and graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

funlw65

  • Jr. Member
  • **
  • Posts: 70
    • Visual Pin Configurator for Nucleo-L152RE
Re: Wish: stop the race after Delphi
« Reply #54 on: February 27, 2021, 02:20:51 pm »
Yes, I agree and I apologize! But this is because now I know that it was my fault. Before knowing this, the logic of my app was without fault and it worked flawlessly, the result was without error. So I was ready to fight for my justice.

Byproducts of this story is that now I regained my confidence in Lazarus+Freepascal team for applications that can have national/international audience and meantime, I also learned how to translate my app to msegui (halfway there). Well, would have served me nothing as error was still there, undetected.

Edit: Zero memory leaks! I'm happy!
« Last Edit: February 27, 2021, 02:32:55 pm by funlw65 »

Fred vS

  • Hero Member
  • *****
  • Posts: 2199
    • StrumPract is the musicians best friend
Re: Wish: stop the race after Delphi
« Reply #55 on: February 27, 2021, 02:36:50 pm »
I also learned how to translate my app to msegui (halfway there). Well, would have served me nothing as error was still there, undetected.

Learning something always serves for something.
 O:-)
I use Lazarus 2.0.6 32/64 and FPC 3.2.0 32/64 on Debian 10.2 64 bit, Windows 10, Windows 7 32/64, Windows XP 32,  FreeBSD 64 and Mac OS X Snow Leopard 32.
Widgetset: fpGUI, MSEgui, Win32, GTK2, Qt, Carbon.

https://github.com/fredvs
https://gitlab.com/fredvs

funlw65

  • Jr. Member
  • **
  • Posts: 70
    • Visual Pin Configurator for Nucleo-L152RE
Re: Wish: stop the race after Delphi
« Reply #56 on: February 27, 2021, 03:11:05 pm »
I also learned how to translate my app to msegui (halfway there). Well, would have served me nothing as error was still there, undetected.

Learning something always serves for something.
 O:-)

I mean, I would have blamed msegui as well...

Yes, I'm glad I had a reason to start learning it. I will continue the conversion of my project and it already goes smoothly - using the RAD tool with procedural programing proved that the project can be rewritten no matter the GUI interface and language.

Fred vS

  • Hero Member
  • *****
  • Posts: 2199
    • StrumPract is the musicians best friend
Re: Wish: stop the race after Delphi
« Reply #57 on: February 27, 2021, 04:16:54 pm »
I mean, I would have blamed msegui as well...

Hum, using -ghl compiler parameter, I have some doubt, mseide-terminal output would show you the guilty line.
(and I wonder why Lazarus should not show it too).

 ;)

Fre;D
I use Lazarus 2.0.6 32/64 and FPC 3.2.0 32/64 on Debian 10.2 64 bit, Windows 10, Windows 7 32/64, Windows XP 32,  FreeBSD 64 and Mac OS X Snow Leopard 32.
Widgetset: fpGUI, MSEgui, Win32, GTK2, Qt, Carbon.

https://github.com/fredvs
https://gitlab.com/fredvs

FTurtle

  • Sr. Member
  • ****
  • Posts: 289
Re: Wish: stop the race after Delphi
« Reply #58 on: February 27, 2021, 05:29:05 pm »
Code: Pascal  [Select][+][-]
  1.       if(FindFirst('*',faDirectory, _fsearch) <> 0) then
  2.         result := FALSE
  3.       else
  4.         result := TRUE;


Better style:

Code: Pascal  [Select][+][-]
  1.       result := (FindFirst('*',faDirectory, _fsearch) = 0);

funlw65

  • Jr. Member
  • **
  • Posts: 70
    • Visual Pin Configurator for Nucleo-L152RE
Re: Wish: stop the race after Delphi
« Reply #59 on: February 28, 2021, 02:20:38 am »
I mean, I would have blamed msegui as well...

Hum, using -ghl compiler parameter, I have some doubt, mseide-terminal output would show you the guilty line.
(and I wonder why Lazarus should not show it too).

 ;)

Fre;D

Fred, is that parameter included by default? Because it showed me no warnings. If is not default, then that is true also for Lazarus.

Code: Pascal  [Select][+][-]
  1.       if(FindFirst('*',faDirectory, _fsearch) <> 0) then
  2.         result := FALSE
  3.       else
  4.         result := TRUE;


Better style:

Code: Pascal  [Select][+][-]
  1.       result := (FindFirst('*',faDirectory, _fsearch) = 0);


Thank you @FTurtle, is that binary evaluation true also for Basic (Gambas3) and Python?

 

TinyPortal © 2005-2018