[Linux] Flash content fails to load

[athenian200]

I'm currently using the officially provided binary from lpmo. Now that you said it, I will try using stevepusser's build and see if that works.

EDIT: Nope, Flash doesn't work in stevepusser's build either.

Well, I just tried Flash on Ubuntu 22.04 with Glibc 2.35. What I found was that on a version I compiled myself on there, it worked just fine. But the official binaries we provide didn't work, resulting in weird audio issues, a black and white picture, and finally a message offering to forcequit. It displayed the following output:

Code: Select all

[NPAPI 23160] WARNING: pipe error (3): Connection reset by peer: file /home/PM4Linux/MCP/Pale-Moon/platform/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 330
[NPAPI 23160] ###!!! ABORT: Aborting on channel error.: file /home/PM4Linux/MCP/Pale-Moon/platform/ipc/glue/MessageChannel.cpp, line 2127
[NPAPI 23160] ###!!! ABORT: Aborting on channel error.: file /home/PM4Linux/MCP/Pale-Moon/platform/ipc/glue/MessageChannel.cpp, line 2127
Killed

Since I've gotten this result, I guess I should tell everyone about a weird glibc change (aside from the ones we've already dealt with) that I basically only know about because one of the distros screwed up in providing shims to compensate for it:

https://repo.palemoon.org/athenian200/epyrus/issues/7

Essentially, glibc 2.35 moved the pthread and dl libraries out of -lpthread and -ldl, and I had to instruct the user to manually create "dummy" libraries because his distro forgot to do it (they'll be fixing it in the next release). If that hadn't happened, I would have no idea what is going on here. But the problem is... we build assuming that -lpthread and -ldl are real libraries, and the linker looks for them. While the fallback mechanisms work well enough for Pale Moon by itself, the interaction between Pale Moon and Flash is just enough to make it break. This also reminds me of an issue Baloo was having with Epyrus on a Ubuntu-based distro called PopOS, with an external program that was trying to hook into Epyrus (I forget what it was).

So my theory is that they have made glibc "different" enough that our little solution for creating universal Linux binaries isn't as universal as it used to be, unfortunately.

EDIT: I also tried a pre-release version of Fedora with glibc 2.36. Both the self-compiled build AND the official binaries work on Flash Player for that one. So that is even weirder.

It seems that basically differences between how different distros are dealing with glibc changes result in this randomly working or not working with provided binaries, and it's back to the way it was when I used Linux... building it yourself results in less bugs and provided binaries have all kinds of issues.

[jobbautista9]

Ok, I just tried the live image of Ubuntu 21.10, which has glibc 2.34, and surprisingly Flash on Pale Moon (the official binary, not a self-built one) works there. Now this is interesting, because I expected it not to work and try out 21.04 (which has glibc 2.33, which I thought is the last good version) instead after testing there. So either Ubuntu somehow has patched glibc better than Debian's, or maybe I just have a broken system, who knows. I really don't know anymore; this is so frustrating to troubleshoot...

ubuntu-21.10-walfas.png

[athenian200]

Okay, I checked something really quick on Ubutu 22.04. I noticed that the libpthread.so.0 file has actual binary data, while the libpthread.a file meant to act as a "shim" looks like it does on Fedora, so this is like halfway between the way it was on OpenMandriva (with no shim) and Fedora (with no actual libpthread). I first tried backing up the libpthread.so.0 file and creating a symlink to the "shim." This resulted in it failing to launch at all. So I then instead tried backing up the "shim" file and putting the actual binary in its place.

The result was that just replacing that one file caused the official binaries to start working just like a self-built version. Which means... Ubuntu and Debian didn't handle this transition well. Better than a smaller distro like OpenMandriva, but much worse than Fedora Rawhide which is still working even with 2.36. I think everything is getting confused because Ubuntu left a part of the old glibc in there and also included the shims, so pthread stuff can effectively get defined twice depending on how libraries are loaded.

[athenian200]

So, I decided to test the OP's operating system, EndeavorOS. For some weird reason, I couldn't get the official binaries to detect Flash player at ALL on that one. Like no matter where I put them or what I set MOZ_PLUGIN_PATH to, it simply wouldn't load up and acted like I had put an invalid file.

But when I built my own copy of Pale Moon... everything worked pretty much flawlessly, including the OP's link.

So it seems like for now, the only solution is for people on Debian and Arch to try building Pale Moon themselves if the official binaries don't work (note that you'll have to build gconf from AUR). The bleeding edge glibc is not compatible with our binaries... building for Linux now feels more like a musl build or what I had to deal with for Solaris compared with what it used to be.

