Lazarus

Miscellaneous => Suggestions => Topic started by: funlw65 on December 27, 2020, 12:30:47 pm

Title: [Problem solved] Wish: stop the race after Delphi
Post by: funlw65 on December 27, 2020, 12:30:47 pm
I would like that freepascal + lazarus to go to pit stop for a while and solve all the problems the compiler and lcl components have.

I get occasional program crashes under Linux, no matter which pascal version, with both gtk2 and qt5, and just using the standard lazarus components, no custom components, no dynamic memory allocations, etc. So random crashes are a common thing. At compilation time I get warnings only about UnicodeString to AnsiString conversions.

I chose lazarus for the amazing user interface and freepascal for the ability to work with strings in a more natural manner compared with C. I'll look for another tool...

Edit: memory leaks proved to be my fault!
Title: Re: Wish: stop the race after Delphi
Post by: PascalDragon on December 27, 2020, 12:56:28 pm
Quote from: funlw65 on December 27, 2020, 12:30:47 pm
At compilation time I get warnings only about UnicodeString to AnsiString conversions.

If you get warnings about UnicodeString <-> AnsiString conversions, then you should check your code, cause these warnings are there for a reason.

Also we're not racing after Delphi, we're racing after bug reports we have and these might include requests for features that derive from Delphi.
Title: Re: Wish: stop the race after Delphi
Post by: funlw65 on December 27, 2020, 01:03:58 pm
Well these come from using units like DOM, XMLRead and code like this one:

Code: Pascal  [Select][+][-]
  1. v_cb_sampling_idx_uart5 := strtoint(PassNode.FirstChild.NodeValue);

Not my code...
Title: Re: Wish: stop the race after Delphi
Post by: MarkMLl on December 27, 2020, 01:14:40 pm
Quote from: funlw65 on December 27, 2020, 12:30:47 pm
I would like that freepascal + lazarus to go to pit stop for a while and solve all the problems the compiler and lcl components have.

I get occasional program crashes under Linux, no matter which pascal version, with both gtk2 and qt5, and just using the standard lazarus components, no custom components, no dynamic memory allocations, etc. So random crashes are a common thing. At compilation time I get warnings only about UnicodeString to AnsiString conversions.

I echo your sentiment but my experience is that crashes are generally the result of something in my code rather than in the LCL etc.

I've got a lot of tricky legacy stuff which is heavily multithreaded, and not only is that sort of thing notoriously difficult to get right but it's very easy to write assuming certain things about e.g. a particular version of Delphi which no longer hold at some point in the future.

MarkMLl
Title: Re: Wish: stop the race after Delphi
Post by: Handoko on December 27, 2020, 01:17:40 pm
Quote from: funlw65 on December 27, 2020, 12:30:47 pm
I get occasional program crashes under Linux, no matter which pascal version, with both gtk2 and qt5 ...

I don't use Qt5 interface. But I've been using Lazarus on Ubuntu for more than 10 years. I do not write corporate class software, I just write simple games and tools. They just work correctly, no crash. Well actually, they crashed several times. But after some inspections, those were my own faults.

Lazarus and Free Pascal are not as bad as you thought. If you have issue with it, post it here. Tell us what are the steps to make it crash and don't forget to provide the compile-able source code. We will help you fix it. If you are not willing to publicize your project, you can write a demo that show the problem.
Title: Re: Wish: stop the race after Delphi
Post by: funlw65 on December 27, 2020, 01:23:58 pm
Quote from: Handoko on December 27, 2020, 01:17:40 pm
Quote from: funlw65 on December 27, 2020, 12:30:47 pm
I get occasional program crashes under Linux, no matter which pascal version, with both gtk2 and qt5 ...

I don't use Qt5 interface. But I've been using Lazarus on Ubuntu for more than 10 years. I do not write corporate class software, I just write simple games and tools. They just work correctly, no crash. Well actually, they crashed several times. But after some inspections, those were my own faults.

Lazarus and Free Pascal are not as bad as you thought. If you have issue with it, post it here. Tell us what are the steps to make it crash and don't forget to provide the compile-able source code. We will help you fix it. If you are not willing to publicize your project, you can write a demo that show the problem.

Ok, I understand and I am ready to accept that the error might be my fault. Even if the code is incredibly simple, just pressing buttons, completing fields, generating text files based on the configuration the user makes. The crashes are random, no mater where I am in the program. Sometimes, just moving the mouse over a button.

I will commit the last version of the code on gitlab (is an open source project) and I will post the link.
Title: Re: Wish: stop the race after Delphi
Post by: funlw65 on December 27, 2020, 01:44:14 pm
Code committed here:  https://gitlab.com/funlw65/vscode_nucleo_l152re
but the repository contains also all the tools and tutorials required for an user  so is huge.

So I archived only the application and uploaded on my google drive
https://drive.google.com/file/d/1jm1bdS9pwVWy6TOg1gnsMJqnuEI7yEPD/view?usp=sharing

The application is a visual tool for configuring the clock frequency, the pins and the peripherals of an STM32L152 microcontroller and then generates the C source code for the gcc arm compiler and the project files required for the Visual Studio Code and the Cortex Debugger.
Title: Re: Wish: stop the race after Delphi
Post by: Handoko on December 27, 2020, 02:00:29 pm
I saw you set it to use Qt and Athlon, which does not match my system so I changed it to Intel Linux GTK2. Compiling succeeded, now running it.

