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

[msintle]

I have observed this issue for 2+ years and counting, it seems to affect Linux distributions primarily.

Run a Lazarus built app that uses common file dialogs, and the app crashes/freezes when you try to open/save a file, etc.

The same thing happens with Lazarus itself, so it is near impossible to try and manually create a reproducing project on affected systems.

I have been observing this phenomenon on Ubuntu Linux's countless versions, most recently 24.x, and before that, 22.x, running under the aarch64 CPU architecture.

I can't imagine I'm the only one seeing this, but the issue has not been resolved despite years of progress (literally), so thought I'd finally make a dedicated post for it.

Again, it is really hard to actually provide a reproducing project, since Lazarus itself cannot successfully run on the affected platforms.

How do we start triage for this issue?

[dsiders]

I have observed this issue for 2+ years and counting, it seems to affect Linux distributions primarily.

Run a Lazarus built app that uses common file dialogs, and the app crashes/freezes when you try to open/save a file, etc.

The same thing happens with Lazarus itself, so it is near impossible to try and manually create a reproducing project on affected systems.

I have been observing this phenomenon on Ubuntu Linux's countless versions, most recently 24.x, and before that, 22.x, running under the aarch64 CPU architecture.

I can't imagine I'm the only one seeing this, but the issue has not been resolved despite years of progress (literally), so thought I'd finally make a dedicated post for it.

Again, it is really hard to actually provide a reproducing project, since Lazarus itself cannot successfully run on the affected platforms.

How do we start triage for this issue?

Which dialog routine specifically? Do you have a small example that demonstrates? Without specifics, everyone will just be guessing.

[Laksen]

Is that with custom themes?

[msintle]

Is that with custom themes?

All standard themes.

[msintle]

Which dialog routine specifically? Do you have a small example that demonstrates? Without specifics, everyone will just be guessing.

Standard TOpenDialog.Execute, for example, will reproduce the issue instantly.

All standard file dialogs are broken on affected Linux'es.

[Bart]

Broken as in ...?

Bart

[dsiders]

Which dialog routine specifically? Do you have a small example that demonstrates? Without specifics, everyone will just be guessing.

Standard TOpenDialog.Execute, for example, will reproduce the issue instantly.

All standard file dialogs are broken on affected Linux'es.

I am using both 3.6 and main on Linux (OpenSuse) x86-64. No problems there.

[wp]

Run a Lazarus built app that uses common file dialogs, and the app crashes/freezes when you try to open/save a file, etc.

The same thing happens with Lazarus itself, so it is near impossible to try and manually create a reproducing project on affected systems.

Are these applications running standalone, or inside Lazarus, i.e. inside the debugger? In the latter case: which debugger are you using? gdb? Switch to fpdebug.

[msintle]

Which dialog routine specifically? Do you have a small example that demonstrates? Without specifics, everyone will just be guessing.

Standard TOpenDialog.Execute, for example, will reproduce the issue instantly.

All standard file dialogs are broken on affected Linux'es.

I am using both 3.6 and main on Linux (OpenSuse) x86-64. No problems there.

As mentioned above and in the title, the failures occur on aarch64.

[msintle]

Run a Lazarus built app that uses common file dialogs, and the app crashes/freezes when you try to open/save a file, etc.

The same thing happens with Lazarus itself, so it is near impossible to try and manually create a reproducing project on affected systems.

Are these applications running standalone, or inside Lazarus, i.e. inside the debugger? In the latter case: which debugger are you using? gdb? Switch to fpdebug.

Again as aforementioned, you can't run inside Lazarus either, because Lazarus's open dialogs also fail - so you can't even install your packages, load your project, etc. on affected systems.

[dsiders]

Which dialog routine specifically? Do you have a small example that demonstrates? Without specifics, everyone will just be guessing.

Standard TOpenDialog.Execute, for example, will reproduce the issue instantly.

All standard file dialogs are broken on affected Linux'es.

I am using both 3.6 and main on Linux (OpenSuse) x86-64. No problems there.

As mentioned above and in the title, the failures occur on aarch64.

You implied is was a problem on Linux's in general. I'm confirming that it's not a problem on other CPU architectures.

Rather than dribble info out, post your Help > About content and identify where your install came from. Ubuntu provided Deb packages are broken in general. Is it installed in a /home directory?

[msintle]

You implied is was a problem on Linux's in general. I'm confirming that it's not a problem on other CPU architectures.

Rather than dribble info out, post your Help > About content and identify where your install came from. Ubuntu provided Deb packages are broken in general. Is it installed in a /home directory?

Here's a reproducing project, including binaries for both GTK2 and Qt5 on aarch64.

I created the sample on aarch64 Qt5 Kali 2022 with Lazarus 2.3, where the dialog is shown normally, and Lazarus works, somewhat normally (unlike in the demo app, it takes nearly 30 seconds for the Lazarus standard file dialogs to display on screen).

I then compiled this sample on aarch64 GTK2 Debian 11 with Lazarus 3.99 installed by FPCUPDLX, where the dialog is again shown normally, and Lazarus works, entirely normally.

Now trying the GTK2 binary on Ubuntu 24.01, 22.04, etc. reproduces the issue instantly. The Qt5 sample doesn't run at all on Ubuntu, of course.

I do hope this helps. If you dig deeper, you may find more widgets/OS's that don't work with the standard file dialogs in this way; but at least we have a starting point here. Thanks!

Edit: Since the ZIP file size is too big for the forum due to the compiled binaries, I've uploaded it here instead (the transfer expires in 3 days, so if somebody has a more permanent solution, please help with a permanent link):

https://we.tl/t-ADOx4no1gM

[dbannon]

....
How do we start triage for this issue?

Strange, I thought I posted an answer to this yesterday.

Anyway, msintle, I am guessing that you are using a Raspberry Pi ?  You don't mention but "linux" and "AARCH64" ...

In case you are, firstly, I suggest a memcheck.  Secondly, consider your power supply.  Unfortunately, Raspberry PI no longer works on "any old phone charger", you need need a 5v 3Amp supply and that is a lot of current through a small cable and connector.  Most devices that use substantial power use the USB protocols that can up the voltage and drop the current.

What you describe does sound to me like a power issues (on a raspberry pi).

I routinely test my app on 64bit Raspberry Pi, no problems. Both gtk2 and Qt5

Davo 

[msintle]

Strange, I thought I posted an answer to this yesterday.

Anyway, msintle, I am guessing that you are using a Raspberry Pi ?  You don't mention but "linux" and "AARCH64" ...

In case you are, firstly, I suggest a memcheck.  Secondly, consider your power supply.  Unfortunately, Raspberry PI no longer works on "any old phone charger", you need need a 5v 3Amp supply and that is a lot of current through a small cable and connector.  Most devices that use substantial power use the USB protocols that can up the voltage and drop the current.

What you describe does sound to me like a power issues (on a raspberry pi).

I routinely test my app on 64bit Raspberry Pi, no problems. Both gtk2 and Qt5

Davo

Nope, not even close.

VMs running on Parallels on an M3 Submax.

The issue(s) are real, please take the reports seriously - thank you very much.

[mas steindorff]

we were seeing something similar when we built our exe with Lazarus 2.4 with 32 bit target and ran on a 64 bit windows OS.  In our case, the OpenFileDialog would take 20 to 30 seconds.
I used this as the main excuse to update to 3.4 where the same code compiled for either 32 bit or 64 bit opens the dialog within 2 seconds.