Odd problem, multithread issue? Topic is solved
Forum rules
Please keep everything here strictly on-topic.
This board is meant for Pale Moon source code development related subjects only like code snippets, patches, specific bugs, git, the repositories, etc.
This is not for tech support! Please do not post tech support questions in the "Development" board!
Please make sure not to use this board for support questions. Please post issues with specific websites, extensions, etc. in the relevant boards for those topics.
Please keep things on-topic as this forum will be used for reference for Pale Moon development. Expect topics that aren't relevant as such to be moved or deleted.
Please keep everything here strictly on-topic.
This board is meant for Pale Moon source code development related subjects only like code snippets, patches, specific bugs, git, the repositories, etc.
This is not for tech support! Please do not post tech support questions in the "Development" board!
Please make sure not to use this board for support questions. Please post issues with specific websites, extensions, etc. in the relevant boards for those topics.
Please keep things on-topic as this forum will be used for reference for Pale Moon development. Expect topics that aren't relevant as such to be moved or deleted.
Re: Odd problem, multithread issue?
Just a quick Observation: I have run into the same error, both with PaleMoon and the Citrix ICA client. (on ArchLinux)
I had maybe a crash every 1-2 weeks, after setting MOZ_OMTC_ENABLED=1 a month went by without a crash.
Next I will try taking that out, and running both PaleMoon and the Citrix Client with LIBGL_DRI3_DISABLE=true for the next month, and see what happens there...
I had maybe a crash every 1-2 weeks, after setting MOZ_OMTC_ENABLED=1 a month went by without a crash.
Next I will try taking that out, and running both PaleMoon and the Citrix Client with LIBGL_DRI3_DISABLE=true for the next month, and see what happens there...
PM crashes in Fedora 29
Code: Select all
[xcb] Unknown sequence number while processing queue
[xcb] Most likely this is a multi-threaded client and XInitThreads has not been called
[xcb] Aborting, sorry about that.
palemoon: xcb_io.c:263: poll_for_event: Assertion `!xcb_xlib_threads_sequence_lost' failed.
[NPAPI 5341] ###!!! ABORT: Aborting on channel error.: file /home/PM4Linux/REPO/UXP/ipc/glue/MessageChannel.cpp, line 2133
[NPAPI 5341] ###!!! ABORT: Aborting on channel error.: file /home/PM4Linux/REPO/UXP/ipc/glue/MessageChannel.cpp, line 2133
Re: PM crashes in Fedora 29
Sigh.
viewtopic.php?f=3&t=49Moonchild wrote:When you ask for support, try to give at least basic information about your setup as well
Nichi nichi kore ko jitsu = Every day is a good day.
Re: PM crashes in Fedora 29
Nigaikaze wrote:Sigh.viewtopic.php?f=3&t=49Moonchild wrote:When you ask for support, try to give at least basic information about your setup as well
Re: PM crashes in Fedora 29
openbox + xfce4-panel + xfce4-terminal:
Code: Select all
Failed to open VDPAU backend libvdpau_va_gl.so: cannot open shared object file: No such file or directory
1550833470336 addons.update-checker WARN update.rdf: Update manifest for {2b10c1c8-a11f-4bad-fe9c-1c11e82cac42} did not contain an updates property
1550833470378 addons.update-checker WARN update.rdf: Update manifest for uBlock0@raymondhill.net did not contain an updates property
Failed to open VDPAU backend libvdpau_va_gl.so: cannot open shared object file: No such file or directory
W/MPEG4Extractor( 4570): Error -1004 parsing chunck at offset 246 looking for first track
W/MPEG4Extractor( 4570): Error -1004 parsing chunck at offset 246 looking for first track
[xcb] Unknown sequence number while processing queue
[xcb] Most likely this is a multi-threaded client and XInitThreads has not been called
[xcb] Aborting, sorry about that.
palemoon: xcb_io.c:263: poll_for_event: Assertion `!xcb_xlib_threads_sequence_lost' failed.
Re: PM crashes in Fedora 29
This may have some useful info: viewtopic.php?f=37&t=19034&hilit=xcb
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite
Odd problem, multithread issue? (2)
Hello, not sure why the previous https://forum.palemoon.org/viewtopic.php?f=37&t=19034 is locked to me "This topic is locked, you cannot edit posts or make further replies.", hence I continue in here.
Since I've fully switched to the PM few months ago, I've been affected by the same issue a lot, seeing crashes sometimes 5-6 times a day.
Altough I'm not any debugging professional, I tried to collect some data (steps for it found at Arch Wikipedia).
I'm running Arch Linux, up-to-date SW updates, PM being taken from AUR (have also tried the precompiled one from PM website, but makes no difference).
Those listed as "truncated" are taking about 257MB on the drive, which is a lz4 compressed file (about 2GB binary file when decompressed).
These lz4 files could be provided if needed.
Those "missing" were already somehow removed, automatically I presume.
But when they were still showing "present", I collected their data with commands like:
That data I provide in here as attachment "20200302-collected_data.zip" (log files named "YYYY-MM-DD_HHMMSS-coredumpctl_gdb_$PID-bt_full.log").
I also tried manual GDB debugging of the PM process with commands (output is in the attachment, file "2020-01-31_072529-coredumpctl_gdb-manual-bt_full.log"):
Another one I tried was strace (in attachment log files: "2020-02-11_112100-strace_eopen.log" and "strace-2020-02-28_08h10m07s.log"), strace command:
While it doesn't generate much of log data, while running PM with STRACE I noticed it's been crashing much less, quite a difference.
As if the strace was causing some sort of delays for the PM.
I just hope, that this all would be useful somehow.
Since I've fully switched to the PM few months ago, I've been affected by the same issue
Code: Select all
[xcb] Unknown sequence number while processing queue
[xcb] Most likely this is a multi-threaded client and XInitThreads has not been called
[xcb] Aborting, sorry about that.
palemoon: xcb_io.c:260: poll_for_event: Assertion `!xcb_xlib_threads_sequence_lost' failed.
Aborted (core dumped)
Altough I'm not any debugging professional, I tried to collect some data (steps for it found at Arch Wikipedia).
I'm running Arch Linux, up-to-date SW updates, PM being taken from AUR (have also tried the precompiled one from PM website, but makes no difference).
Code: Select all
# coredumpctl list
TIME PID UID GID SIG COREFILE EXE
Mon 2020-01-20 07:26:03 CET 12163 1000 100 6 missing /usr/lib/palemoon/palemoon
Mon 2020-01-20 10:08:27 CET 181688 1000 100 6 missing /usr/lib/palemoon/palemoon
Mon 2020-01-20 10:16:30 CET 691522 1000 100 6 missing /usr/lib/palemoon/palemoon
Mon 2020-01-20 10:30:51 CET 714265 1000 100 6 missing /usr/lib/palemoon/palemoon
Mon 2020-01-20 11:10:32 CET 755059 1000 100 6 missing /usr/lib/palemoon/palemoon
Mon 2020-01-20 12:40:42 CET 854964 1000 100 6 missing /usr/lib/palemoon/palemoon
Tue 2020-01-21 07:54:29 CET 151929 1000 100 6 missing /usr/lib/palemoon/palemoon
Tue 2020-01-21 08:03:57 CET 360932 1000 100 6 missing /usr/lib/palemoon/palemoon
Tue 2020-01-21 12:51:29 CET 395305 1000 100 6 missing /usr/lib/palemoon/palemoon
Tue 2020-01-21 12:56:37 CET 1215198 1000 100 6 missing /usr/lib/palemoon/palemoon
Tue 2020-01-21 14:26:34 CET 1226027 1000 100 6 missing /usr/lib/palemoon/palemoon
Wed 2020-01-22 08:59:11 CET 161836 1000 100 6 missing /usr/lib/palemoon/palemoon
Wed 2020-01-22 13:49:54 CET 557427 1000 100 6 missing /usr/lib/palemoon/palemoon
Thu 2020-01-23 10:08:05 CET 53545 1000 100 6 missing /usr/lib/palemoon/palemoon
Thu 2020-01-23 15:40:29 CET 12785 1000 100 6 missing /usr/lib/palemoon/palemoon
Mon 2020-01-27 09:01:53 CET 20249 1000 100 6 missing /usr/lib/palemoon/palemoon
Tue 2020-01-28 15:52:59 CET 61750 1000 100 6 missing /usr/lib/palemoon/palemoon
Wed 2020-01-29 07:37:02 CET 10182 1000 100 6 missing /usr/lib/palemoon/palemoon
Wed 2020-01-29 07:50:00 CET 60006 1000 100 6 missing /usr/lib/palemoon/palemoon
Wed 2020-01-29 08:29:29 CET 61128 1000 100 6 missing /usr/lib/palemoon/palemoon
Wed 2020-01-29 08:31:12 CET 64764 1000 100 6 missing /usr/lib/palemoon/palemoon
Wed 2020-01-29 14:57:59 CET 64995 1000 100 6 missing /usr/lib/palemoon/palemoon
Fri 2020-01-31 07:06:09 CET 18021 1000 100 6 missing /usr/lib/palemoon/palemoon
Fri 2020-01-31 10:04:58 CET 200685 1000 100 6 missing /usr/lib/palemoon/palemoon
Mon 2020-02-10 07:46:32 CET 22501 1000 100 6 missing /usr/lib/palemoon/palemoon
Mon 2020-02-10 09:49:02 CET 69118 1000 100 6 missing /usr/lib/palemoon/palemoon
Tue 2020-02-11 09:59:10 CET 60902 1000 100 6 missing /usr/lib/palemoon/palemoon
Tue 2020-02-11 11:21:00 CET 759891 1000 100 6 missing /usr/lib/palemoon/palemoon
Fri 2020-02-14 14:36:20 CET 66811 1000 100 6 missing /usr/lib/palemoon/palemoon
Tue 2020-02-18 13:01:13 CET 18621 1000 100 6 missing /usr/lib/palemoon/palemoon
Thu 2020-02-20 14:34:40 CET 73400 1000 100 6 missing /usr/lib/palemoon/palemoon
Fri 2020-02-21 08:49:43 CET 71610 1000 100 6 missing /usr/lib/palemoon/palemoon
Fri 2020-02-21 14:42:45 CET 479681 1000 100 6 missing /usr/lib/palemoon/palemoon
Mon 2020-02-24 15:46:19 CET 24539 1000 100 6 missing /usr/lib/palemoon/palemoon
Tue 2020-02-25 10:14:16 CET 13552 1000 100 6 missing /usr/lib/palemoon/palemoon
Fri 2020-02-28 11:14:41 CET 86147 1000 100 6 truncated /usr/lib/palemoon/palemoon
Mon 2020-03-02 08:35:04 CET 14274 1000 100 6 truncated /usr/lib/palemoon/palemoon
These lz4 files could be provided if needed.
Those "missing" were already somehow removed, automatically I presume.
But when they were still showing "present", I collected their data with commands like:
Code: Select all
# coredumpctl gdb PID
(gdb) bt full
I also tried manual GDB debugging of the PM process with commands (output is in the attachment, file "2020-01-31_072529-coredumpctl_gdb-manual-bt_full.log"):
Code: Select all
$ gdb /usr/bin/palemoon
(gdb) set logging on
(gdb) run --no-daemon --verbose
(gdb) bt full
Code: Select all
strace -o /tmp/strace-`date '+%Y-%m-%d_%Hh%Mm%Ss'`.log -eopen /usr/bin/palemoon
As if the strace was causing some sort of delays for the PM.
I just hope, that this all would be useful somehow.
- Attachments
-
- 20200302-collected_data.zip
- (21.99 KiB) Downloaded 9 times
Re: Odd problem, multithread issue?
They are not really useful since there are no debugging symbols.
All it says is that there's something going on with Xlib, which is already known.
Anyway, there aren't many things using Xlib/XCB in Pale Moon: GTK (used for the UI) and maybe the plugin system (if it doesn't use GTK already.)
My guess is that some distros ship with a faulty GTK2. Try compiling GTK2 yourself, install it on top of the one provided by Arch (basically overwrite it) and then try again.
All it says is that there's something going on with Xlib, which is already known.
Anyway, there aren't many things using Xlib/XCB in Pale Moon: GTK (used for the UI) and maybe the plugin system (if it doesn't use GTK already.)
My guess is that some distros ship with a faulty GTK2. Try compiling GTK2 yourself, install it on top of the one provided by Arch (basically overwrite it) and then try again.
Re: Odd problem, multithread issue?
I was afraid of that.vannilla wrote: They are not really useful since there are no debugging symbols.
That would be a rocket science for me already.
I've found only those for windows at the http://archive.palemoon.org/symbols/ .
But I have no idea how to use it.
I would assume, that they would need to be a linux specific and to be compiled with the PM somehow.
Any chance to prepare one for these purporses from you guys (a bzip tarball like you provide on https://linux.palemoon.org/)?
Perhaps also with some guide how to use it (if it would require different steps than those one I've been already been performing)?
Ain't gonna be that easy.vannilla wrote: My guess is that some distros ship with a faulty GTK2. Try compiling GTK2 yourself, install it on top of the one provided by Arch (basically overwrite it) and then try again.
But I can take a look on it, when I'll have some more time.
Re: Odd problem, multithread issue?
It actually is easy: https://developer.gnome.org/gtk2/stable ... lding.html
Of course the argument to "--prefix" is going to be the path to where the package manager installed the distro's GTK.
If you install there, half of that guide does not apply though you might want to reboot the system just in case (it's not strictly required.)
Re: Odd problem, multithread issue?
Sorry for the delay in my answer, because of the current situation worldwide, I was not working with the affected computer that much, to verify the self compiled gtk2.vannilla wrote: ↑2020-03-02, 13:08It actually is easy: https://developer.gnome.org/gtk2/stable ... lding.html
Of course the argument to "--prefix" is going to be the path to where the package manager installed the distro's GTK.
If you install there, half of that guide does not apply though you might want to reboot the system just in case (it's not strictly required.)
I used the following AUR package https://aur.archlinux.org/packages/gtk2-git/ with the following instructions for package build https://aur.archlinux.org/cgit/aur.git/ ... h=gtk2-git
Code: Select all
./configure \
--prefix=/usr \
--sysconfdir=/etc \
--localstatedir=/var \
--with-xinput=yes \
--disable-gtk-doc
Therefore, the default Arch repository gtk2 has been replaced by the AUR one.
Nevertheless, the problem still persists.
Only today I saw already five crashes:
Code: Select all
init RIL[xcb] Unknown sequence number while processing queue
[xcb] Most likely this is a multi-threaded client and XInitThreads has not been called
[xcb] Aborting, sorry about that.
palemoon: xcb_io.c:260: poll_for_event: Assertion `!xcb_xlib_threads_sequence_lost' failed.
Aborted (core dumped)
Re: Odd problem, multithread issue?
Maybe you could try using the files from GTK's official website: https://download.gnome.org/sources/gtk+/2.24/
Pick the latest version (2.24.32), configure and build it, instead of using something from the package manager.
If it still breaks then the issue is even deeper than that.
Pick the latest version (2.24.32), configure and build it, instead of using something from the package manager.
If it still breaks then the issue is even deeper than that.
Re: Odd problem, multithread issue?
Is there any difference between your source and the one from the AUR package?vannilla wrote: ↑2020-05-11, 12:38Maybe you could try using the files from GTK's official website: https://download.gnome.org/sources/gtk+/2.24/
Pick the latest version (2.24.32), configure and build it, instead of using something from the package manager.
If it still breaks then the issue is even deeper than that.
Code: Select all
pkgver=2.24.32+62+g56c6970b02
Code: Select all
https://gitlab.gnome.org/GNOME/gtk.git#branch=gtk-2-24
Re: Odd problem, multithread issue?
vannilla wrote: ↑2020-05-11, 12:38Maybe you could try using the files from GTK's official website: https://download.gnome.org/sources/gtk+/2.24/
Pick the latest version (2.24.32), configure and build it, instead of using something from the package manager.
If it still breaks then the issue is even deeper than that.
Well, I did tried compilation from the official GTK website sources you pointed out.
Code: Select all
wget https://download.gnome.org/sources/gtk+/2.24/gtk+-2.24.32.tar.xz
tar -xf gtk+-2.24.32.tar.xz
cd gtk+-2.24.32
./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var --with-xinput=yes --disable-gtk-doc
make
sudo make install
And within 2 hours I've got another crash:
Code: Select all
[xcb] Unknown sequence number while processing queue
[xcb] Most likely this is a multi-threaded client and XInitThreads has not been called
[xcb] Aborting, sorry about that.
palemoon: xcb_io.c:260: poll_for_event: Assertion `!xcb_xlib_threads_sequence_lost' failed.
Aborted (core dumped)
Re: Odd problem, multithread issue?
Then it means that something else is going on.
The strange thing is that it seems to happen only on certain configurations.
Might as well go all in: compile the latest xorg server like you did for GTK and see what happens.
Probably you need to also compile Xlib and xcb too.
The strange thing is that it seems to happen only on certain configurations.
Might as well go all in: compile the latest xorg server like you did for GTK and see what happens.
Probably you need to also compile Xlib and xcb too.
Re: Odd problem, multithread issue?
Right, which makes it very hard to simulate.
This way I would end up with a Gentoo like compiled Arch linux.
Wouldn't it be easier to prepare some debugging version of PM (for Linux) like (Download x64 tarball), in order to help trace the issue?
Because PM is the only SW having these problems, no other SW is affected.
Re: Odd problem, multithread issue?
As far as I understood the assertion you hit is not in Pale Moon code but in a Linux lib -- a debug version of Pale Moon likely wouldn't help; at most if there's a "lucky" stack trace then it might point to the type of call that causes the lib to assert but even that is unlikely to be able to solve things.
Pale Moon might be the only software that -triggers- it (that you now of), but that doesn't mean that the browser is automatically at fault here.
Pale Moon might be the only software that -triggers- it (that you now of), but that doesn't mean that the browser is automatically at fault here.
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite
Re: Odd problem, multithread issue?
But it would help in fixing the problem.
Once the problem is solved you can go back to "the Arch way".
Anyway if you really want to check with Pale Moon, you can get the debug symbols by compiling it with the right flags.
However as said by Moonchild, the assertion is somewhere in xcb/Xlib, especially if Pale Moon and GTK correctly call the multithread initialization function.