Common File Dialogs Have Been Broken for a Very Long Time (Ex: Ubuntu AARCH64)

[msintle]

OK, so next issue. I was able to reproduce some of the random crashes I've been reported by QA - even after our infamous fix here - and they turn out to be something utterly unrelated, of course.

This code crashes on Ubuntu aarch64 Lazarus latest trunk with the fix herein:

TStringList(ListBox1.Items).Sorted := True;

Whereas this code works properly:

ListBox1.Sorted := True;

Is that the expected behavior?

I suspect this might also have to do with the Qt5 Intel random crashes/bugs on Linux, but that is TBD.

[marcov]

Is that the expected behavior?

Yes.  tListbox.items is a TStrings derivative, but not necessarily TStringList.

[msintle]

Is that the expected behavior?

Yes.  tListbox.items is a TStrings derivative, but not necessarily TStringList.

I believe this behavior is divergent from Delphi and inconsistent even amongst versions/operating systems of Lazarus editions.

[TRon]

I believe this behavior is divergent from Delphi and inconsistent even amongst versions/operating systems of Lazarus editions.

Delphi only had to worry about a single target while Lazarus supports many.

How the widgetset implements a particular feature/behaviour depends on the interface that it relies on. see also architecture scheme at the right.

Also in Delphi days the cast is/was considered bad coding style.

[marcov]

I believe this behavior is divergent from Delphi and inconsistent even amongst versions/operating systems of Lazarus editions.

No it isn't. Delphi doesn't specify anything else either: https://docwiki.embarcadero.com/Libraries/Sydney/en/Vcl.StdCtrls.TCustomListBox.Items

So if it happened to work in your older code, that is an undetected bug and a classic example that working code is not necessarily correct. It might just be that the memory layout doesn't get corrupted in some sensitive way by the typecast.

I don't know if Delphi has an equivalent to -CR, but if it had, I would use it on that code   I actually debugged many old Delphi unit tests with FPC checks on maximum to find such cases.

[msintle]

I believe this behavior is divergent from Delphi and inconsistent even amongst versions/operating systems of Lazarus editions.

Delphi only had to worry about a single target while Lazarus supports many.

How the widgetset implements a particular feature/behaviour depends on the interface that it relies on. see also architecture scheme at the right.

Also in Delphi days the cast is/was considered bad coding style.

Fair, but I guess then the question is what underlying storage would be used instead of TStringList for such a control, ex: in the real world with Lazarus and GTK2, what type of string storage is the control possibly using on aarch64?

[marcov]

Fair, but I guess then the question is what underlying storage would be used instead of TStringList for such a control, ex: in the real world with Lazarus and GTK2, what type of string storage is the control possibly using on aarch64?

TStrings is abstract and could use e.g. items stored in the widget.  As for aarch64, as it is faulty code, it might simply that the architecture has a slightly different memory layout that brings the bug to the surface.

[msintle]

OK, get ready for the next inanity.

When I compile with Lazarus trunk on Debian 12.6 hosted by aarch64, and then run strip on the affected file; it explodes in the TListBox.Sorted := True statement.

However, this does not happen if I don't strip the file.

Does this make any sense whatsoever?

Edit: That wasn't it. Right now on Debian 12.6 hosted by aarch64 (having to fall back here due to other problems with the customary Ubuntu VM above), running the non-stripped binary from the console gives this error:

Gtk-CRITICAL **: 20:39:27.480: IA__gtk_tree_model_iter_nth_child: assertion 'n >= 0' failed

But running it from the Lazarus IDE inside the debugger causes no problems.

[msintle]

Got Ubuntu back up and running, and there's the call stack and the line which errors out. Does that mean anything?

Edit: I was able to trace the code line by line and it has nothing to do with TListBox.Sorted. After the dialog stars showing the issue happens very intermittently. If I keep tracing the execution, the application message loop seems processing normally. The moment I hit F9, it may or may not work properly. When it crashes, the crash location is the same as in the screenshot.

[msintle]

To work around this issue, I went back to my original build environment for aarch64 Linux, which is a Debian 11. The binaries produced by that Lazarus version work fine only on Debian aarch64 (with the .sorted fix and the initialization widgetset fix), but fail on Ubuntu aarch64 (since the proper widgetset fix is available only with trunk, and trunk causes other problems as described in the immediately preceding posts).

