Recent

Author Topic: Common File Dialogs Have Been Broken for a Very Long Time (Ex: Ubuntu AARCH64)  (Read 11208 times)

dbannon

  • Hero Member
  • *****
  • Posts: 3156
    • tomboy-ng, a rewrite of the classic Tomboy
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.

There was definitely an issue with FileOpen Dialog using Qt5, that was fixed, from memory about the time Lazarus 3.0 was released. It was 20second or a bit more freeze that related to dbus communications, "manageable" with the right dbus add-ons installed. Its not there now. Certain combinations of native widgets, all a blur in my memory now.

msintle's experience is a crash. From memory, some people reported that problem caused caused a crash, I never saw it. But it does not appear in any current Lazarus now. But msintle's use of Ubuntu 22.04 would be the right timing to show that problem. It was only with Qt5, never a problem with gtk2.  Don't think Qt6 was a thing then ...

Look though the Qt branch of the forum, couple of years back.

msintle, you see it on both GTK2 and Qt5 ?   (How about Qt6?)  And using the Lazarus in U24.04 (from memory Laz_3.2) ? If so, not the issue above. Maybe unique to "VMs running on Parallels on an M3 Submax." ?   Hmm, I wonder what that means ?

Davo




Lazarus 3, Linux (and reluctantly Win10/11, OSX Monterey)
My Project - https://github.com/tomboy-notes/tomboy-ng and my github - https://github.com/davidbannon

msintle

  • Full Member
  • ***
  • Posts: 247
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.

There was definitely an issue with FileOpen Dialog using Qt5, that was fixed, from memory about the time Lazarus 3.0 was released. It was 20second or a bit more freeze that related to dbus communications, "manageable" with the right dbus add-ons installed. Its not there now. Certain combinations of native widgets, all a blur in my memory now.

msintle's experience is a crash. From memory, some people reported that problem caused caused a crash, I never saw it. But it does not appear in any current Lazarus now. But msintle's use of Ubuntu 22.04 would be the right timing to show that problem. It was only with Qt5, never a problem with gtk2.  Don't think Qt6 was a thing then ...

Look though the Qt branch of the forum, couple of years back.

msintle, you see it on both GTK2 and Qt5 ?   (How about Qt6?)  And using the Lazarus in U24.04 (from memory Laz_3.2) ? If so, not the issue above. Maybe unique to "VMs running on Parallels on an M3 Submax." ?   Hmm, I wonder what that means ?

Davo

Seems like I must clarify a couple things:

o What I see on Ubuntu is a freeze, and when I click around the application in desperation, Ubuntu says the app has stalled and offers to terminate it. So not a crash proper, but a freeze and the resulting termination; giving the ultimate user the impression of a crash (of sorts).

o I see this on GTK2 on Ubuntu currently. I haven't seen it on Qt5, at least not with the reproducing app or my own apps (but I do see a lengthy stall with Lazarus itself as described earlier).

o Would everyone please kindly stop suggesting the issue must somehow be unique to my environment, voltage, etc. This is extremely counter-productive.

o Ubuntu being the widely adopted Linux OS that it is, this issue only hurts the prospects of Lazarus, and all apps built with Lazarus, for as long as it remains unfixed.

o I am testing inside a clean machine installation of Ubuntu hosted as a guest operating system using Parallels running on an Apple Silicon Mac with the M3 Max processor, 30 GPU cores (hence, the Submax designation as the top-of-the-line M3 Max has 40 GPU cores).

dbannon

  • Hero Member
  • *****
  • Posts: 3156
    • tomboy-ng, a rewrite of the classic Tomboy
OK, you want me out of the discussion, I'm out !

Davo
Lazarus 3, Linux (and reluctantly Win10/11, OSX Monterey)
My Project - https://github.com/tomboy-notes/tomboy-ng and my github - https://github.com/davidbannon

tetrastes

  • Hero Member
  • *****
  • Posts: 594
o I am testing inside a clean machine installation of Ubuntu hosted as a guest operating system using Parallels running on an Apple Silicon Mac with the M3 Max processor, 30 GPU cores (hence, the Submax designation as the top-of-the-line M3 Max has 40 GPU cores).

Did you test with other virtualization software than Parallels?

I don't know if you can install Ubuntu on this Mac, but on x86, when problems under VM, I would test on directly installed OS, before saying that it is a global problem.

msintle

  • Full Member
  • ***
  • Posts: 247
o I am testing inside a clean machine installation of Ubuntu hosted as a guest operating system using Parallels running on an Apple Silicon Mac with the M3 Max processor, 30 GPU cores (hence, the Submax designation as the top-of-the-line M3 Max has 40 GPU cores).

Did you test with other virtualization software than Parallels?

I don't know if you can install Ubuntu on this Mac, but on x86, when problems under VM, I would test on directly installed OS, before saying that it is a global problem.

As requested earlier, if you're thinking "it must be a bug in Parallels", please don't bother to post on this thread.

