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

[msintle]

Anyways, thanks to everyone for their help in nailing this one down.

We've made Lazarus all the better for it, I believe it was quite an embarrassment for it to not have working common file/folder dialogs on all aarch64 Linux platforms!

[rvk]

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.

Why wouldn't the sample for Qt5 not run on Ubuntu? Of course you need to install some qt5 dependencies but it should be possible.
(We already figured out it was only on gtk2 but I thought I mention it )

O, and just FYI. I just installed Ubuntu 24.10 on bare metal Raspberry pi 4 2GB (before I repurpose that pi).
The problem still doesn't occur there

Lots of fun... when an error only happens in certain circumstances

[marcov]

The latter IS a bug in fpc, because it should raise EDivisionByZero. I will try and test it.
But do not mask out everything unless you know what you are masking.
I believe Jonas made a similar remark a couple of years ago.

(it also depends on how much context/information the signal handler gets to derive the exact kind of SIGFPE. I can remember that with the initial FreeBSD implementation that was quite a journey, since not much was documented)

[msintle]

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.

Why wouldn't the sample for Qt5 not run on Ubuntu? Of course you need to install some qt5 dependencies but it should be possible.
(We already figured out it was only on gtk2 but I thought I mention it )

O, and just FYI. I just installed Ubuntu 24.10 on bare metal Raspberry pi 4 2GB (before I repurpose that pi).
The problem still doesn't occur there

Lots of fun... when an error only happens in certain circumstances

for cute five, I use Kali and Fedora - no issues with either, regarding the common dialogs (they already have all the dependencies installed out of the box [I see that either GTK2 or Qt5 builds work on 95% of distributions]).

I honestly have no clue why your pi is such an exception, I bet if you virtualized Linux there, you'd be able to reproduce the problem.

[rvk]

I honestly have no clue why your pi is such an exception, I bet if you virtualized Linux there, you'd be able to reproduce the problem.

You lost that bet 

I also installed Ubuntu 20.04 in a virtual machine (on Proxmox 8 on Rasbian lite).
Still no problem.

BTW. Is VMWare free now?
I couldn't find VMware ESXi to install on the pi (whole flings.vmware.com seems to be down).