[Moonchild]

So it seems like for now, the only solution is for people on Debian and Arch to try building Pale Moon themselves if the official binaries don't work (note that you'll have to build gconf from AUR). The bleeding edge glibc is not compatible with our binaries... building for Linux now feels more like a musl build or what I had to deal with for Solaris compared with what it used to be.

This makes me sad. Of course this is exactly the reason why I made the redist exception for official branding in the redist license for building from source, but I would have hoped that main distros would at the very least favour stability over just freewheeling their libs.
practically speaking, there is the simple reason that we can't start providing binaries for even a small number of different "main" distros. If this continues being a problem we may simply have to change our policy for Linux and make it a "just build from source or use a distro-specific distribution channel" instead of offering generic binaries -- but I hope things do get solved in *nix land.

[athenian200]

practically speaking, there is the simple reason that we can't start providing binaries for even a small number of different "main" distros. If this continues being a problem we may simply have to change our policy for Linux and make it a "just build from source or use a distro-specific distribution channel" instead of offering generic binaries -- but I hope things do get solved in *nix land.

I think that maybe we should just add a prominent note on our binaries that they work best with RHEL-derivatives and Fedora (which is exactly what my testing revealed, no version of RHEL or Fedora even up to Rawhide had any issues). I mean, I suspect that was already true to a degree, just maybe not this much... I imagine Steve has been going out of his way to provide Debian/Ubuntu builds for a reason, and the Arch users keep their AUR updated enough that we hear about build issues for a reason. We can keep doing what we do, but basically we have to be a bit more realistic about our compatibility expectations across distros that do things differently from Fedora/RHEL.

In all honesty, I almost didn't provide Linux binaries for Epyrus at first because I was hoping most Linux users could build themselves (along with having enough experience to know stuff like this is very common). But the thing is, I found that at least for Epyrus, I have a lot of Windows 7/XP refugees on slower/older hardware with limited tech skills who need binaries. I thought about using a newer environment, but I quickly had to go CentOS 7 because too many people had outdated glibc.

I haven't decided what I am going to do for Epyrus in light of this new info yet, but I will say that I am reluctant to abandon the users on older glibc who are probably the least able to build my application themselves, and I feel that the binaries I'm providing are at least enough for those people, even if I would now advise anyone on newer Linux to do their own builds.

[vannilla]

As far as I'm concerned as a Linux user I believe encouraging users to use distro-specific solutions or even building from source is the best course of action instead of using the generic build.
While we can argue all we want about how things are being handled regarding glibc et al., the role of the packager was born a long time ago exactly to solve these situations.
The purpose of the packager is taking care of ensuring the application works on their targeted systems and thanks to that they relieve the maintainers from things they don't necessarily need to know.
For example taking from this thread, the Pale Moon team only need to know that to get pthread and dl_* functions you need the -lpthread and -ldl flags; whether these flags end up taking an actual file or a symlink or something else is not something they need to care about: that is the packager's business.
Just my opinion as a long-time Linux user, even if I build from source myself most of the time for various reasons.

[jouven]

But when I built my own copy of Pale Moon... everything worked pretty much flawlessly, including the OP's link.

What procedure did you follow to compile Pale moon?
I tried https://aur.archlinux.org/packages/palemoon , which compiles it, still I get the same outcome.

[athenian200]

What procedure did you follow to compile Pale moon?
I tried https://aur.archlinux.org/packages/palemoon , which compiles it, still I get the same outcome.

Well, the biggest difference I notice on AUR is that your configuration disables GConf and uses GTK2. I built GConf from AUR to satisfy the GConf dependency and used the official configuration shown here, which enables GConf and uses GTK3. Oh, and I installed the GNOME desktop, I don't know if that would make a difference or not. I just picked that because that seems to be the standard environment on Linux.

http://developer.palemoon.org/build/linux/

The only other difference is I built the platform against master rather than the release branch AUR uses, but I wouldn't have expected that to fix anything.

If that doesn't solve the problem, it really sounds like it could be a matter of either a weird video driver issue, or them having pushed a change already that partially mitigates the issue you're having in the latest update. My experience on your distro was different from what you reported in that I couldn't get our official binaries to load Flash player up at all, much less crash with it. It acted like libflashplayer.so wasn't there at all until it built it from scratch.

