Recent

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

JuhaManninen

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 4459
  • I like bugs.
Re: Wish: stop the race after Delphi
« Reply #30 on: December 27, 2020, 05:37:56 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.
Mostly Lazarus trunk and FPC 3.2 on Manjaro Linux 64-bit.

PascalDragon

  • Hero Member
  • *****
  • Posts: 5446
  • Compiler Developer
Re: Wish: stop the race after Delphi
« Reply #31 on: December 28, 2020, 01:11:13 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.

funlw65

  • Full Member
  • ***
  • Posts: 148
    • Visual Pin Configurator for Nucleo 64pin boards
Re: Wish: stop the race after Delphi
« Reply #32 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?
FreePascal 3.2.2, C 10.2.1, D 1.24 under Linux(init,musl,glibc), DragonflyBSD, NetBSD
gui: gtk2, qt5, raylib4.x+raygui3.x, nanovg 
tui: freevision, tvision2, termbox2+widgets, finalcut
db: typhoon-1.11...

PascalDragon

  • Hero Member
  • *****
  • Posts: 5446
  • Compiler Developer
Re: Wish: stop the race after Delphi
« Reply #33 on: December 29, 2020, 11:29:12 am »
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).

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).

funlw65

  • Full Member
  • ***
  • Posts: 148
    • Visual Pin Configurator for Nucleo 64pin boards
Re: Wish: stop the race after Delphi
« Reply #34 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
« Last Edit: January 05, 2021, 07:44:33 am by funlw65 »
FreePascal 3.2.2, C 10.2.1, D 1.24 under Linux(init,musl,glibc), DragonflyBSD, NetBSD
gui: gtk2, qt5, raylib4.x+raygui3.x, nanovg 
tui: freevision, tvision2, termbox2+widgets, finalcut
db: typhoon-1.11...

dbannon

  • Hero Member
  • *****
  • Posts: 2786
    • tomboy-ng, a rewrite of the classic Tomboy
Re: Wish: stop the race after Delphi
« Reply #35 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.

« Last Edit: January 05, 2021, 09:04:17 am by dbannon »
Lazarus 3, Linux (and reluctantly Win10/11, OSX Monterey)
My Project - https://github.com/tomboy-notes/tomboy-ng and my github - https://github.com/davidbannon

funlw65

  • Full Member
  • ***
  • Posts: 148
    • Visual Pin Configurator for Nucleo 64pin boards
Re: Wish: stop the race after Delphi
« Reply #36 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.
« Last Edit: January 05, 2021, 08:23:59 am by funlw65 »
FreePascal 3.2.2, C 10.2.1, D 1.24 under Linux(init,musl,glibc), DragonflyBSD, NetBSD
gui: gtk2, qt5, raylib4.x+raygui3.x, nanovg 
tui: freevision, tvision2, termbox2+widgets, finalcut
db: typhoon-1.11...

PascalDragon

  • Hero Member
  • *****
  • Posts: 5446
  • Compiler Developer
Re: Wish: stop the race after Delphi
« Reply #37 on: January 05, 2021, 08:52:40 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?

dbannon

  • Hero Member
  • *****
  • Posts: 2786
    • tomboy-ng, a rewrite of the classic Tomboy
Re: Wish: stop the race after Delphi
« Reply #38 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

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?
Lazarus 3, Linux (and reluctantly Win10/11, OSX Monterey)
My Project - https://github.com/tomboy-notes/tomboy-ng and my github - https://github.com/davidbannon

PascalDragon

  • Hero Member
  • *****
  • Posts: 5446
  • Compiler Developer
Re: Wish: stop the race after Delphi
« Reply #39 on: January 05, 2021, 09:06:17 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. ;)

dbannon

  • Hero Member
  • *****
  • Posts: 2786
    • tomboy-ng, a rewrite of the classic Tomboy
Re: Wish: stop the race after Delphi
« Reply #40 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
Lazarus 3, Linux (and reluctantly Win10/11, OSX Monterey)
My Project - https://github.com/tomboy-notes/tomboy-ng and my github - https://github.com/davidbannon

funlw65

  • Full Member
  • ***
  • Posts: 148
    • Visual Pin Configurator for Nucleo 64pin boards
Re: Wish: stop the race after Delphi
« Reply #41 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.
« Last Edit: January 05, 2021, 10:09:04 am by funlw65 »
FreePascal 3.2.2, C 10.2.1, D 1.24 under Linux(init,musl,glibc), DragonflyBSD, NetBSD
gui: gtk2, qt5, raylib4.x+raygui3.x, nanovg 
tui: freevision, tvision2, termbox2+widgets, finalcut
db: typhoon-1.11...

JuhaManninen

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 4459
  • I like bugs.
Re: Wish: stop the race after Delphi
« Reply #42 on: January 05, 2021, 12:34:16 pm »
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.
Mostly Lazarus trunk and FPC 3.2 on Manjaro Linux 64-bit.

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: Wish: stop the race after Delphi
« Reply #43 on: January 05, 2021, 12:46:15 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
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & 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

  • Full Member
  • ***
  • Posts: 148
    • Visual Pin Configurator for Nucleo 64pin boards
Re: Wish: stop the race after Delphi
« Reply #44 on: January 05, 2021, 06:08:51 pm »
Thank you for advices, now I know how to hunt :)
FreePascal 3.2.2, C 10.2.1, D 1.24 under Linux(init,musl,glibc), DragonflyBSD, NetBSD
gui: gtk2, qt5, raylib4.x+raygui3.x, nanovg 
tui: freevision, tvision2, termbox2+widgets, finalcut
db: typhoon-1.11...

 

TinyPortal © 2005-2018