I am going to take a bath, relax and watch TV. Will be back 1 hour later. Lets see will it crash or not.

Below is the screenshot running on Ubuntu Mate 20.04 Lazarus 2.0.10 GTK2.
Title: Re: Wish: stop the race after Delphi
Post by: funlw65 on December 27, 2020, 02:06:06 pm
It worked for me in gtk2 without crashes after moving to lazarus 2.x ... But the reason moving to qt5 is that gtk2 is obsoleted in some versions of linux and don't know if it will be compiled in next distro versions (whatever linux that might be). I am on Debian 10.x but I worked also in Void, Fedora, Mint.
Title: Re: Wish: stop the race after Delphi
Post by: Martin_fr on December 27, 2020, 02:11:49 pm
If you get "random crashes", try running under  (compile with -gv)
Code: Text  [Select][+][-]
  1. valgrind --tool=memcheck

The report will contain some noise (depending on gtk version), but it may yield something useful.
Title: Re: Wish: stop the race after Delphi
Post by: Handoko on December 27, 2020, 02:12:45 pm
According to this wiki, Qt is okay but some features are partial implemented:
https://wiki.lazarus.freepascal.org/Roadmap (https://wiki.lazarus.freepascal.org/Roadmap)

Because I don't use Qt, so I will let others to comment.
Title: Re: Wish: stop the race after Delphi
Post by: lainz on December 27, 2020, 02:19:11 pm
I can say that any app can crash also with kotlin that's in my opinion a more modern language oriented to be simple to type and avoid errors.

I get crashes as well with any language so is the faulty code and not the language.
Title: Re: Wish: stop the race after Delphi
Post by: lainz on December 27, 2020, 02:23:14 pm
With faulty code I say your code and as well the libraries. So any included library can be the reason too as well third party stuff.
Title: Re: Wish: stop the race after Delphi
Post by: JuhaManninen on December 27, 2020, 02:48:27 pm
Quote from: funlw65 on December 27, 2020, 01:44:14 pm
So I archived only the application and uploaded on my google drive
https://drive.google.com/file/d/1ahhRN3RnQY4Aj-n70olH4E0-3xpxQhJc/view?usp=sharing
How to download the .zip file into my computer. It only offers a "ZIP Extractor" working in Google Drive. Can't you just upload it here?
Title: Re: Wish: stop the race after Delphi
Post by: Handoko on December 27, 2020, 03:17:36 pm
This is the zip version. I removed the binary because the size is 8 MB.
Title: Re: Wish: stop the race after Delphi
Post by: funlw65 on December 27, 2020, 03:19:09 pm
Attached the Valgrind messages:
Title: Re: Wish: stop the race after Delphi
Post by: lucamar on December 27, 2020, 03:48:40 pm
Quote from: funlw65 on December 27, 2020, 03:19:09 pm
Attached the Valgrind messages: [...]

Nitpicking, I know, but when attaching the output of a command line program it's almost always better to do it as a text file, either redirecting the output to a file or copying it from the terminal (almost all have facilities for this) and paste it to a text file using whatever editor you like.

It's always easier viewing/editing text than an image. ;)
Title: Re: Wish: stop the race after Delphi
Post by: funlw65 on December 27, 2020, 04:00:12 pm
Quote from: lucamar on December 27, 2020, 03:48:40 pm
Quote from: funlw65 on December 27, 2020, 03:19:09 pm
Attached the Valgrind messages: [...]

Nitpicking, I know, but when attaching the output of a command line program it's almost always better to do it as a text file, either redirecting the output to a file or copying it from the terminal (almost all have facilities for this) and paste it to a text file using whatever editor you like.

It's always easier viewing/editing text than an image. ;)

I thought it will keep the formatting better this way... no problem to redirect it to a file next time.
Title: Re: Wish: stop the race after Delphi
Post by: Handoko on December 27, 2020, 04:22:11 pm
Two hours have passed, no crash. I moved my mouse, clicked the form here and there. Nothing bad happened. So, I can say the issue is not Lazarus GTK2 related.
Title: Re: Wish: stop the race after Delphi
Post by: funlw65 on December 27, 2020, 04:34:13 pm
Quote from: Handoko on December 27, 2020, 04:22:11 pm
Two hours have passed, no crash. I moved my mouse, clicked the form here and there. Nothing bad happened. So, I can say the issue is not Lazarus GTK2 related.

Thank you for your test. Were you able to see these dialogs? Even with gtk2 there are memory leaks...
The green and gray "pins" are click-able and launch another configuration dialog...
Title: Re: Wish: stop the race after Delphi
Post by: JuhaManninen on December 27, 2020, 04:46:40 pm
Quote from: Handoko on December 27, 2020, 03:17:36 pm
This is the zip version. I removed the binary because the size is 8 MB.
Thanks!
Did you extract and copy the files through Google Drive and then created a new ZIP package?

@funlw65, how to test your app? "Setting Environment" asks for "Toolchain folder" and such. What folder should I choose? There is no initial directory to start with.

