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

[msintle]

Wow yes, that's absolutely your script, as FPCUPDLX simply results in error 512 on the majority of the Linux'es I try it on - even after I've installed all the dependencies it asks for - so your script has been a lifesaver, on top of the already-life-saving FPCUPDLX.

So running that command you requested returned this:

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

1. ┌──(parallels㉿kali-linux-2024-2)-[~/Downloads]
2. └─$ dirname $(gcc --print-file-name=crtbegin.o)
3. /usr/lib/gcc/aarch64-linux-gnu/14

Definitely seems like the right one, then.

And yes, adding the dot helped me locate the Free Pascal Compiler configuration file, too.

Now I can get back to the actual torture of researching the random Linux hangs.

Sadly, now pasting the full compiler path into the configuration window doesn't seem to finish Lazarus configuration.

I've managed to obtain a stack trace, and the full screenshot is attached, so you know I'm not fabricating difficulty upon difficulty:

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

1. ┌──(parallels㉿kali-linux-2024-2)-[~]
2. └─$ /home/parallels/dev/lazarus/startlazarus
3. Info: (startlazarus) [TLazarusManager.Run] starting /home/parallels/dev/lazarus/lazarus ...
4. Info: (startlazarus) [TLazarusManager.Run] exe=/home/parallels/dev/lazarus/lazarus Params=[--started-by-startlazarus
5. --no-splash-screen
6. --force-new-instance
7. ]
8. Hint: (lazarus) [TMainIDE.ParseCmdLineOptions] PrimaryConfigPath="/home/parallels/.lazarus"
9. Hint: (lazarus) [TMainIDE.ParseCmdLineOptions] SecondaryConfigPath="/etc/lazarus"
10. AddDefaultRecentProjects: Adding default projects
11. NOTE: editor options config file not found - using defaults
12. Looking for code tools config file:  "/home/parallels/.lazarus/codetoolsoptions.xml"
13. NOTE: codetools config file not found - using defaults
14. Warning: (lazarus) incompatible Lazarus directory: /home/parallels/
15. SearchLazarusDirectoryCandidates Value=. File=/home/parallels/.lazarus
16. SearchLazarusDirectoryCandidates Value=/home/parallels/dev/lazarus File=/home/parallels/dev/lazarus
17. SearchLazarusDirectoryCandidates Value=/usr/share/lazarus File=/usr/share/lazarus
18. SearchLazarusDirectoryCandidates Value=/usr/local/share/lazarus File=/usr/local/share/lazarus
19. SearchLazarusDirectoryCandidates Value=/usr/local/lib/lazarus File=/usr/local/lib/lazarus
20. SearchLazarusDirectoryCandidates Value=/usr/local/lazarus File=/usr/local/lazarus
21. SearchLazarusDirectoryCandidates Value=/usr/lib/lazarus File=/usr/lib/lazarus
22. SearchLazarusDirectoryCandidates Value=/usr/lib/lazarus/4.99 File=/usr/lib/lazarus/4.99
23. SearchLazarusDirectoryCandidates Value=~/pascal/lazarus File=/home/parallels/pascal/lazarus
24. SearchLazarusDirectoryCandidates Value=~/lazarus File=/home/parallels/lazarus
25. SearchCompilerCandidates Value=fpc File=
26. SearchCompilerCandidates Value=ppcaarch64 File=
27. SearchCompilerCandidates Value=$(LazarusDir)/fpc/3.3.1/bin/aarch64-linux/fpc File=/home/parallels/dev/lazarus/fpc/3.3.1/bin/aarch64-linux/fpc
28. SearchCompilerCandidates Value=$(LazarusDir)/fpc/bin/aarch64-linux/fpc File=/home/parallels/dev/lazarus/fpc/bin/aarch64-linux/fpc
29. SearchCompilerCandidates Value=/usr/local/bin/fpc File=/usr/local/bin/fpc
30. SearchCompilerCandidates Value=/usr/bin/fpc File=/usr/bin/fpc
31. SearchCompilerCandidates Value=/opt/fpc/fpc File=/opt/fpc/fpc
32. SearchFPCSrcDirCandidates Value=$(LazarusDir)/fpc/$(FPCVer)/source File=/home/parallels/dev/lazarus/fpc/3.3.1/source/
33. SearchFPCSrcDirCandidates Value=$Path($(CompPath))/../../source File=/source/
34. SearchFPCSrcDirCandidates Value=/usr/share/fpcsrc/$(FPCVer) File=/usr/share/fpcsrc/3.3.1/
35. SearchFPCSrcDirCandidates Value=/usr/local/share/fpcsrc/$(FPCVer) File=/usr/local/share/fpcsrc/3.3.1/
36. SearchFPCSrcDirCandidates Value=/usr/share/fpcsrc File=/usr/share/fpcsrc/
37. SearchFPCSrcDirCandidates Value=/usr/local/share/fpcsrc File=/usr/local/share/fpcsrc/
38. SearchFPCSrcDirCandidates Value=/usr/fpcsrc File=/usr/fpcsrc/
39. SearchFPCSrcDirCandidates Value=/usr/share/fpc/src File=/usr/share/fpc/src/
40. SearchFPCSrcDirCandidates Value=/usr/fpc/src File=/usr/fpc/src/
41. SearchFPCSrcDirCandidates Value=/usr/local/fpc/src File=/usr/local/fpc/src/
42. SearchFPCSrcDirCandidates Value=/usr/local/share/fpc/src File=/usr/local/share/fpc/src/
43. SearchFPCSrcDirCandidates Value=/usr/local/src/fpc File=/usr/local/src/fpc/
44. SearchFPCSrcDirCandidates Value=/usr/lib/fpc/src File=/usr/lib/fpc/src/
45. SearchFPCSrcDirCandidates Value=/usr/local/lib/fpc/src File=/usr/local/lib/fpc/src/
46. SearchFPCSrcDirCandidates Value=/vol/fpc/src File=/vol/fpc/src/
47. SearchFPCSrcDirCandidates Value=/vol/lib/fpc/src File=/vol/lib/fpc/src/
48. SearchFPCSrcDirCandidates Value=/usr/src/fpc File=/usr/src/fpc/
49. SearchFPCSrcDirCandidates Value=/vol/src/fpc File=/vol/src/fpc/
50. SearchMakeExeCandidates Value=make File=/usr/bin/make
51. TSearchFpcSourceThread.Finishing
52. TInitialSetupDialog.ThreadTerminated
53. TApplication.HandleException: EAccessViolation
54. Access violation
55.   Stack trace:
56.   $0000FFFF8263CD00
57.   $0067FFFF828D1900
58.   $003E00000069162C
59.   $000000000050BE5C  GTK2KillFocusCBAfter,  line 108 of gtk2widgetset.inc
60.   $0000FFFF8294E700
61.   $003AFFFF82738764
62.   $0021FFFF8274FE9C
63.   $0041FFFF82750DFC
64.   $0039FFFF82757038
65.   $0047FFFF827570E0
66.   $007FFFFF82A88A60
67.   $0000FFFF82A96C84
68.   $004AFFFF82A9998C
69.   $0006FFFF82738764
70.   $007FFFFF8274FD3C
71.   $0047FFFF827515C8
72.   $0067FFFF82757038

