skullnobrains
asked on
ubuntu 14 weird ff 98 crash
hi
this question is partly educational and partly because it is annoying
i installed a recent firefox 98.0 using mozilla's provided precompiled binaries on an old ubuntu 14 computer
i noticed a few bugs including the impossibility to close a browser window without crashing firefox. closing the last tab or the window itself produce the same behaviors.
using the default ubuntu session, the window does not close and ff crashes
using a gnome flashback session, the window does close but the remaining windows become grey and unresponsive.
using openbox produces the same behavior as above but the crash occurs after a few seconds.
using xfce for some reason works as expected.
all the above behaviors are repeatable at least a few times and occured every single time i tried.
does anyone have a idea why this would happen ? or how to debug it ? or experienced anything similar ?
i tried ltrace and the same permanent mutex lock/unlock stuff is displayed on screen before and after the rest of the browser becomes unresponsive but i may have missed relevant stuff given the volume of output.
my hunch is gtk may be involved somehow though i have not played with other unexpectedly recent gtk based software on the same machine.
i DO NOT WISH to discuss whether using ubuntu 14 is a good idea so please juste refrain from posting if you're just going to suggest upgrading. this machine has a octuple boot not including alternate kernels and a bunch of vms some of which are also bootable on bare bones so this is really besides the point.
thanks a lot for your help
Once you determine the problem, likely you'll find some library problem.
If you must run recent FireFox on Trusty, here are the steps.
1) Recompile FireFox from source on Trusty.
2) Relink FireFox on Trusty.
3) If problems persist, you'll then track down the problem library + modify the source to work on Trusty, then recompile the library as a shared object, then proceed to fixing the next similar problem.
If you must run recent FireFox on Trusty, here are the steps.
1) Recompile FireFox from source on Trusty.
2) Relink FireFox on Trusty.
3) If problems persist, you'll then track down the problem library + modify the source to work on Trusty, then recompile the library as a shared object, then proceed to fixing the next similar problem.
Trusty (Ubuntu 14.04) EOL'ed April 2014.The EOL of Ubuntu 14.04 is on the 17th of April 2019, so only 3 years ago. LTS versions are good for 5 years of support and the rest are good for 2 years.
End Of Life 2014 is a very long time ago.
Had you updated ubuntu to the very last patches available?
If you recompile firefox from source, you may have to shoehorn in libraries for the newer version of firefox to work correctly. It can be done, but it can be a bit tedious to put in new libraries alongside default libraries. You might want to staticly compile firefox on a newer ubuntu and copy the binary over.
ASKER
hello serialband.
yes that ubuntu includes the latest updates. funnily enough, a much more vastly outdated 14 does not display the same behavior with a similarly unexpected ff version.
i am not really trying to fix stuff at this stage but rather find out what produces this behavior. if needed, i'll simply use the appimage, snap or whatever equivalent version or even a static build or hijack alpine's.
i am actually interested in what produces the bug and failed to find anything obvious either in the logs or in strace/ltrace. gdb would probably be hardly usable and i'm not really good with it but might be an option i have not dug yet. i was hoping someone would know something quite obvious that would explain why the same bug would not occur in an xfce session.
yes that ubuntu includes the latest updates. funnily enough, a much more vastly outdated 14 does not display the same behavior with a similarly unexpected ff version.
i am not really trying to fix stuff at this stage but rather find out what produces this behavior. if needed, i'll simply use the appimage, snap or whatever equivalent version or even a static build or hijack alpine's.
i am actually interested in what produces the bug and failed to find anything obvious either in the logs or in strace/ltrace. gdb would probably be hardly usable and i'm not really good with it but might be an option i have not dug yet. i was hoping someone would know something quite obvious that would explain why the same bug would not occur in an xfce session.
ASKER
in order to get an extra hint, i tried the appimage (98.0.2)
strangely enough, i ended up with the same bug
i only tried in the regular ubuntu session as i have other things that are running on this machine at the moment and i cannot affort to close the session
i must admit i am quite baffled by this situation.
i tried to quit using file>quit
the window does close but FF keeps running both with the regular and appimage versions [nuts!]
running in safe mode or with profile manager or presumably anything that involves a startup window is not possible since the window won't close either. but switching profiles works as expected.
does it raise some kind of flag ?
what the hell can produce such a behavior ?
strangely enough, i ended up with the same bug
i only tried in the regular ubuntu session as i have other things that are running on this machine at the moment and i cannot affort to close the session
i must admit i am quite baffled by this situation.
i tried to quit using file>quit
the window does close but FF keeps running both with the regular and appimage versions [nuts!]
running in safe mode or with profile manager or presumably anything that involves a startup window is not possible since the window won't close either. but switching profiles works as expected.
does it raise some kind of flag ?
what the hell can produce such a behavior ?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
@serialband, Thanks...
https://wiki.ubuntu.com/Releases - Correct, I misread, so Trusty is presumed hackable starting April 2019.
@skullnobrains, there should be some log somewhere showing the problem, even if this is a core dump you can run through gdb for a stacktrace... for some sort of starting point...
https://wiki.ubuntu.com/Releases - Correct, I misread, so Trusty is presumed hackable starting April 2019.
@skullnobrains, there should be some log somewhere showing the problem, even if this is a core dump you can run through gdb for a stacktrace... for some sort of starting point...
It's possible that you have kernel or other system or library file corruption. Windows users would have to run DISM or SFC to fix it and Mac users would have to run recovery and reinstall the OS on top of their systems to fix it. I don't believe Linux has something equivalent. I've found that I've bee able to fix a lot of weird, unexplained issues by fixing kernel and system files.
ASKER
@david : there is no core dump. the program does not really crash. it continues to run and becomes unresponsive. it might even be possible that it runs fine but ubuntu thinks it does not and somehow forbids to interact with it.
@serialband : i do not believe in such a corruption : other programs including the packaged FF run perfectly. and ff 98 displayed this behavior the very first time i launched it. corruption in ff files is unlikely as well since the appimage version does the same.
i am thinking something either X related or system related (such as a lagging dbus confirmation) prevents the program to exit entirely. i am unsure how to debug. somehow the fact it works in xfce (4.10) should be a hint.
note : i tried to replace the window manager on the fly while ff was hanged which did not unhang the program.
note2 : i forgot to mention that ALL the ff windows hang when this happens.
@serialband : i do not believe in such a corruption : other programs including the packaged FF run perfectly. and ff 98 displayed this behavior the very first time i launched it. corruption in ff files is unlikely as well since the appimage version does the same.
i am thinking something either X related or system related (such as a lagging dbus confirmation) prevents the program to exit entirely. i am unsure how to debug. somehow the fact it works in xfce (4.10) should be a hint.
note : i tried to replace the window manager on the fly while ff was hanged which did not unhang the program.
note2 : i forgot to mention that ALL the ff windows hang when this happens.
A double free issue comes to mind.....
Several have been fixed and it has been a thingy in 5-9 years ago in various software. (Gnome, ..)
Firefox Double Free was long ago, so probably gnome related libraries are to blame.
Several have been fixed and it has been a thingy in 5-9 years ago in various software. (Gnome, ..)
Firefox Double Free was long ago, so probably gnome related libraries are to blame.
ASKER
hello
@noci : sorry i missed your initial post. as always your input is much welcome.
--
i am not very good with gdb but managed to grab the 2 following traces.
i am unsure whether the first one is relevant
this one is more relevant and attaching + detatching does not unlock firefox but does allow the window to actually close
repetitively tracing the program, detatching retracing produces the following traces
there seem to be a pattern where ff circles around inside the same g_closure invoke() call and repetitively calls g_pointer_bit_lock/unlock on what may or may not be the same pointer. this seems repeatable.
the libxul are indeed different but all libs probably are
i am unsure how to debug further or whether a double free is indeed involved
thanks all
@noci : sorry i missed your initial post. as always your input is much welcome.
--
i am not very good with gdb but managed to grab the 2 following traces.
i am unsure whether the first one is relevant
#0 0x00007fd836eecc9d in poll () at ../sysdeps/unix/syscall-template.S:81
#1 0x00007fd82a42d1c7 in ?? () from /opt/firefox/libxul.so
#2 0x00007fd833021ff4 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3 0x00007fd8330220fc in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#4 0x00007fd82a190e6d in ?? () from /opt/firefox/libxul.so
#5 0x00007fd82a1d24f1 in ?? () from /opt/firefox/libxul.so
#6 0x00007fd82ad7004d in ?? () from /opt/firefox/libxul.so
#7 0x00007fd82b431ea9 in ?? () from /opt/firefox/libxul.so
#8 0x00007fd828f19b61 in ?? () from /opt/firefox/libxul.so
#9 0x00007fd828f8bee9 in ?? () from /opt/firefox/libxul.so
#10 0x00007fd828f8c8e2 in ?? () from /opt/firefox/libxul.so
#11 0x00007fd828f8cca9 in ?? () from /opt/firefox/libxul.so
#12 0x00005626810b6ee6 in _start ()
this one is more relevant and attaching + detatching does not unlock firefox but does allow the window to actually close
#0 0x00007fcaa6a2907b in gdk_window_peek_children () from /usr/lib/x86_64-linux-gnu/libgdk-3.so.0
#1 0x00007fca9c816c6f in ?? () from /opt/firefox/libxul.so
#2 0x00007fcaa46c63b8 in g_closure_invoke () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#3 0x00007fcaa46d7d3d in ?? () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#4 0x00007fcaa46dfa29 in g_signal_emit_valist () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#5 0x00007fcaa46dfce2 in g_signal_emit () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#6 0x00007fcaa6f73911 in gtk_widget_unrealize () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#7 0x00007fcaa6f73a38 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#8 0x00007fcaa46ccad0 in g_object_run_dispose () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#9 0x00007fca9c80e4b0 in ?? () from /opt/firefox/libxul.so
#10 0x00007fca9ca2e6f1 in ?? () from /opt/firefox/libxul.so
#11 0x00007fca9a131d83 in ?? () from /opt/firefox/libxul.so
#12 0x00007fca9a132687 in ?? () from /opt/firefox/libxul.so
#13 0x00007fca996e03ee in ?? () from /opt/firefox/libxul.so
#14 0x00007fcaa6e3fd3e in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#15 0x00007fcaa46c65e7 in ?? () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#16 0x00007fcaa46df088 in g_signal_emit_valist () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#17 0x00007fcaa46dfce2 in g_signal_emit () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#18 0x00007fcaa6f68974 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#19 0x00007fcaa6e3fa69 in gtk_main_do_event () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#20 0x00007fcaa6a43c22 in ?? () from /usr/lib/x86_64-linux-gnu/libgdk-3.so.0
#21 0x00007fcaa43f6e14 in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#22 0x00007fcaa43f7058 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#23 0x00007fcaa43f70fc in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#24 0x00007fca9b564889 in ?? () from /opt/firefox/libxul.so
#25 0x00007fca9b5a74fd in ?? () from /opt/firefox/libxul.so
#26 0x00007fca9c14504d in ?? () from /opt/firefox/libxul.so
#27 0x00007fca9c806ea9 in ?? () from /opt/firefox/libxul.so
#28 0x00007fca9a2eeb61 in ?? () from /opt/firefox/libxul.so
#29 0x00007fca9a360ee9 in ?? () from /opt/firefox/libxul.so
#30 0x00007fca9a3618e2 in ?? () from /opt/firefox/libxul.so
#31 0x00007fca9a361ca9 in ?? () from /opt/firefox/libxul.so
#32 0x000055cb7d800ee6 in _start ()repetitively tracing the program, detatching retracing produces the following traces
#0 0x00007fcaa46e834c in g_type_check_instance_cast () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#1 0x00007fca9c816c4b in ?? () from /opt/firefox/libxul.so
#2 0x00007fcaa46c63b8 in g_closure_invoke () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#0 0x00007fcaa43ce8f0 in g_pointer_bit_unlock () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#1 0x00007fcaa43dc86f in g_datalist_get_data () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2 0x00007fca9c816c56 in ?? () from /opt/firefox/libxul.so
#3 0x00007fcaa46c63b8 in g_closure_invoke () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
....
#0 0x00007fcaa6a28453 in gdk_window_get_type () from /usr/lib/x86_64-linux-gnu/libgdk-3.so.0
#1 0x00007fcaa6a29069 in gdk_window_peek_children () from /usr/lib/x86_64-linux-gnu/libgdk-3.so.0
#2 0x00007fca9c816c6f in ?? () from /opt/firefox/libxul.so
#3 0x00007fcaa46c63b8 in g_closure_invoke () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#0 0x00007fcaa43ce8dd in g_pointer_bit_unlock () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#1 0x00007fcaa43dc86f in g_datalist_get_data () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2 0x00007fca9c816c56 in ?? () from /opt/firefox/libxul.so
#3 0x00007fcaa46c63b8 in g_closure_invoke () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#0 0x00007fcaa43ce825 in g_pointer_bit_lock () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#1 0x00007fcaa43dc80f in g_datalist_get_data () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2 0x00007fca9c816c56 in ?? () from /opt/firefox/libxul.so
#3 0x00007fcaa46c63b8 in g_closure_invoke () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
there seem to be a pattern where ff circles around inside the same g_closure invoke() call and repetitively calls g_pointer_bit_lock/unlock on what may or may not be the same pointer. this seems repeatable.
the libxul are indeed different but all libs probably are
i am unsure how to debug further or whether a double free is indeed involved
thanks all
ASKER
i am unsure whether this is relevant but here goes the ldd for libxul (errors included)
what baffles me is the appimage variant produces the same result.
i am wondering whether the unity desktop loads a different version of one of the bundled libs before firefox is started which may explain quite a few things
lsof says the libssl and libnss present in /opt/firefox are the ones that are loaded but a bunch of system libs which are not in /opt are used by firefox
$ sudo ldd /opt/firefox/libxul.so
/opt/firefox/libxul.so: /usr/lib/x86_64-linux-gnu/libssl3.so: version `NSS_3.33' not found (required by /opt/firefox/libxul.so)
/opt/firefox/libxul.so: /usr/lib/x86_64-linux-gnu/libssl3.so: version `NSS_3.30.0.1' not found (required by /opt/firefox/libxul.so)
/opt/firefox/libxul.so: /usr/lib/x86_64-linux-gnu/libnss3.so: version `NSS_3.45' not found (required by /opt/firefox/libxul.so)
/opt/firefox/libxul.so: /usr/lib/x86_64-linux-gnu/libnss3.so: version `NSS_3.31' not found (required by /opt/firefox/libxul.so)
/opt/firefox/libxul.so: /usr/lib/x86_64-linux-gnu/libnss3.so: version `NSS_3.30' not found (required by /opt/firefox/libxul.so)
/opt/firefox/libxul.so: /usr/lib/x86_64-linux-gnu/libnss3.so: version `NSS_3.44' not found (required by /opt/firefox/libxul.so)
/opt/firefox/libxul.so: /usr/lib/x86_64-linux-gnu/libnss3.so: version `NSS_3.47' not found (required by /opt/firefox/libxul.so)
/opt/firefox/libxul.so: /usr/lib/x86_64-linux-gnu/libnss3.so: version `NSS_3.55' not found (required by /opt/firefox/libxul.so)
/opt/firefox/libxul.so: /usr/lib/x86_64-linux-gnu/libnss3.so: version `NSS_3.58' not found (required by /opt/firefox/libxul.so)
/opt/firefox/libxul.so: /usr/lib/x86_64-linux-gnu/libnss3.so: version `NSS_3.52' not found (required by /opt/firefox/libxul.so)
linux-vdso.so.1 => (0x00007ffdc09ad000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f5fdf067000)
libmozsandbox.so => not found
libnspr4.so => /usr/lib/x86_64-linux-gnu/libnspr4.so (0x00007f5fdee2a000)
libplc4.so => /usr/lib/x86_64-linux-gnu/libplc4.so (0x00007f5fdec25000)
libplds4.so => /usr/lib/x86_64-linux-gnu/libplds4.so (0x00007f5fdea21000)
liblgpllibs.so => not found
libnss3.so => /usr/lib/x86_64-linux-gnu/libnss3.so (0x00007f5fde6e3000)
libnssutil3.so => /usr/lib/x86_64-linux-gnu/libnssutil3.so (0x00007f5fde4b6000)
libsmime3.so => /usr/lib/x86_64-linux-gnu/libsmime3.so (0x00007f5fde28a000)
libmozsqlite3.so => not found
libssl3.so => /usr/lib/x86_64-linux-gnu/libssl3.so (0x00007f5fde03e000)
libmozgtk.so => not found
libmozwayland.so => not found
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f5fdde3a000)
libasound.so.2 => /usr/lib/x86_64-linux-gnu/libasound.so.2 (0x00007f5fddb4a000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f5fdd942000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f5fdd63c000)
libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007f5fdd307000)
libXcomposite.so.1 => /usr/lib/x86_64-linux-gnu/libXcomposite.so.1 (0x00007f5fdd104000)
libXdamage.so.1 => /usr/lib/x86_64-linux-gnu/libXdamage.so.1 (0x00007f5fdcf01000)
libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x00007f5fdccef000)
libXfixes.so.3 => /usr/lib/x86_64-linux-gnu/libXfixes.so.3 (0x00007f5fdcae9000)
libXrandr.so.2 => /usr/lib/x86_64-linux-gnu/libXrandr.so.2 (0x00007f5fdc8df000)
libXrender.so.1 => /usr/lib/x86_64-linux-gnu/libXrender.so.1 (0x00007f5fdc6d5000)
libXtst.so.6 => /usr/lib/x86_64-linux-gnu/libXtst.so.6 (0x00007f5fdc4cf000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f5fdc106000)
/lib64/ld-linux-x86-64.so.2 (0x00007f5fe8b2b000)
libfreetype.so.6 => /usr/lib/x86_64-linux-gnu/libfreetype.so.6 (0x00007f5fdbe63000)
libfontconfig.so.1 => /usr/lib/x86_64-linux-gnu/libfontconfig.so.1 (0x00007f5fdbc27000)
libgtk-3.so.0 => /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 (0x00007f5fdb516000)
libgdk-3.so.0 => /usr/lib/x86_64-linux-gnu/libgdk-3.so.0 (0x00007f5fdb26f000)
libpangocairo-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libpangocairo-1.0.so.0 (0x00007f5fdb062000)
libpango-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libpango-1.0.so.0 (0x00007f5fdae15000)
libatk-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libatk-1.0.so.0 (0x00007f5fdabf3000)
libcairo-gobject.so.2 => /usr/lib/x86_64-linux-gnu/libcairo-gobject.so.2 (0x00007f5fda9ea000)
libcairo.so.2 => /usr/lib/x86_64-linux-gnu/libcairo.so.2 (0x00007f5fda6df000)
libgdk_pixbuf-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0 (0x00007f5fda4be000)
libgio-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0 (0x00007f5fda14a000)
libgobject-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 (0x00007f5fd9ef9000)
libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0 (0x00007f5fd9bf1000)
libdbus-glib-1.so.2 => /usr/lib/x86_64-linux-gnu/libdbus-glib-1.so.2 (0x00007f5fd99ca000)
libdbus-1.so.3 => /lib/x86_64-linux-gnu/libdbus-1.so.3 (0x00007f5fd9785000)
libxcb-shm.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-shm.so.0 (0x00007f5fd9582000)
libX11-xcb.so.1 => /usr/lib/x86_64-linux-gnu/libX11-xcb.so.1 (0x00007f5fd9380000)
libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f5fd9161000)
libXcursor.so.1 => /usr/lib/x86_64-linux-gnu/libXcursor.so.1 (0x00007f5fd8f57000)
libXi.so.6 => /usr/lib/x86_64-linux-gnu/libXi.so.6 (0x00007f5fd8d47000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f5fd8a43000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f5fd882d000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f5fd8614000)
libpng12.so.0 => /lib/x86_64-linux-gnu/libpng12.so.0 (0x00007f5fd83ee000)
libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x00007f5fd81c4000)
libgmodule-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgmodule-2.0.so.0 (0x00007f5fd7fc0000)
libatk-bridge-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libatk-bridge-2.0.so.0 (0x00007f5fd7d95000)
libpangoft2-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libpangoft2-1.0.so.0 (0x00007f5fd7b80000)
libXinerama.so.1 => /usr/lib/x86_64-linux-gnu/libXinerama.so.1 (0x00007f5fd797d000)
libwayland-client.so.0 => /usr/lib/x86_64-linux-gnu/libwayland-client.so.0 (0x00007f5fd7770000)
libxkbcommon.so.0 => /usr/lib/x86_64-linux-gnu/libxkbcommon.so.0 (0x00007f5fd7536000)
libwayland-cursor.so.0 => /usr/lib/x86_64-linux-gnu/libwayland-cursor.so.0 (0x00007f5fd732e000)
libthai.so.0 => /usr/lib/x86_64-linux-gnu/libthai.so.0 (0x00007f5fd7125000)
libpixman-1.so.0 => /usr/lib/x86_64-linux-gnu/libpixman-1.so.0 (0x00007f5fd6e7d000)
libxcb-render.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-render.so.0 (0x00007f5fd6c74000)
libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007f5fd6a51000)
libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007f5fd6836000)
libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6 (0x00007f5fd662e000)
libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007f5fd63f0000)
libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007f5fd61ec000)
libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007f5fd5fe6000)
libatspi.so.0 => /usr/lib/x86_64-linux-gnu/libatspi.so.0 (0x00007f5fd5dba000)
libharfbuzz.so.0 => /usr/lib/x86_64-linux-gnu/libharfbuzz.so.0 (0x00007f5fd5b65000)
libdatrie.so.1 => /usr/lib/x86_64-linux-gnu/libdatrie.so.1 (0x00007f5fd595e000)
libgraphite2.so.3 => /usr/lib/x86_64-linux-gnu/libgraphite2.so.3 (0x00007f5fd5737000)
what baffles me is the appimage variant produces the same result.
i am wondering whether the unity desktop loads a different version of one of the bundled libs before firefox is started which may explain quite a few things
lsof says the libssl and libnss present in /opt/firefox are the ones that are loaded but a bunch of system libs which are not in /opt are used by firefox
$ lsof -p `pgrep firefox` | sed '/x86_64/! d ; s/.*\///' | sort -u | tr "\n" " "
lsof: WARNING: can't stat() ext4 file system /var/lib/docker/aufs
Output information may be incomplete.
event-sound-cache.tdb.11e9f13b8147377154a7a07751b4884a.x86_64-pc-linux-gnu gconv-modules.cache im-ibus.so ld-2.19.so libasound_module_pcm_pulse.so libasound.so.2.0.0 libasyncns.so.0.3.1 libatk-1.0.so.0.21009.1 libatk-bridge-2.0.so.0.0.0 libatspi.so.0.0.1 libc-2.19.so libcairo-gobject.so.2.11301.0 libcairo.so.2.11301.0 libcanberra-alsa.so libcanberra-gtk3-module.so libcanberra-gtk3.so.0.1.9 libcanberra.so.0.2.5 libcgmanager.so.0.0.0 libcroco-0.6.so.3.0.1 libdatrie.so.1.3.1 libdbus-1.so.3.7.6 libdbus-glib-1.so.2.2.2 libdconfsettings.so libdl-2.19.so libexpat.so.1.6.0 libffi.so.6.0.1 libFLAC.so.8.3.0 libfontconfig.so.1.8.0 libfreetype.so.6.11.1 libgcc_s.so.1 libgdk-3.so.0.1000.8 libgdk_pixbuf-2.0.so.0.3000.7 libgio-2.0.so.0.4002.0 libglib-2.0.so.0.4002.0 libgmodule-2.0.so.0.4002.0 libgobject-2.0.so.0.4002.0 libgraphite2.so.3.0.1 libgtk-3.so.0.1000.8 libgvfscommon.so libgvfsdbus.so libharfbuzz.so.0.927.0 libibus-1.0.so.5.0.505 libICE.so.6.3.0 libjson-c.so.2.0.0 libltdl.so.7.3.0 liblzma.so.5.0.0 libm-2.19.so libnih-dbus.so.1.0.0 libnih.so.1.0.0 libnsl-2.19.so libnss_compat-2.19.so libnss_dns-2.19.so libnss_files-2.19.so libnss_mdns4_minimal.so.2 libnss_mdns4.so.2 libnss_nis-2.19.so libogg.so.0.8.1 liboverlay-scrollbar.so libpango-1.0.so.0.3600.3 libpangocairo-1.0.so.0.3600.3 libpangoft2-1.0.so.0.3600.3 libpcre.so.3.13.1 libpixbufloader-png.so libpixbufloader-svg.so libpixman-1.so.0.30.2 libpng12.so.0.50.0 libpthread-2.19.so libpulsecommon-4.0.so libpulse.so.0.16.2 libresolv-2.19.so librsvg-2.so.2.40.2 librt-2.19.so libselinux.so.1 libSM.so.6.0.1 libsndfile.so.1.0.25 libstdc++.so.6.0.19 libtdb.so.1.3.8 libthai.so.0.2.0 libudev.so.1.3.5 libunico.so libunity-gtk3-parser.so.0.0.0 libunity-gtk-module.so libuuid.so.1.3.0 libvorbisenc.so.2.0.8 libvorbisfile.so.3.3.4 libvorbis.so.0.4.5 libwayland-client.so.0.2.0 libwayland-cursor.so.0.0.0 libwrap.so.0.7.6 libX11.so.6.3.0 libX11-xcb.so.1.0.0 libXau.so.6.0.0 libxcb-render.so.0.0.0 libxcb-shm.so.0.0.0 libxcb.so.1.1.0 libXcomposite.so.1.0.0 libXcursor.so.1.0.2 libXdamage.so.1.1.0 libXdmcp.so.6.0.0 libXext.so.6.4.0 libXfixes.so.3.1.0 libXinerama.so.1.0.0 libXi.so.6.1.0 libxkbcommon.so.0.0.0 libxml2.so.2.9.1 libXrandr.so.2.2.0 libXrender.so.1.3.0 libXss.so.1.0.0 libXtst.so.6.1.0 libz.so.1.2.8 alexb@alexb-TOSH:~$ lsof -p `pgrep firefox` | sed '/x86_64/! d ; s/.*\///' | sort -u | tr "\n" " "
Are tere actual version differences between the system libraries and the ones in /opt?
If you maybe force the /opt ones to be used anyway this will probably be more stable. Mixing "near equal" libraries does sometimes have interesting side effects.
If you maybe force the /opt ones to be used anyway this will probably be more stable. Mixing "near equal" libraries does sometimes have interesting side effects.
ASKER
the libs in /opt are all loaded by ff as expected. the other libs are not provided by ff. i guess the developers expect them to be present on the system.
i will check each of them have satisfiable dependencies tomorrow but i do not expect that much since wrong versions would probably end up with a crash on startup.
if the libs are actually the issue, i guess i can bundle more recent ones and change the elf headers adequately.
do you think a compiled version is worth a shot ?
i will check each of them have satisfiable dependencies tomorrow but i do not expect that much since wrong versions would probably end up with a crash on startup.
if the libs are actually the issue, i guess i can bundle more recent ones and change the elf headers adequately.
do you think a compiled version is worth a shot ?
can the above ldd errors be the cause of the issue in your opinion ? i have a hard time seeing why they would since nss does not seem related.
one extra info : closing subwindows such as select menus produce the same issue. i am thinking gtk3 might be messing x11 commmunication somehow
A build from source should at least provide a version that matches everything from the native system...
(if compiletime / link time options actualy make a difference.).
(It were gtk/gnome libraries i meant when mentioning double free issues, for Firefox there was one, but that was solved in 2013 (before Ubuntu 14).
I found this one.... familiar?
https://askubuntu.com/questions/572948/unity-freezes-when-closing-or-minimizing-a-window
(if compiletime / link time options actualy make a difference.).
(It were gtk/gnome libraries i meant when mentioning double free issues, for Firefox there was one, but that was solved in 2013 (before Ubuntu 14).
I found this one.... familiar?
https://askubuntu.com/questions/572948/unity-freezes-when-closing-or-minimizing-a-window
ASKER
hi all
some update on this issue :
downgrading 2.40.2-0ubuntu1.1+esm4 to 2.40.2-0ubuntu1.1 modifies the behavior : the window closes before firefox crashes. i have no idea what esm4 is. i googled to no avail.
using the latest long term support release of firefox firefox-91.7.1esr.tar.bz2 works perfectly
--
i am still interested in figuring out the cause of the issue. assuming my hunch is correct, ff hits a bug in libglib2 which is probably related to synchronisation between threads.
this is extracted from the documentation of the g_bit_lock function which seems to be the event on which FF hangs
if anyone knows how to debug further, i am interested. my gbd knowledge is quite limited so i do not think i can dig much deeper in a reasonable amount of time.
if you know what esm4 is, the info is very welcome as well
thanks for your help so far
some update on this issue :
downgrading 2.40.2-0ubuntu1.1+esm4 to 2.40.2-0ubuntu1.1 modifies the behavior : the window closes before firefox crashes. i have no idea what esm4 is. i googled to no avail.
using the latest long term support release of firefox firefox-91.7.1esr.tar.bz2 works perfectly
--
i am still interested in figuring out the cause of the issue. assuming my hunch is correct, ff hits a bug in libglib2 which is probably related to synchronisation between threads.
this is extracted from the documentation of the g_bit_lock function which seems to be the event on which FF hangs
Sets the indicated lock_bit in address . If the bit is already set, this call will block until g_bit_unlock() unsets the corresponding bit.
Attempting to lock on two different bits within the same integer is not supported and will very probably cause deadlocks.
The value of the bit that is set is (1u << bit ). If bit is not between 0 and 31 then the result is undefined.
if anyone knows how to debug further, i am interested. my gbd knowledge is quite limited so i do not think i can dig much deeper in a reasonable amount of time.
if you know what esm4 is, the info is very welcome as well
thanks for your help so far
ESM is Most probably Extended Security Maintenance releasse... the 4 must mean the Forth...
http://www.releases.ubuntu.com/trusty/ (the current release is #6).
1 down..... the other is more problematic.
with the lock...., that would make sense, but if only threads get locked then how can other processes get locked... (all windows get greyed was mentioned before). So that can only happen if the bug is within the gnome windows manager.
http://www.releases.ubuntu.com/trusty/ (the current release is #6).
1 down..... the other is more problematic.
with the lock...., that would make sense, but if only threads get locked then how can other processes get locked... (all windows get greyed was mentioned before). So that can only happen if the bug is within the gnome windows manager.
ASKER
thanks. esm is indeed extended maintenance release. the downgrade is a one way trip since april the 1rst when canonical decided to ask for paid subscription to access said repositories. took me a while to get things back straight.
regarding the bug itself, my understanding is the main process hangs and the unity desktop or maybe indeed the compiz window manager decides the program is hanged.
i do not think i can debug further in a reasonable amount of time, so i am closing this question.
thanks a lot for your help
regarding the bug itself, my understanding is the main process hangs and the unity desktop or maybe indeed the compiz window manager decides the program is hanged.
i do not think i can debug further in a reasonable amount of time, so i am closing this question.
thanks a lot for your help
N.p. good luck juggling this one to stay alive.
End Of Life 2014 is a very long time ago.
You mentioned, "i DO NOT WISH to discuss whether using ubuntu 14 is a good idea".
It's not really if running Trusty is a good or bad idea, it's just that each day... you'll have more + more problems with new software crashing on an old OS like Trusty.
1) does anyone have a idea why this would happen?
Old Bible story talks about the problem of putting new wine (FireFox) in an old wine skin (Trusty), which will cause the old wine skin to leak then burst (FireFox crash).
So the answer to the why is, you're running Trusty.
2) or how to debug it?
Finding the exact reason is simple.
Look at your FireFox run logs which will likely show the exact problem or run FireFox under gdb (which will likely require you build FireFox + all libraries from source).
3) or experienced anything similar ?
To experience something similar would require someone to be running Trusty + FireFox.
No one adverse to being repeatedly hacked... without knowing they're hacked... would ever install Trusty.