[jouven]

My experience on your distro was different from what you reported in that I couldn't get our official binaries to load Flash player up at all, much less crash with it. It acted like libflashplayer.so wasn't there at all until it built it from scratch.

How did you install flash?

I tried compiling the official way http://developer.palemoon.org/build/linux/ , and it doesn't finish compiling, it won't on arch-based distros right now and it's acknowledged in the https://aur.archlinux.org/packages/palemoon comments. My compilation stopped at this error:

Code: Select all

somepath/MoonchildProductions/Pale-Moon/platform/ipc/chromium/src/third_party/libevent/./arc4random.c:486:1: error: static declaration of ‘arc4random_buf’ follows non-static declaration

I don't know how do you managed to compile it and made flash work. But if I had to guess... you installed endeavouros but didn't update it.

[athenian200]

I tried compiling the official way http://developer.palemoon.org/build/linux/ , and it doesn't finish compiling, it won't on arch-based distros right now and it's acknowledged in the https://aur.archlinux.org/packages/palemoon comments. My compilation stopped at this error:

Code: Select all

somepath/MoonchildProductions/Pale-Moon/platform/ipc/chromium/src/third_party/libevent/./arc4random.c:486:1: error: static declaration of ‘arc4random_buf’ follows non-static declaration

I know, I already fixed that, that's why I compiled against master:

https://repo.palemoon.org/MoonchildProd ... 5f84f77d47

I don't know how do you managed to compile it and made flash work. But if I had to guess... you installed endeavouros but didn't update it.

Nope, I just checked and my installation is up-to-date. I did the online install, not the offline, and it has Glibc 2.36 installed. I double-checked that. I even just ran the update procedure now and it only updated two packages. So somehow I am in fact getting it to work on the latest version.

[distantpluto]

I tried compiling the official way http://developer.palemoon.org/build/linux/ , and it doesn't finish compiling, it won't on arch-based distros right now and it's acknowledged in the https://aur.archlinux.org/packages/palemoon comments. My compilation stopped at this error:

Code: Select all

somepath/MoonchildProductions/Pale-Moon/platform/ipc/chromium/src/third_party/libevent/./arc4random.c:486:1: error: static declaration of ‘arc4random_buf’ follows non-static declaration

I don't know how do you managed to compile it and made flash work. But if I had to guess... you installed endeavouros but didn't update it.

PM builds for me from the AUR (the link you posted). There's a patch included. Are you building clean?

As for Flash, I rebuilt PM to see if the OPs link would work, since glibc had been updated since I last built PM. Still doesn't load. However, Flash works perfectly for my IP cams' interface and viewer (as it did before).

[athenian200]

2022-08-21 (1).png

Just to prove I really did do this...

[jouven]

I finally managed to compile Pale moon the official way, using the master branch, still flash won't load.
I'll ask again athenian200, how did you install flash? (in you endevaouros installation)

As for Flash, I rebuilt PM to see if the OPs link would work, since glibc had been updated since I last built PM. Still doesn't load. However, Flash works perfectly for my IP cams' interface and viewer (as it did before).

We are in the same boat then, I can run flash too (not in Pale moon). I get around using the adobe flash player standalone.

[athenian200]

I finally managed to compile Pale moon the official way, using the master branch, still flash won't load.
I'll ask again athenian200, how did you install flash? (in you endevaouros installation)

What do you mean by "won't load"? Do you mean it still crashes or that it won't load up at all?

All I did was type out

Code: Select all

export MOZ_PLUGIN_PATH=/home/athenian200/Downloads

Which happened to be where I had the libflashplayer.so extracted to. That didn't work with the official binaries, but did work with the ones I built.

I'm not really satisfied with the resolution that on newer glibc the only solution is using Flash Player standalone. :/ There has to be something going on that's making it work on my end, I just don't know what it is. I always seem to find myself in these situations where I know that something can work, and I in fact get it to work on my machine, but struggle with the kind of detail-oriented approach I would need to make what I know can be done practical for other people.

[jouven]

What do you mean by "won't load"? Do you mean it still crashes or that it won't load up at all?

All I did was type out

Code: Select all

export MOZ_PLUGIN_PATH=/home/athenian200/Downloads