Quote
Even with gtk2 there are memory leaks...
Blame yourself for that.
For example Lazarus IDE built with GTK2 or QT5 has no memory leaks after hours of intense work.
Title: Re: Wish: stop the race after Delphi
Post by: funlw65 on December 27, 2020, 04:56:11 pm
Hi, you need to read the Readme from the repository (link on the first page of this thread). When you enter in the repository, you must scroll the page down and read the description and the little tutorial. There is also a movie that shows step by step how to set the environment.

The application won't work if the environment is not set correctly because the main objective is to have a C toolchain for programming the STM32 microcontroller. It does some checks then complain if those things are not there, in your home folder.

In my experience, the app works perfect and the project generated in C language compiles without errors in arm-gcc. It saves the project correctly, it loads correctly, I don't have problems with the way the app works. It works as intended. But it leaks heavily and not from my code as I do not use custom objects or allocate memory. But you can see that looking at the code. If I use qt5 it crashes.
Title: Re: Wish: stop the race after Delphi
Post by: Martin_fr on December 27, 2020, 04:57:44 pm
Quote from: funlw65 on December 27, 2020, 03:19:09 pm
Attached the Valgrind messages:
Are you sure you compiled with -gv ?
Also to be save, set debug info to dwarf ( -gw ). (I would think gv includes that, but...)

This would be the first app I have seen where valgrind did not at least give a false positive an "uninitialized ...in condition" or "reading 1 byte ... past the end of ..."