Being fully stuck with the current state of affairs, and yet still being unable to let this go much to my detriment (and yours since you're reading this), I figured I'd install Lazarus trunk on another "randomly freezing" aarch64 Linux, namely, Kali 2024.2. The installation went by without a hitch - thanks to that great installation script. When configuring the Lazarus IDE though, the IDE itself bombs right when I'm typing the full path to my fpc executable.

By bomb, I mean it freezes and stops responding. Running Lazarus from console, we see some kind of output (attached) that may be meaningful towards a resolution?

Either that, or I really need to find the strength somewhere, somehow, to let this line of inquiry go?

[msintle]

Got through that by pasting the entire path using the right-click menu.
Now when I'm building my app, the build process craps out with this error:
Error: /usr/x86_64-w64-mingw32/lib/crtbegin.o: file not recognized: file format not recognized
Fortunately, this reproduces with a blank LCL project too, instantly.

[rvk]

Now when I'm building my app, the build process craps out with this error:
Error: /usr/x86_64-w64-mingw32/lib/crtbegin.o: file not recognized: file format not recognized

x86_64-w64-mingw32 ?? On Debian (or Kali) ??
I can't keep up with what you are trying to do.

Are you trying to cross-compile to win64/32 target?
If not... you might want to check your fpc.cfg and remove the -Fl/usr/x86_64-w64-mingw32/lib line.

Or actually you should check the correct location of a correct crtbegin.o file.

Code: Bash  [Select][+][-]

1. find / -name crtbegin.o -printf '%h\n' 2>/dev/null

if there are multiple folders found, and /usr/x86_64-w64-mingw32/lib is the first, then that's probably the wrong one and you need to manually adjust it to the correct one.

[msintle]

Now when I'm building my app, the build process craps out with this error:
Error: /usr/x86_64-w64-mingw32/lib/crtbegin.o: file not recognized: file format not recognized

x86_64-w64-mingw32 ?? On Debian (or Kali) ??
I can't keep up with what you are trying to do.

I don't blame you.

I'm trying to iron out all Linux bugs - random freezes, crashes, etc.

It has been extremely challenging.

Are you trying to cross-compile to win64/32 target?
If not... you might want to check your fpc.cfg and remove the -Fl/usr/x86_64-w64-mingw32/lib line.

Not at all. I am trying to compile a Linux GTK2 aarch64 Lazarus LCL binary on Kali 2024.2 and have it run without freezing and/or other odd lockup issues.

Or actually you should check the correct location of a correct crtbegin.o file.

Code: Bash  [Select][+][-]

1. find / -name crtbegin.o -printf '%h\n' 2>/dev/null

Thank you for that. So that returns:

Code: Bash  [Select][+][-]

1. ┌──(parallels㉿kali-linux-2024-2)-[~]
2. └─$ find / -name crtbegin.o -printf '%h\n' 2>/dev/null
3. /usr/x86_64-w64-mingw32/lib
4. /usr/i686-w64-mingw32/lib
5. /usr/lib/gcc/x86_64-w64-mingw32/13-win32
6. /usr/lib/gcc/aarch64-linux-gnu/14
7. /usr/lib/gcc/aarch64-linux-gnu/13
8. /usr/lib/gcc/i686-w64-mingw32/13-win32

if there are multiple folders found, and /usr/x86_64-w64-mingw32/lib is the first, then that's probably the wrong one and you need to manually adjust it to the correct one.

How do I do that? There were no fpc.cfg files found, does this mean the Free Pascal Compiler failed to install properly?

[rvk]

Thank you for that. So that returns:

Code: Bash  [Select][+][-]

1. ┌──(parallels㉿kali-linux-2024-2)-[~]
2. └─$ find / -name crtbegin.o -printf '%h\n' 2>/dev/null
3. /usr/x86_64-w64-mingw32/lib
4. /usr/i686-w64-mingw32/lib
5. /usr/lib/gcc/x86_64-w64-mingw32/13-win32
6. /usr/lib/gcc/aarch64-linux-gnu/14
7. /usr/lib/gcc/aarch64-linux-gnu/13
8. /usr/lib/gcc/i686-w64-mingw32/13-win32

Ha, did you install that with my script?
On that particular OS you have mingw installed with multiple crtbegin.o versions.
My script just expected a clean OS with one version.

You probably want this one
/usr/lib/gcc/aarch64-linux-gnu/14
(And not the one from mingw)

if there are multiple folders found, and /usr/x86_64-w64-mingw32/lib is the first, then that's probably the wrong one and you need to manually adjust it to the correct one.

How do I do that? There were no fpc.cfg files found, does this mean the Free Pascal Compiler failed to install properly?

The config file for fpc is saved to the home directory of the user in
.fpc.cfg
(Note the dot in front so it's a hidden file)

Do this and it will open.
nano ~/.fpc.cfg

Now search at the bottom for that mingw directory and change the directory to the one above.

Code: Pascal  [Select][+][-]

1.  -Fl/usr/lib/gcc/aarch64-linux-gnu/14

I need to change the script to always search for the crtbegin.o in the correct architecture and not take the first one it finds 

[rvk]

BTW. Can you check if this gives the same directory?
(I could use this in the script instead of find)

Code: Bash  [Select][+][-]

1. dirname $(gcc --print-file-name=crtbegin.o)

/edit/
Ok, I changed this in my script and it seems to take the correct gcc lib directory.

Code: Bash  [Select][+][-]

1. cat << EOF >> $HOME/.fpc.cfg
2. -Fu$BASE/fpc/lib/fpc/\$fpcversion/units/\$fpctarget
3. -Fu$BASE/fpc/lib/fpc/\$fpcversion/units/\$fpctarget/*
4. -Fu$BASE/fpc/lib/fpc/\$fpcversion/units/\$fpctarget/rtl
5. -Fl$(dirname $(gcc --print-file-name=crtbegin.o))
6. -FD$BASE/fpc/bin
7. EOF