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

[msintle]

msintle,
    have you ever observed these problems when not running within a VM? if not, are you able to test without a VM?

the reason i ask, is that it may be that the 'Common File Dialogs' contain a defect that is only revealed when runnning within a VM. that does not make the defect in said dialogs any less real, but it does mean that it can only be diagnosed back to the root cause by someone running within a VM - possibly even requiring the specific version of Parallels you are using, and on the specific aarch64 implementation that the M3 contains.

I'm not even sorry to have to say that if that's your line of thinking, you're absolutely unqualified to be posting here on this topic.

[robert rozee]

i am trying to help you diagnose the very real problem you have discovered with the Common File Dialogs. the first step to doing this is to arrive at what are the essential elements required for others to reproduce the behaviour.

to date, am i right in saying that to observe the problems one needs:

Ubuntu 24.04 for aarch64,
recent release of FPC and Lazarus for aarch64,
M3 Submax,
recent OSX,
and Parallels VM software.


cheers,
rob   :-)

[hansotten]

tion that the M3 contains.

I'm not even sorry to have to say that if that's your line of thinking, you're absolutely unqualified to be posting here on this topic.
[/quote]

I hope you understand that with your way of expressing yourself in this thread you are not getting much help. Please behave yourself in this forum.

[rvk]

It reproduces on the latest Debian 12.6, Ubuntu 24.04, Kali 2024.2, all fresh clean installs (all aarch64 GTK2).

I can NOT confirm. Works fine for me.

Debian GNU/Linux 12 (bookworm)
Lazarus 4.99 (rev main_4_99-471-gaef3e62e80) FPC 3.3.1 aarch64-linux-gtk2

[msintle]

i am trying to help you diagnose the very real problem you have discovered with the Common File Dialogs. the first step to doing this is to arrive at what are the essential elements required for others to reproduce the behaviour.

to date, am i right in saying that to observe the problems one needs:

Ubuntu 24.04 for aarch64,
recent release of FPC and Lazarus for aarch64,
M3 Submax,
recent OSX,
and Parallels VM software.


cheers,
rob   :-)

I believe that recaps what I have stated, although I'd be very surprised if the issue didn't reproduce on aarch64 Linux'es running natively, or on another hypervisor. IOW the M3 Submax/OSX/Parallels stuff ought hardly be necessary.

[msintle]

tion that the M3 contains.

I'm not even sorry to have to say that if that's your line of thinking, you're absolutely unqualified to be posting here on this topic.

I hope you understand that with your way of expressing yourself in this thread you are not getting much help. Please behave yourself in this forum.
[/quote]

You behave yourself please.

Why is it OK with people to hijack the thread with absolutely unrelated tests which they claim discredit my report and not OK for me to call them out for it?

[msintle]

It reproduces on the latest Debian 12.6, Ubuntu 24.04, Kali 2024.2, all fresh clean installs (all aarch64 GTK2).

I can NOT confirm. Works fine for me.

Debian GNU/Linux 12 (bookworm)
Lazarus 4.99 (rev main_4_99-471-gaef3e62e80) FPC 3.3.1 aarch64-linux-gtk2

As stated in my bug report, my Lazarus version is:

Lazarus/FPC Version:  Lazarus 3.99 (rev main_3_99-693-gacd0c99f86) FPC 3.3.1 aarch64-linux-gtk2

Are you able to reproduce this issue with the latest 3.99 branch?

[rvk]

Are you able to reproduce this issue with the latest 3.99 branch?

4.99 IS the latest trunk version in main.
I downloaded and compiled the latest trunk for this test.

Main is called 4.99 now, not 3.99.

There is no 3.99 branche.
But there is the older tag main_3_99. Did you mean that one?

[msintle]

Are you able to reproduce this issue with the latest 3.99 branch?

4.99 IS the latest trunk version in main.
I downloaded and compiled the latest trunk for this test.

Main is called 4.99 now, not 3.99.

There is no 3.99 branche.
But there is the older tag main_3_99. Did you mean that one?

Great question, I believe when I had last installed Lazarus, 4.99 wasn't out yet.

I'll reinstall and see what I find.

[marcov]

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.

Note that FPC going from FPC 3.0.4 to 3.2.0+ might be the what resolved this, not lazarus. On Windows the file dialog can be hampered by file explorer plugins bleeding exceptions, that didn't work well with older FPC "SJLJ" kind of exceptions..  Since FPC 3.2.0, FPC also uses standard windows SEH exception processing.

So this observation is probably not relevant for *nix

[msintle]

Sadly, doesn't work. Please see attached screenshot.

This is a 100% clean VM which has only the bare minimum dependencies required to install Lazarus, as shown in the FPCUPDLX requirements text (plus GDB).

I also tested on an older Debian (non-12.6) and that failed too, but it does have all the latest updates, so not sure if that'd make a distinct test case, all things considered.

Can you repeat your test in a clean environment - if you don't believe in VMs, format a disposable device and run bare metal on it - it is very possible that missing dependencies could be the culprit (which is a primary advantage of VM testing).

Edit: My build environment is Debian 11.3 aarch64, and the file dialogs work there just fine.

Also: Even Lazarus can't show any file dialogs on Debian 12.x, for example.

[msintle]

For the continuing speculative bemusement of the forum lizards, please see the attached screenshot.

Inside gtk2proc.inc:

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

1.   gtk_window_present(GtkWindow);
2.  

Is where it blows up!

[rvk]

Can you repeat your test in a clean environment - if you don't believe in VMs, format a disposable device and run bare metal on it - it is very possible that missing dependencies could be the culprit (which is a primary advantage of VM testing).

I am on a clean environment on bare metal (rpi 4, also aarch64 and debian ). Retesting wouldn't make a difference. If it's working on a system it might not be possible to make it fail.

That's why the others are saying it might be an issue on specific hardware, and not a generic problem on aarch64. Maybe someone with paralels can test this.

I believe you that you have a problem (others do too). But if nobody can reproduce it (especially developers) it's hard to pinpoint the exact culprit.

Can you test a standard distribution of Lazarus (or use a different install script)?
(I never used fpcdeluxe but use my own script.)

[marcov]

The SIGFPE sounds like exception mask troubles ( https://wiki.freepascal.org/SetExceptionMask and https://wiki.freepascal.org/Multiplatform_Programming_Guide#Gtk2_and_masking_FPU_exceptions ) 

[rvk]

Is where it blows up!

SIGFPE

The SIGFPE signal reports a fatal arithmetic error. Although the name is derived from “floating-point exception”, this signal actually covers all arithmetic errors, including division by zero and overflow. If a program stores integer data in a location which is then used in a floating-point operation, this often causes an “invalid operation” exception, because the processor cannot recognize the data as a floating-point number.

Just to make sure.... This error also occurs if you run the compiled program outside the IDE (and thus debugger)?