Just starting and stopping indeed brings up no errors. (I use gtk2, since I haven't got qt installed)
I do not have the toolchain, so I can't really test anything else.
Title: Re: Wish: stop the race after Delphi
Post by: funlw65 on December 27, 2020, 05:02:58 pm
This was before the image I posted:

Code: Text  [Select][+][-]
  1. [methevac@me-pc vsc_stm32l1_projects]$ cd vpc
  2. [methevac@me-pc vpc]$ valgrind --tool=memcheck ./vpc
  3. ==509== Memcheck, a memory error detector
  4. ==509== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
  5. ==509== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info
  6. ==509== Command: ./vpc
  7. ==509==
  8.  
  9. (vpc:509): dbind-WARNING **: 16:01:14.321: Couldn't register with accessibility bus: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
  10. qt5ct: using qt5ct plugin
  11. qt5ct: D-Bus global menu: no
  12. ==509== Syscall param writev(vector[...]) points to uninitialised byte(s)
  13. ==509==    at 0x4D63537: __writev (writev.c:26)
  14. ==509==    by 0x4D63537: writev (writev.c:24)
  15. ==509==    by 0x6516FDC: ??? (in /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0)
  16. ==509==    by 0x65173B0: ??? (in /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0)
  17. ==509==    by 0x651743C: xcb_writev (in /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0)
  18. ==509==    by 0x4B7586D: _XSend (in /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0)
  19. ==509==    by 0x4B759A3: ??? (in /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0)
  20. ==509==    by 0x65170E5: ??? (in /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0)
  21. ==509==    by 0x6517164: ??? (in /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0)
  22. ==509==    by 0x6517690: ??? (in /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0)
  23. ==509==    by 0x651792B: xcb_send_request_with_fds64 (in /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0)
  24. ==509==    by 0x6517CF8: xcb_send_request (in /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0)
  25. ==509==    by 0x651E5F0: xcb_change_property (in /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0)
  26. ==509==  Address 0x91f4244 is 36 bytes inside a block of size 16,384 alloc'd
  27. ==509==    at 0x4837B65: calloc (vg_replace_malloc.c:752)
  28. ==509==    by 0x4B65B15: XOpenDisplay (in /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0)
  29. ==509==    by 0x98FBE0D: QXcbConnection::QXcbConnection(QXcbNativeInterface*, bool, unsigned int, char const*) (in /usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5.11.3)
  30. ==509==    by 0x98FFC4E: QXcbIntegration::QXcbIntegration(QStringList const&, int&, char**) (in /usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5.11.3)
  31. ==509==    by 0x485326C: ??? (in /usr/lib/x86_64-linux-gnu/qt5/plugins/platforms/libqxcb.so)
  32. ==509==    by 0x56110C2: QPlatformIntegrationFactory::create(QString const&, QStringList const&, int&, char**, QString const&) (in /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5.11.3)
  33. ==509==    by 0x561F33D: QGuiApplicationPrivate::createPlatformIntegration() (in /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5.11.3)
  34. ==509==    by 0x562039C: QGuiApplicationPrivate::createEventDispatcher() (in /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5.11.3)
  35. ==509==    by 0x5EA7FA4: QCoreApplicationPrivate::init() (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.11.3)
  36. ==509==    by 0x562137E: QGuiApplicationPrivate::init() (in /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5.11.3)
  37. ==509==    by 0x5010F88: QApplicationPrivate::init() (in /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5.11.3)
  38. ==509==    by 0x4A075C0: QApplication_Create (in /usr/lib/x86_64-linux-gnu/libQt5Pas.so.1.2.6)
  39. ==509==
Title: Re: Wish: stop the race after Delphi
Post by: funlw65 on December 27, 2020, 05:09:35 pm
Ok, I did what you said last time and I had a "reaction" from Valgrind after I closed the "Clock" dialog...

Code: Text  [Select][+][-]
  1. [methevac@me-pc vpc]$ valgrind --tool=memcheck ./vpc
  2. ==8590== Memcheck, a memory error detector
  3. ==8590== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
  4. ==8590== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info
  5. ==8590== Command: ./vpc
  6. ==8590==
  7.  
  8. (vpc:8590): dbind-WARNING **: 18:04:46.936: Couldn't register with accessibility bus: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
  9. qt5ct: using qt5ct plugin
  10. qt5ct: D-Bus global menu: no
  11. ==8590== Syscall param writev(vector[...]) points to uninitialised byte(s)
  12. ==8590==    at 0x4D63537: __writev (writev.c:26)
  13. ==8590==    by 0x4D63537: writev (writev.c:24)
  14. ==8590==    by 0x6516FDC: ??? (in /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0)
  15. ==8590==    by 0x65173B0: ??? (in /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0)
  16. ==8590==    by 0x651743C: xcb_writev (in /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0)
  17. ==8590==    by 0x4B7586D: _XSend (in /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0)
  18. ==8590==    by 0x4B759A3: ??? (in /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0)
  19. ==8590==    by 0x65170E5: ??? (in /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0)
  20. ==8590==    by 0x6517164: ??? (in /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0)
  21. ==8590==    by 0x6517690: ??? (in /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0)
  22. ==8590==    by 0x651792B: xcb_send_request_with_fds64 (in /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0)
  23. ==8590==    by 0x6517CF8: xcb_send_request (in /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0)
  24. ==8590==    by 0x651E5F0: xcb_change_property (in /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0)
  25. ==8590==  Address 0x91f4264 is 36 bytes inside a block of size 16,384 alloc'd
  26. ==8590==    at 0x4837B65: calloc (vg_replace_malloc.c:752)
  27. ==8590==    by 0x4B65B15: XOpenDisplay (in /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0)
  28. ==8590==    by 0x98FBE0D: QXcbConnection::QXcbConnection(QXcbNativeInterface*, bool, unsigned int, char const*) (in /usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5.11.3)
  29. ==8590==    by 0x98FFC4E: QXcbIntegration::QXcbIntegration(QStringList const&, int&, char**) (in /usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5.11.3)
  30. ==8590==    by 0x485326C: ??? (in /usr/lib/x86_64-linux-gnu/qt5/plugins/platforms/libqxcb.so)
  31. ==8590==    by 0x56110C2: QPlatformIntegrationFactory::create(QString const&, QStringList const&, int&, char**, QString const&) (in /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5.11.3)
  32. ==8590==    by 0x561F33D: QGuiApplicationPrivate::createPlatformIntegration() (in /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5.11.3)
  33. ==8590==    by 0x562039C: QGuiApplicationPrivate::createEventDispatcher() (in /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5.11.3)
  34. ==8590==    by 0x5EA7FA4: QCoreApplicationPrivate::init() (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.11.3)
  35. ==8590==    by 0x562137E: QGuiApplicationPrivate::init() (in /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5.11.3)
  36. ==8590==    by 0x5010F88: QApplicationPrivate::init() (in /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5.11.3)
  37. ==8590==    by 0x4A075C0: QApplication_Create (in /usr/lib/x86_64-linux-gnu/libQt5Pas.so.1.2.6)
  38. ==8590==
  39. ==8590== Invalid write of size 8
  40. ==8590==    at 0x4A7B96B: ??? (in /usr/lib/x86_64-linux-gnu/libQt5Pas.so.1.2.6)
  41. ==8590==    by 0x5ECA7F5: QMetaObject::activate(QObject*, int, int, void**) (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.11.3)
  42. ==8590==    by 0x5ECAE7E: QObject::destroyed(QObject*) (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.11.3)
  43. ==8590==    by 0x5045EFA: QWidget::~QWidget() (in /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5.11.3)
  44. ==8590==    by 0x5046008: QWidget::~QWidget() (in /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5.11.3)
  45. ==8590==    by 0x5EC875A: QObjectPrivate::deleteChildren() (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.11.3)
  46. ==8590==    by 0x5045E05: QWidget::~QWidget() (in /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5.11.3)
  47. ==8590==    by 0x5046008: QWidget::~QWidget() (in /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5.11.3)
  48. ==8590==    by 0x5ECB08F: QObject::event(QEvent*) (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.11.3)
  49. ==8590==    by 0x504A96A: QWidget::event(QEvent*) (in /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5.11.3)
  50. ==8590==    by 0x500C4C0: QApplicationPrivate::notify_helper(QObject*, QEvent*) (in /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5.11.3)
  51. ==8590==    by 0x501396F: QApplication::notify(QObject*, QEvent*) (in /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5.11.3)
  52. ==8590==  Address 0x1245e5f0 is 16 bytes inside a block of size 56 free'd
  53. ==8590==    at 0x483708B: operator delete(void*, unsigned long) (vg_replace_malloc.c:585)
  54. ==8590==    by 0x7A77F7: QTOBJECTS$_$TQTOBJECT_$__$$_DETACHEVENTS (qtobjects.pas:1109)
  55. ==8590==    by 0x789A6E: QTWIDGETS$_$TQTMAINWINDOW_$__$$_DETACHEVENTS (qtwidgets.pas:8131)
  56. ==8590==    by 0x77E0D2: QTWIDGETS$_$TQTWIDGET_$__$$_DEINITIALIZEWIDGET (qtwidgets.pas:2168)
  57. ==8590==    by 0x7A14FA: QTWIDGETS$_$TQTHINTWINDOW_$__$$_DEINITIALIZEWIDGET (qtwidgets.pas:18307)
  58. ==8590==    by 0x77E2EA: QTWIDGETS$_$TQTWIDGET_$__$$_DESTROY (qtwidgets.pas:2230)
  59. ==8590==    by 0x7882FC: QTWIDGETS$_$TQTMAINWINDOW_$__$$_DESTROY (qtwidgets.pas:7082)
  60. ==8590==    by 0x435C6A: SYSTEM$_$TOBJECT_$__$$_FREE (in /home/methevac/vsc_stm32l1_projects/vpc/vpc)
  61. ==8590==    by 0x77E40A: QTWIDGETS$_$TQTWIDGET_$__$$_RELEASE (qtwidgets.pas:2270)
  62. ==8590==    by 0x77E43A: QTWIDGETS$_$TQTWIDGET_$__$$_DESTROYED (qtwidgets.pas:2276)
  63. ==8590==    by 0x4A7B96A: ??? (in /usr/lib/x86_64-linux-gnu/libQt5Pas.so.1.2.6)
  64. ==8590==    by 0x5ECA7F5: QMetaObject::activate(QObject*, int, int, void**) (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.11.3)
  65. ==8590==  Block was alloc'd at
  66. ==8590==    at 0x4835DEF: operator new(unsigned long) (vg_replace_malloc.c:334)
  67. ==8590==    by 0x49D39A6: QObject_hook_Create (in /usr/lib/x86_64-linux-gnu/libQt5Pas.so.1.2.6)
  68. ==8590==    by 0x7A7778: QTOBJECTS$_$TQTOBJECT_$__$$_ATTACHEVENTS (qtobjects.pas:1096)
  69. ==8590==    by 0x789951: QTWIDGETS$_$TQTMAINWINDOW_$__$$_ATTACHEVENTS (qtwidgets.pas:8099)
  70. ==8590==    by 0x856E38: QTWSFORMS$_$TQTWSHINTWINDOW_$__$$_CREATEHANDLE$TWINCONTROL$TCREATEPARAMS$$TLCLINTFHANDLE (qtwsforms.pp:1052)
  71. ==8590==    by 0x6E5454: CONTROLS$_$TWINCONTROL_$__$$_CREATEWND (wincontrol.inc:7537)
  72. ==8590==    by 0x44FB46: FORMS$_$TSCROLLINGWINCONTROL_$__$$_CREATEWND (scrollingwincontrol.inc:23)
  73. ==8590==    by 0x45938C: FORMS$_$TCUSTOMFORM_$__$$_CREATEWND (customform.inc:2703)
  74. ==8590==    by 0x6E4BFF: CONTROLS$_$TWINCONTROL_$__$$_CREATEHANDLE (wincontrol.inc:7447)
  75. ==8590==    by 0x6E63B7: CONTROLS$_$TWINCONTROL_$__$$_HANDLENEEDED (wincontrol.inc:7900)
  76. ==8590==    by 0x6D1CCA: CONTROLS$_$TCONTROLCANVAS_$__$$_CREATEHANDLE (controlcanvas.inc:96)
  77. ==8590==    by 0x639F6D: GRAPHICS$_$TCANVAS_$__$$_REQUIREDSTATE$TCANVASSTATE (canvas.inc:1699)
  78. ==8590==
  79.  
Title: Re: Wish: stop the race after Delphi
Post by: funlw65 on December 27, 2020, 05:13:23 pm
I excluded the last part with the memory leaks (as in the picture I posted and got the advice to provide only text)
Title: Re: Wish: stop the race after Delphi
Post by: JuhaManninen on December 27, 2020, 05:21:36 pm
Quote from: funlw65 on December 27, 2020, 04:56:11 pm
But it leaks heavily and not from my code as I do not use custom objects or allocate memory.
Hmmm...
Indeed I don't find anything by a search ".Create" except for Application.CreateForm() calls in the main .lpr file.
It means you don't use any objects anywhere except for the streamed visual components on the auto-created forms. You don't even use DataModules.
Interesting!

Functions like ReadXMLFile() in fcl create an object which must by freed by a caller.
You free the Doc objects, OK, but you should use try...finally blocks to be sure.
Title: Re: Wish: stop the race after Delphi
Post by: Martin_fr on December 27, 2020, 05:25:45 pm
I am not sure about the syscall, but would tend to ignore that one. From the stack, if it is anything it is deep inside QT. And it is very unlikely to be caused by anything in the LCL or Lazarus supplied code (let alone yours).

The
Code: Text  [Select][+][-]
  1. ==8590== Invalid write of size 8
does look suspicious.
Code: Text  [Select][+][-]
  1.  is ... bytes inside a block of size ... free'd
is always a bad sign.

The traces are not long enough to say something definitive. (you can increase the length by --num-callers=50 )
And also I am not the expert on QT, or the Lazarus QT wrapper...

There is a (imho) good chance that the memory free and later access are triggered by something either in the Lazarus Code or yours.
Title: Re: Wish: stop the race after Delphi
Post by: funlw65 on December 27, 2020, 05:28:37 pm
Quote from: JuhaManninen on December 27, 2020, 04:46:40 pm
Quote from: Handoko on December 27, 2020, 03:17:36 pm
This is the zip version. I removed the binary because the size is 8 MB.
Thanks!
Did you extract and copy the files through Google Drive and then created a new ZIP package?

@funlw65, how to test your app? "Setting Environment" asks for "Toolchain folder" and such. What folder should I choose? There is no initial directory to start with.

Quote
Even with gtk2 there are memory leaks...
Blame yourself for that.
For example Lazarus IDE built with GTK2 or QT5 has no memory leaks after hours of intense work.

Juha, you should be able to download the archive as it is, there must be a button with a down arrow...
BTW, the application was tested exclusively in Linux as it uses the paths specific to unix-like systems. I know there is a function that translates the linux paths in Windows compatible paths but I didn't bothered to include that in the code. That is all you have to do in the code to be able to work in Windows but there are so many places to make the modifications, that it will be easier to migrate to Linux :D
Title: Re: Wish: stop the race after Delphi
Post by: funlw65 on December 27, 2020, 05:31:45 pm
Quote from: JuhaManninen on December 27, 2020, 05:21:36 pm
Quote from: funlw65 on December 27, 2020, 04:56:11 pm
But it leaks heavily and not from my code as I do not use custom objects or allocate memory.
Hmmm...
Indeed I don't find anything by a search ".Create" except for Application.CreateForm() calls in the main .lpr file.
It means you don't use any objects anywhere except for the streamed visual components on the auto-created forms. You don't even use DataModules.
Interesting!

Functions like ReadXMLFile() in fcl create an object which must by freed by a caller.
You free the Doc objects, OK, but you should use try...finally blocks to be sure.

Exactly! That is why I am discouraged and thinking to use qtcreator and C++ for my application. And is a pity... I really love Pascal and Lazarus+FreePascal is amazing - at least, the possibilities...
Title: Re: Wish: stop the race after Delphi
Post by: JuhaManninen on December 27, 2020, 05:37:56 pm
Quote from: funlw65 on December 27, 2020, 05:28:37 pm
Juha, you should be able to download the archive as it is, there must be a button with a down arrow...
Damn yes, now I notice it. It was "hidden" in upper right corner. The ZIP extractor thingy was more visible.
I am using Linux.
I recommend to make your code cross-platform, the libraries support it.
Title: Re: Wish: stop the race after Delphi
Post by: PascalDragon on December 28, 2020, 01:11:13 pm
Quote from: funlw65 on December 27, 2020, 01:03:58 pm
Well these come from using units like DOM, XMLRead and code like this one:

Code: Pascal  [Select][+][-]
  1. v_cb_sampling_idx_uart5 := strtoint(PassNode.FirstChild.NodeValue);

Not my code...

Yes, your code. NodeValue is of type DOMString which is a UnicodeString, but StrToInt takes a AnsiString. Thus you need to insert an explicit typecast to avoid the warning: StrToInt(AnsiString(PassNode.FirstChild.NodeValue)).

Alternatively you can add an overload to some common unit of yours:

Code: Pascal  [Select][+][-]
  1. unit XYZ;
  2.  
  3. {$mode objfpc}
  4.  
  5. interface
  6.  
  7. function StrToInt(const aStr: UnicodeString): Integer; inline; overload; // the overload is important in this case!
  8.  
  9. implementation
  10.  
  11. uses
  12.   SysUtils;
  13.  
  14. function StrToInt(const aStr: UnicodeString): Integer;
  15. begin
  16.   Result := StrToInt(AnsiString(aStr));
  17. end;
  18.  
  19. end.
Title: Re: Wish: stop the race after Delphi
Post by: funlw65 on December 28, 2020, 02:27:36 pm
Thank you for the overload, it saves me a huge amount of typing! I knew what parameter type strtoint required, but didn't knew a typecast will solve the warning.

And BTW, this solve only the warnings (and there I had no loss of data converting from a type to another), without solving the leaks, right?
Title: Re: Wish: stop the race after Delphi
Post by: PascalDragon on December 29, 2020, 11:29:12 am
Quote from: funlw65 on December 28, 2020, 02:27:36 pm
Thank you for the overload, it saves me a huge amount of typing! I knew what parameter type strtoint required, but didn't knew a typecast will solve the warning.

The idea behind the warning is that the user pays attention to whether the string conversion is indeed correct and if it is to insert an explicit typecast (Delphi behaves the same here).

Quote from: funlw65 on December 28, 2020, 02:27:36 pm
And BTW, this solve only the warnings (and there I had no loss of data converting from a type to another), without solving the leaks, right?

Yes, this only solves these warnings. For your specific usecase of StrToInt there indeed won't be any significant data loss, but there can be situations where you really need to pay attention how you convert your strings (though Lazarus by default uses UTF-8, so there the data loss isn't a problem either).
Title: Re: Wish: stop the race after Delphi
Post by: funlw65 on January 05, 2021, 07:16:30 am
The crash affects also Lazarus compiled with Qt5 widgets. When I hover the mouse over the Toolbar/SpeedButtons in the main form of my project - not immediately, exactly as in my application. When I observed this behavior in my application, I said that I will fiddle with those buttons in the form designer, deactivating the tooltips, introducing a caption, etc. After a while I got this (see attachment):