It's probably the very same thing that's freezing/killing my application on this platform.

The intermittent nature of the issue is perfectly illustrated by the fact that pasting the full path seemed to work while I had the broken installation script for Lazarus, and no longer works properly now that I do have the working installation script for Lazarus

Edit: Logging off and then back on prevented the freeze above, somehow - but the underlying issue probably still remains, no? Do we indeed have some kind of other hard-to-reproduce bug in Lazarus, or am I hallucinating like a brand-new AI?

[rvk]

Edit: Logging off and then back on prevented the freeze above, somehow - but the underlying issue probably still remains, no? Do we indeed have some kind of other hard-to-reproduce bug in Lazarus, or am I hallucinating like a brand-new AI?

I just installed on Kali in Hyper-V (intel) but I don't get the config-dialog (for compiler and fpc directory).
(/edit/ woops, had a previous version there in ~/.lazarus so maybe the reason I didn't get the dialog)

In the script I add the FPC directory to the .profile in the home directory (~/.profile).
So, after logging out and back in, the ~/dev/fpc/bin directory should be in the path (PATH).

When starting Lazarus for the first time, it will search that path and use the fpc compiler and corresponding fpc directory.
So no dialog should be asked anymore (if you logoff and login as suggested by the message at the end of the script).

I'll try kali on a raspberry pi here to see if can get it to crash or freeze.

Where do you have a freeze or crash at the moment? (after that logoff/login)

[msintle]

Intel's an entirely other beast, which has given me the intermittent issues only on the Qt5 side of things.

Arm though, has been cause for much intermittent issue caused grief; all of which surfaced since I started facing the challenge of perfection there head-on, spurred first by the common file dialogs, and now these random crashes/freezes.

The configuration dialog always shows and your PATH setting doesn't seem to help, at least on ARM, even after reboots; as I had found out on Ubuntu. I have no idea why Lazarus's configuration dialog doesn't crash on Kali after a logoff/logon, and does crash before. Is it a threading instability issue on Linux for Lazarus? I'd already attached my stack trace above, but it hardly provides any hints; does it? I've at least gotten my builds done and will see if they provide any more clues today.

Edit: Here's where I have a reproducible crash right now, but no details yet on a minimum project to recreate it. The call stack and the unit/line of crash don't ring any bells for anyone, do they?

[rvk]

I keep having trouble compiling on Raspberry pi 3 with Kali.
It kept crashing when compiling FPC.

After increasing the swapsize it almost completed the script but crashed at the end of compiling Lazarus.

Error: /home/kali/dev/fpc/bin/ppca64 can't be executed, error message: Failed to execute "/home/kali/dev/fpc/bin/ppca64", error code: -9

Not sure if my Raspberry pi 3 is too small or there is a problem with the combination with Kali (because I never had these problems in Debian on rpi).

[msintle]

I keep having trouble compiling on Raspberry pi 3 with Kali.
It kept crashing when compiling FPC.

After increasing the swapsize it almost completed the script but crashed at the end of compiling Lazarus.

Error: /home/kali/dev/fpc/bin/ppca64 can't be executed, error message: Failed to execute "/home/kali/dev/fpc/bin/ppca64", error code: -9

With Alf we'd figured we need at least 4 GB RAM on VMs for successful compilation, in case that helps.

Not sure if my Raspberry pi 3 is too small or there is a problem with the combination with Kali (because I never had these problems in Debian on rpi).

Something's definitely wrong with Kali aarch64. Please see my immediately preceding screenshot above. It is a new post even though it shows before yours (reply #167).

Edit: Trying to come up with a reproducing pattern, here's some of the innocently choice actions I've spotted:

- Changing tabs on my product
- Opening the Find dialog in Lazarus

Any of these can literally trigger the freeze of the running host app (my own or Lazarus itself). And be nearly impossible to reproduce on next run.

[rvk]

Seems like Kali is a lot more memory hungry.

I changed the swap space to 4GB (from 1GB) and now FPC/Lazarus compiles correctly.
(No more freezes and crashes during compilation)

No further problems detected with running a small test project.

(Raspberry pi 3 with Kali and trunk FPC/Lazarus)

[msintle]

Seems like Kali is a lot more memory hungry.

I changed the swap space to 4GB (from 1GB) and now FPC/Lazarus compiles correctly.
(No more freezes and crashes during compilation)

No further problems detected with running a small test project.

(Raspberry pi 3 with Kali and trunk FPC/Lazarus)

Do you have something more involved you could try out? That might hopefully expose some issues.

BTW I just realized my own Kali VM has only 2 GB RAM allocated to it - wow! Your script still ran successfully, installing Lazarus; and my project also built entirely successfully; but I'll repeat all tests with 4 GB RAM too, just to be safe.

Would be such a relief if the oddities turned out due to RAM issues. I'm not holding my breath, although there's always hope, I suppose.

[msintle]

So this is what the issue was - if I set focus on the parent control immediately after hiding a child control, this sometimes, and only sometimes, causes problems with some GTK2 aarch64 Linux distributions.

The solution I've implemented is to trigger a Timer to do the focusing shortly after the hiding, which is an ultra dirty solution, but it works.

[rvk]

if I set focus on the parent control immediately after hiding a child control, this sometimes, and only sometimes, causes problems with some GTK2 aarch64 Linux distributions.

So, you hide a component that has focus, and then set focus to the parent???
I don't think you can (or should be able) to hide a control that has focus !!!

Make a test project showing this and create a bugreport.

[msintle]

Why not?

Let's say the user presses ESC on the focused control, because (s)he doesn't want it showing anymore.

Then I hide it and focus the parent control, which works fine on macOS, most Linux'es, and Windows, and Delphi.

Since this involves custom controls, I'm not sure how readily it'll reproduce with generics. If I get to it, I'll update this thread.

[Thaddy]

Why not?

Let's say the user presses ESC on the focused control, because (s)he doesn't want it showing anymore.

Simply because pressing ESC used to mean it should return to the OS, NOT to the program. That is why it is called ESCape,
What is so difficult to understand? Tied to Windows or Linux or Widgetset?

[rvk]

Then I hide it and focus the parent control, which works fine on macOS, most Linux'es, and Windows, and Delphi.

You first need to shift the focus BEFORE you can hide that control.
A hidden control can't have focus (it'll give you an error).