tetrastes

  • Hero Member
  • *****
  • Posts: 594
How do we start triage for this issue?
Indeed, how do you start triage with such aplomb?

As requested earlier, if you're thinking "it must be a bug in Parallels", please don't bother to post on this thread.
Now I'm thinking this is a bug in your head.

msintle

  • Full Member
  • ***
  • Posts: 247
How do we start triage for this issue?
Indeed, how do you start triage with such aplomb?

I've already provided a reproducing project in ready to run binary form. If anybody would actually bother to run it on aarch64 Ubuntu, instead of speculating about bugs in third party hardware, software, and/or electric wiring; that'd be a great start. I do get people sometimes are stuck in denial though.

As requested earlier, if you're thinking "it must be a bug in Parallels", please don't bother to post on this thread.
Now I'm thinking this is a bug in your head.

No, you are a bug in my head.
« Last Edit: October 10, 2024, 06:18:50 pm by msintle »

msintle

  • Full Member
  • ***
  • Posts: 247
For the benefit of all lounging forum lizards:

https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/41188

msintle

  • Full Member
  • ***
  • Posts: 247
So looks like this problem is only getting worse.

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

dbannon

  • Hero Member
  • *****
  • Posts: 3156
    • tomboy-ng, a rewrite of the classic Tomboy
So looks like this problem is only getting worse.
But, apparently, only for you.

I just tested my app on 11 different distributions prior to a release. Don't see anything like you describe. But I am using VirtualBox for virtualization.

Oh, sorry, you 'asked' me not to respond didn't you ?

LoungeLizard
Lazarus 3, Linux (and reluctantly Win10/11, OSX Monterey)
My Project - https://github.com/tomboy-notes/tomboy-ng and my github - https://github.com/davidbannon

msintle

  • Full Member
  • ***
  • Posts: 247
Hey LoungeLizard,

Great to hear from you!

Can you confirm which distributions you tested, and whether they are aarch64 or x64?

It seems VB recently added aarch64 support, so I thought I'd check to be sure.

dbannon

  • Hero Member
  • *****
  • Posts: 3156
    • tomboy-ng, a rewrite of the classic Tomboy
No, I am running Linux on x86_64.  I also test on RasPi aarch64 but that is not, IMHO, relevant. But we do need to recognize the fact that you may well be the first person to run Lazarus on an Ubuntu box running under Parallels on a Mac. I bet none of the FPC/Lazarus developers even thought to test such a combination.

With such lofty expectations needs to come some tolerance.

What is relevant is a bug that existed in the Lazarus you would have been using if you used the U22.04 repo to install Lazarus. That was the bug I was discussing when you got all uptight. But its not present in the 24.04 repo and only affected Qt5 apps. So, we can safely dismiss it ?

So, what do we know ?
  • Firstly, no one else has experienced this problem. FPC/Lazarus users are vocal lot, they would have spoken up if they did. There was huge discussions about that similar but more isolated bug I mentioned above. (for the record, maybe 2000 downloads from my unofficial libqtxpas site, only 60 or so for aarch64).
  • Secondly, apparently, no one else here, in FPC/Lazarus land is using Parallels. Again. people would speak up. We do that here.


What we can speculate about -
  • Ubuntu does not mention the word 'Apple' on its downloads page but DDG does think it did. Is that because Apple threatened them with legal action or they found technical problems ?  They mention ARM only in the context of Raspberry Pi and "Certified Ubuntu Compatible" CPUs. Given Apple's fondness for cross platform, that seems unlikely.


What does Apple present Parallels capable of ?  (I assume Parallels is an Apple product.)

I would go ahead and try VirtualBox for aarch64 if you can. Its sure not a bug free product on platforms its been in use on for years however I depend on it heavily ....

Davo

Lazarus 3, Linux (and reluctantly Win10/11, OSX Monterey)
My Project - https://github.com/tomboy-notes/tomboy-ng and my github - https://github.com/davidbannon

msintle

  • Full Member
  • ***
  • Posts: 247
Thanks again for hijacking the thread, but I'm reporting an issue related to aarch64 and you're reporting failure to reproduce on x86_64, which is completely unrelated. I myself am not seeing an issue on x86_64.

When people read this thread they are 100% confused by your tireless interjections - the point I am making is trivially simple, but you are for reasons unknown choosing to deflect and bury it.

dseligo

  • Hero Member
  • *****
  • Posts: 1410
This is classic example of PEBKAC. TS is P, I mean.

robert rozee

  • Full Member
  • ***
  • Posts: 182
It reproduces on the latest Debian 12.6, Ubuntu 24.04, Kali 2024.2, all fresh clean installs (all aarch64 GTK2)
...
VMs running on Parallels on an M3 Submax.

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.


cheers,
rob   :-)
« Last Edit: November 05, 2024, 11:37:32 am by robert rozee »

 

TinyPortal © 2005-2018