Two years back, when I started working at this project, I had problems with bitmaps included in buttons that were 32x32 pixels or bigger in size. Then, Lazarus 2.x seemed to solve that problem... don't remember on which widget set... 

Edit: I remembered, it was qt5. So I switched to gtk2 but then I created that topic, "How long gtk+2.0 will last?" https://forum.lazarus.freepascal.org/index.php/topic,43719.0.html
Title: Re: Wish: stop the race after Delphi
Post by: dbannon on January 05, 2021, 08:07:45 am
funlw65, my app has 19K lines of code, compiles under GTK2 or Qt5 (and Win, Mac) and has no memory leaks or crashes.  But let me tell you, it has, during development, had lots and lots of both.  And from memory, I can trace just one memory leak to Lazarus, and that was in Mac's Cocoa Carbon (who cares?) and one crash that related to pasting content from the clipboard (that has been fixed).  And the rest where mine and mine alone !

Its quite easy to miss things that leak, I found it necessary to continuously check for leaks as I developed.  For example, findfirst (used to search directories for files) uses a small data structure that gets auto created for you, you may well claim you did not create it but you must free it !

That being said, my application obviously does quite different things than yours and uses different parts of Lazarus. So, you could be using unstable Lazarus stuff and I am not. Looks (from images in this thread) you are talking to an ardiuno and maybe something else ?  So, USB/Serial protocols ?  Can be quite timing sensitive. 