And if you try this in an event, it can also have strange effects.

That's why I said you need to put this in a sample project showing the problem. Maybe you are doing things the wrong way. And if it is a bug, it can je used to show that.

[msintle]

Why not?

Let's say the user presses ESC on the focused control, because (s)he doesn't want it showing anymore.

Simply because pressing ESC used to mean it should return to the OS, NOT to the program. That is why it is called ESCape,
What is so difficult to understand? Tied to Windows or Linux or Widgetset?

Maybe I'm an idiot, and that's why I'm having a hard time to understand, but:

When you close a modal dialog in your application using ESC, for example; control doesn't really return to the OS, but whatever main window is your app itself, right?

[msintle]

Then I hide it and focus the parent control, which works fine on macOS, most Linux'es, and Windows, and Delphi.

You first need to shift the focus BEFORE you can hide that control.
A hidden control can't have focus (it'll give you an error).

And if you try this in an event, it can also have strange effects.

That's why I said you need to put this in a sample project showing the problem. Maybe you are doing things the wrong way. And if it is a bug, it can je used to show that.

But I'm not trying to focus a hidden control at all. The control I'm hiding when ESC is pressed is a child of the still visible parent control.

[rvk]

But I'm not trying to focus a hidden control at all. The control I'm hiding when ESC is pressed is a child of the still visible parent control.

Your missing my point.
You said you first hide the control and THEN set focus to the parent.
That's not possible.

You first set focus to the parent and THEN hide the (sub)control.

See the difference (order).

How or what you are actually doing doesn't matter. As long as you don't show any code, this is a non-issue. If you want something resolved (because of a bug or programming error), you need to show the code.