I also couldn't find Ubuntu Desktop for ARM.
(RPI has a Ubuntu Desktop image in its own Raspberry pi imager but I couldn't find a normal clean download for ARM)

So I now installed Ubuntu Server (which can be found easily) and converted it to ubuntu-desktop (which didn't reproduce the problems).

(my script said: Running on: KVM Virtual Machine under proxmox so it is virtualized.)

[msintle]

I honestly have no clue why your pi is such an exception, I bet if you virtualized Linux there, you'd be able to reproduce the problem.

You lost that bet 

I also installed Ubuntu 20.04 in a virtual machine (on Proxmox 8 on Rasbian lite).
Still no problem.

BTW. Is VMWare free now?
I couldn't find VMware ESXi to install on the pi (whole flings.vmware.com seems to be down).

I also couldn't find Ubuntu Desktop for ARM.
(RPI has a Ubuntu Desktop image in its own Raspberry pi imager but I couldn't find a normal clean download for ARM)

So I now installed Ubuntu Server (which can be found easily) and converted it to ubuntu-desktop (which didn't reproduce the problems).

(my script said: Running on: KVM Virtual Machine under proxmox so it is virtualized.)

Wouldn't be the first bet I've lost, for sure; but - I'd try with the latest Ubuntu versions (24.x) just for good measure.

Martin also mentioned several scenarios he's seen with Lazarus behaving differently under virtualization - so I'm more than happy to stand corrected, as ever.

VMware is free on macOS (it's called VMware Fusion), probably because the product is subpar quality compared to Parallels.

I've always used the Parallels automated download process for Ubuntu desktop releases so never really had to dig manually.

I tried the manual digging approach now and, joy, it's hell. Couldn't figure it out! Maybe just try with Debian aarch64 instead, which also reproduces for me? 12.6.

[rvk]

Wouldn't be the first bet I've lost, for sure; but - I'd try with the latest Ubuntu versions (24.x) just for good measure.

24.04 is the latest LTS. And I don't really think 24.10 would make any difference (and you said you could also reproduce it on 22.04).

VMware is free on macOS (it's called VMware Fusion), probably because the product is subpar quality compared to Parallels.

I can't download VMWare anywhere. Also not VMWare ESXi (broken links and pages) and I don't think VMWare Fusion can run on a pi.

Maybe just try with Debian aarch64 instead, which also reproduces for me? 12.6.

I just fired up a version of Debian 12.7 (latest) in proxmox. Also works 

So I guess I'm out of ideas and this can't be reproduced here on aarch64 (virtual or bare metal).

[msintle]

So I guess I'm out of ideas and this can't be reproduced here on aarch64 (virtual or bare metal).

I believe now is when we throw in the proverbial towel.

[Martin_fr]

Ok, most likely this is not a match to the issue here. I throw it in anyway. Just in case....

There is an issue (apparently mainly) with modal forms: https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/41041

File dialogs are modal. Depending on the Windowmanager, and the exact versions of whatever libraries are involved => its possible that its triggering this.

My - frankly extremely limited - understanding is, that in most cases the routines in gtk recognize the wrong data, and give some error and think work out. But, that isn't guaranteed.


Another approach might be: valgrind. (if that is avail for arch)

If by any chance any data is freed or uninitialized, then valgrind may identify that, even if the access to it happens deep in gtk. But, you also will get a lot of noise, as in most cases gtk itself triggers warnings.

[TRon]

I can't download VMWare anywhere. Also not VMWare ESXi (broken links and pages) and I don't think VMWare Fusion can run on a pi.

Probably to do with the fact that vmware was acquired by broadcom. Their clients are dropped in favour of some open source kvm software now. I did not manage to store all details on that topic into my brain 

[rvk]

Yeah, that's why I used Proxmox to test it on the pi.
Proxmox uses QEMU/KVM under the hood for full virtualization.

You could use QEMU on Windows x64 to emulate aarch64 but then you would really have emulation, not virtualization. I wonder how slow that will be

[msintle]

Ok, most likely this is not a match to the issue here. I throw it in anyway. Just in case....

There is an issue (apparently mainly) with modal forms: https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/41041

File dialogs are modal. Depending on the Windowmanager, and the exact versions of whatever libraries are involved => its possible that its triggering this.

My - frankly extremely limited - understanding is, that in most cases the routines in gtk recognize the wrong data, and give some error and think work out. But, that isn't guaranteed.


Another approach might be: valgrind. (if that is avail for arch)

If by any chance any data is freed or uninitialized, then valgrind may identify that, even if the access to it happens deep in gtk. But, you also will get a lot of noise, as in most cases gtk itself triggers warnings.

I'm afraid you may be correct.

Our QA ran additional tests on x86_64 Linux platforms with GTK2 and Qt5, and we ran into similar issues, lockups, freezes across some choice variants:

aarch64 GTK2 Ubuntu & Kali: Random freezes, which happen when you, for example, cancel out of some modal dialogs (not even common file dialogs) we show on  our own; but don't happen when you take other actions (completing the modal dialog actions) without cancelling them.

x86_64 Qt5 Centos, Fedora: Random crashes after a common file dialog is shown successfully - whereby the entire app immediately terminates. To be fair, the workaround code above was only implemented for the aarch64 platform, so it may have prevented these issues as well. We're doing further testing to clarify.

At any rate, running Lazarus itself on affected platforms consistently reproduces the issues, sooner or later (ex: you can just delve into the Lazarus settings dialog, and/or use its standard file dialog boxes, to easily reproduce the crashes as mentioned earlier).

The problems also tend to reproduce with more complex projects, and can be somehow far more elusive in simpler projects.

I realize all of this is anecdotal evidence so please by all means feel free to treat it as such, I am primarily just confirming Martin_fr's suspicions here.

[msintle]

I can't download VMWare anywhere. Also not VMWare ESXi (broken links and pages) and I don't think VMWare Fusion can run on a pi.

Probably to do with the fact that vmware was acquired by broadcom. Their clients are dropped in favour of some open source kvm software now. I did not manage to store all details on that topic into my brain 

News today is that Broadcom, probably to manage their spiraling PR scandal, has made VMware Workstation 100% free (as Fusion already was), together with the promise of regular updates.

You get this sign-in page:

https://access.broadcom.com/default/ui/v1/signin/

After which apparently products are available for download for all platforms.

VMware's still my #1 choice on Windows, as I find Hyper-V absolutely insufferable.

[msintle]

Yeah, that's why I used Proxmox to test it on the pi.
Proxmox uses QEMU/KVM under the hood for full virtualization.

You could use QEMU on Windows x64 to emulate aarch64 but then you would really have emulation, not virtualization. I wonder how slow that will be

Is QEMU actually a hypervisor now, I thought it was always emulating everything?

That could certainly explain why you're seeing (partially at least) different behavior, but I've been out of the QEMU loop so it may have well become its own hypervisor.

[Martin_fr]

Run it from a console, so you can see if any warnings a printed.

Also there is a (I think) --sync option, and then if a stacktrace is printed it should be useful (assuming you also have debug info, and can resolve it).

For all else, and even the results of above debug stuff, I need to leave that to those with more Linux experience than me.