When it crashes and you are doing nothing, is the app itself also doing nothing ?  Or is it hitting that USB interface watching for something to change ?  Is that something you can disable to see if the situation improves ?

Davo

Edit, replaced the work Cocoa with Carbon, sorry about stupid mistake.

Title: Re: Wish: stop the race after Delphi
Post by: funlw65 on January 05, 2021, 08:16:38 am
Davo, rest assured, is not from me. This application only generates text, text files to be correct, reading the status of the widgets from the forms that were created by the Lazarus. My code is tested step by step. After generating the C sources with my app, I close it and then import the project in Visual Studio Code to be completed, compiled, debugged and uploaded in the STM32 NucleoL152 development board where it works flawlessly. 

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.

The way I program is the old procedural thing... for a couple of reasons. I can dare to say that this app can be used as a benchmark for Lazarus. If there are memory leaks, those come from Lazarus or deeper.

BTW, that last crash is Lazarus crash, in designer mode... No code executed from my project. In the same area it crashes my app.
Title: Re: Wish: stop the race after Delphi
Post by: PascalDragon on January 05, 2021, 08:52:40 am
Quote from: dbannon on January 05, 2021, 08:07:45 am
And from memory, I can trace just one memory leak to Lazarus, and that was in Mac's Cocoa (who cares?)