Which happened to be where I had the libflashplayer.so extracted to. That didn't work with the official binaries, but did work with the ones I built.

I'm not really satisfied with the resolution that on newer glibc the only solution is using Flash Player standalone. :/ There has to be something going on that's making it work on my end, I just don't know what it is. I always seem to find myself in these situations where I know that something can work, and I in fact get it to work on my machine, but struggle with the kind of detail-oriented approach I would need to make what I know can be done practical for other people.

I'll ask in a different way then, where did you get your libflashplayer.so file from?
I never mentioned Pale moon crashing, flash content just doesn't load, if I put https://megami.starcreator.com/nanaca-c ... h_v110.swf in the address bar and I hit enter key it loads an empty site and the Pale moon process prints the following message in the console/log:

Code: Select all

###!!! [Parent][MessageChannel::Call] Error: Channel error: cannot send/recv


###!!! [Parent][MessageChannel::Call] Error: (msgtype=0x9A000C,name=PPluginInstance::Msg_NPP_GetValue_NPPVpluginScriptableNPObject) Channel error: cannot send/recv


###!!! [Parent][MessageChannel] Error: (msgtype=0x9A0071,name=PPluginInstance::Msg_PBrowserStreamConstructor) Channel error: cannot send/recv

[athenian200]

I'll ask in a different way then, where did you get your libflashplayer.so file from?

You have the NPAPI version and not the PPAPI version, right? PM only supports NPAPI. I guess you would need to find a copy of flashplayer32_0r0_371_linux.x86_64.tar.gz somehow, because that's what I have. It was the last version of Linux Flash Player I ever installed, and I just happened to find it on an old hard drive somewhere. I don't know if it would make a difference, but it would be at least one more variable eliminated.

I never mentioned Pale moon crashing, flash content just doesn't load, if I put https://megami.starcreator.com/nanaca-c ... h_v110.swf in the address bar and I hit enter key it loads an empty site and the Pale moon process prints the following message in the console/log:

Oh! I assumed that was the error you got when Pale Moon crashed, because when I tried it in Ubuntu there WAS a crash (though with a different error). I'm glad to know it at least isn't crashing the browser on Arch. That opens up a lot of other possibilities for what it could be. Does going to Preferences, Advanced, Force Hardware Acceleration make things worse or better? Sorry I'm having you try so many seemingly random things, I know it's frustrating when you just want the Flash Player to work.

[jouven]

You have the NPAPI version and not the PPAPI version, right? PM only supports NPAPI. I guess you would need to find a copy of flashplayer32_0r0_371_linux.x86_64.tar.gz somehow, because that's what I have. It was the last version of Linux Flash Player I ever installed, and I just happened to find it on an old hard drive somewhere. I don't know if it would make a difference, but it would be at least one more variable eliminated.

Found the version you mentioned here https://archive.org/download/flashplayer_old
Tried forcing it with export MOZ_PLUGIN_PATH
Palemoon shows it in the addons/plugins section.
But the outcome is the same, same behavior and messages in the log/console.

[athenian200]

Tried forcing it with export MOZ_PLUGIN_PATH
Palemoon shows it in the addons/plugins section.
But the outcome is the same, same behavior and messages in the log/console.

Well, I do have some good news, though it won't help very much with the "right away" part of the problem. I managed to reproduce your issue. For some reason, this can't be reproduced on a VM. Only on bare metal, and that's why I couldn't get it to happen before.

Also, apparently the issue on Arch is NOT the same one that Ubuntu is having. They have similar symptoms, but it's not the same at all. What's really bizarre is this... the official binaries start working with Flash Player in the VM with 2.36-3, after they add DT_HASH back. That is to say, an update they pushed out an hour ago. But it doesn't seem to help at all on bare metal...

So I think what's happening on Arch on bare metal now is a separate issue from all the glibc issues we've been having. Because all the glibc issues at worst just render our official binaries inoperable in isolation and require the application to be rebuilt. Whatever is going on with Arch makes it so that our application will never work even if rebuilt, but can't be seen in a VM.

[Mæstro]

To help diagnose, Flash 32·0·0·371 works for me with Pusser’s Debian 10 build in LMDE 4. I install any patches Mint Upgrade brings to my attention; feel free to ask me if you must know any library versions or the like. Moreover, I have tested this sample file, and it loads well: I had got 725·10 m on my first try once I could work out the game mechanics!