(question): use with other browsers still limited to the NPAPI? about freshplayerplugin

[RJVB]

To answer my own question:

not loaded: /usr/lib/mozilla/plugins/libfreshwrapper-flashplayer.so because "Cannot load library /usr/lib/mozilla/plugins/libfreshwrapper-flashplayer.so: (dlopen: cannot load any more object with static TLS)"
not loaded: /usr/lib/mozilla/plugins/libfreshwrapper-flashplayer.so because "Cannot load library /usr/lib/mozilla/plugins/libfreshwrapper-flashplayer.so: (dlopen: cannot load any more object with static TLS)"

One way around that: LD_PRELOAD'ing the plugin. Then it works.

I tried converting ANGLE's TLS mechanism to C++11 thread_local but that didn't help, either because it uses the same mechanism behind the scenes, or because one of the numerous dependencies already saturated the TLS pool.

patch-cxx11-tls.txt

[i-rinat]

Is there any easy way to get QtWebKit browser working for testing purposes?

I found nothing appropriate in Debian repositories. The one I hoped for was qutebrowser, which now uses qtwebengine, even if I install qtwebkit renderer package. Example app using PyQt5 doesn't load Flash plugin at all. Perhaps, I use it in a wrong way.

[RJVB]

Indeed, almost everyone uses (Qt)WebEngine nowadays, not without reason; QtWebKit doesn't yet have a full implementation of (or support for) WebKit2. I'm using Otter Browser (https://github.com/OtterBrowser/otter-browser), together with the 5.212 alpha2 QtWebKit project (the alpha2 release plus the commits made since that release; https://github.com/annulen/webkit/releases. This supports plugins on Linux. The only real issue I had with the freshplayer plugin turned out to be related to the use of thread-local variables (TLS). Once I rebuilt libuuid (recent versions seem to use a whole slew of TL variables which they don't really need, apparently) and I deactivated the trace code that uses tictoc_ts (unused AFAICT) that problem went away and the plugin loads without LD_PRELOAD forcing. I still need to move the standard flash player plugin out of the way (it says Adobe but is very recent). I updated Google Chrome this morning, and the fresh/flash player version reflected that upgrade immediately. My initial idea that using thread_local (or __thread) variables would solve the static TLS issue was wrong of course. You need to use pthread_g/setspecific to avoid it. I tried to use a copy of ANGLE's tls.cpp wrapper to replace the `__thread` mainloop variables, but I clearly don't understand the code well enough.

[i-rinat]

I tried to prototype patch here: https://github.com/i-rinat/freshplayerplugin/tree/dev-thread-local-to-gprivate. Is that enough to make error message go away? If that helps, I'll make another version, with single GPrivate instance. Documentation says they are very limited resources too.

By the way, I find that there is no "cannot load any more object with static TLS" string in glibc code anymore. There are some commented out lines in translation files, but original string from the code itself was deleted. I think, glibc 2.22 was the first release without that error message. Changelog mentions fixes related to TLS, so it may help to update glibc.

[RJVB]

I tried to prototype patch here: https://github.com/i-rinat/freshplayerplugin/tree/dev-thread-local-to-gprivate. Is that enough to make error message go away? If that helps, I'll make another version, with single `GPrivate` instance. Documentation says they are very limited resources too.

Sounds good. I probably won't have time to test for a few days, so don't hesitate to prod me if you think I'm forgetting about it!

By the way, I find that there is no "cannot load any more object with static TLS" string in glibc code anymore. There are some commented out lines in translation files, but original string from the code itself was deleted. I think, glibc 2.22 was the first release without that error message. Changelog mentions fixes related to TLS, so it may help to update glibc.

Did you see if they also removed the static table for TLS which is apparently the source of the whole problem? Problem is, updating my (e)glibc is among the very few things that I really hesitate doing. I did try to follow online instructions to rebuild a patched libdl.so version, but either I did something wrong, or those instructions don't apply to my system's eglibc 2.19 .

[i-rinat]

Did you see if they also removed the static table for TLS which is apparently the source of the whole problem?

I have no idea about how this all is working and what glibc does there. But here is that commit I was talking about: https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=f8aeae347377f3dfa8cbadde057adf1827fb1d44;hp=b97eb2bdb1ed72982a7821c3078be591051cef59.

[RJVB]

I have no idea about how this all is working and what glibc does there.

I doubt that I understand this any better than you :) Proof: I recognise nothing of that code, and it's not even a month ago since I applied the patch I mentioned. Maybe eglibc is just sufficiently different to explain that... I do see that there is still a static table, but the maybe they implemented the suggested change ("track the minimum DTV slots allocated in all threads"). Or maybe they increased the table size, or made it possible to extend it as needed. Either way, I'll try your patch later this week. R.

[i-rinat]

Pushed modified patch to the master branch as ce233f6. Also, there no dev-thread-local-to-gprivate branch anymore, since it had essentially the same.

There are no .tdata nor .tbss sections in compiled binary, which were used for thread-local storage. So plugin should load without triggering the bug, unless some other library exhaust TLS storage. But in that case there is nothing can be done in freshplayerplugin.

[RJVB]

Seems to work fine. At least freshplayerplugin no longer fails to load when other libraries have (almost) exhausted the resource.