Obviously the Lazarus devs care, cause there shouldn't be memory leaks in the LCL or the widgetset interfaces. Did you report it? Was it fixed in the meantime?
Title: Re: Wish: stop the race after Delphi
Post by: dbannon on January 05, 2021, 09:01:34 am

Arr, sorry, I mean to say Carbon, not Cocoa !  https://bugs.freepascal.org/view.php?id=32678

I will edit the above message.

Seriously sorry !
Davo

Quote from: PascalDragon on January 05, 2021, 08:52:40 am
Quote from: dbannon on January 05, 2021, 08:07:45 am
And from memory, I can trace just one memory leak to Lazarus, and that was in Mac's Cocoa (who cares?)

Obviously the Lazarus devs care, cause there shouldn't be memory leaks in the LCL or the widgetset interfaces. Did you report it? Was it fixed in the meantime?
Title: Re: Wish: stop the race after Delphi
Post by: PascalDragon on January 05, 2021, 09:06:17 am
Quote from: dbannon on January 05, 2021, 09:01:34 am
Arr, sorry, I mean to say Carbon, not Cocoa !  https://bugs.freepascal.org/view.php?id=32678

Even if it's Carbon it should be looked at. It's still needed for PowerPC after all. But thank you for the bug report, maybe I'll give it a try to hunt it down. ;)
Title: Re: Wish: stop the race after Delphi
Post by: dbannon on January 05, 2021, 09:13:16 am
funlw65  - hmm, might be interesting to run a memory test on your machine ?  If its that simple and other people are not having the same problem with much more complicated applications, you have to wonder ....

Unless, as I said, you are using a specific part of Lazarus that is otherwise rarely used.  If you can identify just what that part is, it can be fixed.

Davo
Title: Re: Wish: stop the race after Delphi
Post by: funlw65 on January 05, 2021, 09:33:22 am
The same result on two different Intel Asus laptops with 4GB RAM and a desktop PC based on AMD with 8GB RAM. On Linux Debian, Devuan, Void, Fedora, LinuxMint and UNIX FreeBSD.

I gave the clues, initially, at a 1.x Lazarus couldn't use pixmaps in (speed)buttons that were bigger than 16x16, buttons were displayed without those pixmaps. Now, the problems seems to be in that ToolBar/SpeedButtons/probably their Pixmaps? As I said, Lazarus compiled with Qt5 widget crashes working on the ToolBar/SpeedButtons in my main form.

It is somehow stable with gtk2 but there are still reports of memory locations not being freed. And probably a crash "in years" - so rare that I considered the app free of problems.

Working on Debian for quite some time now.
Title: Re: Wish: stop the race after Delphi
Post by: JuhaManninen on January 05, 2021, 12:34:16 pm
Quote from: funlw65 on January 05, 2021, 08:16:38 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.
Title: Re: Wish: stop the race after Delphi
Post by: MarkMLl on January 05, 2021, 12:46:15 pm
Quote from: funlw65 on January 05, 2021, 08:16:38 am
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
Title: Re: Wish: stop the race after Delphi
Post by: funlw65 on January 05, 2021, 06:08:51 pm
Thank you for advices, now I know how to hunt :)
Title: Re: Wish: stop the race after Delphi
Post by: funlw65 on January 05, 2021, 08:13:10 pm
Quote from: MarkMLl on January 05, 2021, 12:46:15 pm
Quote from: funlw65 on January 05, 2021, 08:16:38 am
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)...
Title: Re: Wish: stop the race after Delphi
Post by: funlw65 on January 06, 2021, 07:14:50 am
Quote from: JuhaManninen on January 05, 2021, 12:34:16 pm
Quote from: funlw65 on January 05, 2021, 08:16:38 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. 
Title: Re: Wish: stop the race after Delphi
Post by: funlw65 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?
Title: Re: Wish: stop the race after Delphi
Post by: Martin_fr on January 06, 2021, 06:17:51 pm
Quote from: funlw65 on January 05, 2021, 08:13:10 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)
Title: Re: Wish: stop the race after Delphi
Post by: JuhaManninen on January 07, 2021, 05:15:01 pm
Quote from: funlw65 on January 06, 2021, 05:36:41 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.
Title: Re: Wish: stop the race after Delphi
Post by: funlw65 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;
 
Title: Re: Wish: stop the race after Delphi
Post by: MarkMLl on February 27, 2021, 01:47:50 pm
Quote from: funlw65 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;


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

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

MarkMLl
Title: Re: Wish: stop the race after Delphi
Post by: funlw65 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!
Title: Re: Wish: stop the race after Delphi
Post by: MarkMLl on February 27, 2021, 02:09:16 pm
Quote from: funlw65 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!

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
Title: Re: Wish: stop the race after Delphi
Post by: funlw65 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!
Title: Re: Wish: stop the race after Delphi
Post by: Fred vS on February 27, 2021, 02:36:50 pm
Quote from: funlw65 on February 27, 2021, 02:20:51 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:-)
Title: Re: Wish: stop the race after Delphi
Post by: funlw65 on February 27, 2021, 03:11:05 pm
Quote from: Fred vS on February 27, 2021, 02:36:50 pm
Quote from: funlw65 on February 27, 2021, 02:20:51 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.
Title: Re: Wish: stop the race after Delphi
Post by: Fred vS on February 27, 2021, 04:16:54 pm
Quote from: funlw65 on February 27, 2021, 03:11:05 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
Title: Re: Wish: stop the race after Delphi
Post by: FTurtle on February 27, 2021, 05:29:05 pm
Quote from: funlw65 on February 27, 2021, 01:34:21 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);
Title: Re: Wish: stop the race after Delphi
Post by: funlw65 on February 28, 2021, 02:20:38 am
Quote from: Fred vS on February 27, 2021, 04:16:54 pm
Quote from: funlw65 on February 27, 2021, 03:11:05 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

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

Quote from: FTurtle on February 27, 2021, 05:29:05 pm
Quote from: funlw65 on February 27, 2021, 01:34:21 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);


Thank you @FTurtle, is that binary evaluation true also for Basic (Gambas3) and Python?
Title: Re: Wish: stop the race after Delphi
Post by: Fred vS on February 28, 2021, 11:22:53 am
Quote from: funlw65 on February 28, 2021, 02:20:38 am
Fred, is that parameter included by default? Because it showed me no warnings. If is not default, then that is true also for Lazarus.

Hello.

Not sure to understand.

Using Lazarus, you need to enable gl + gh in project option: see picture.

For mseide (or ideU) you set it in project options too: see picture.

When you close your application, there should have some info about the memory leak: see picture of the mseide-console:
It should be the same with Lazarus.

Fre;D


Title: Re: [Problem solved] Wish: stop the race after Delphi
Post by: Fred vS on February 28, 2021, 12:37:32 pm
Re-hello.

Quote from: funlw65 on February 28, 2021, 02:20:38 am
Fred, is that parameter included by default? Because it showed me no warnings. If is not default, then that is true also for Lazarus.

No, -ghl is not set as default (imho).
But (imho too) it seems to me that this is a good practice to always use the -ghl parameter for each project.

This to directly see, after each change, if no memory leak was added.
And when your project is ready for release, remove that -ghl parameter to have a clean binary without any debug code added.

Fre;D
Title: Re: Wish: stop the race after Delphi
Post by: FTurtle on February 28, 2021, 06:08:41 pm
Quote from: funlw65 on February 28, 2021, 02:20:38 am
Quote from: FTurtle on February 27, 2021, 05:29:05 pm
Code: Pascal  [Select][+][-]
  1.       result := (FindFirst('*',faDirectory, _fsearch) = 0);


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

If some language has boolean type then such approach is applicable.
TinyPortal © 2005-2018