Talk about code development, features, specific bugs, enhancements, patches, and similar things.
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.
-
Angii
Unread post
by Angii » 2018-05-02, 01:16
I've been just dealing with this problem for a while, but recently it happened to me abruptly immediately after reopening Pale Moon. I have a feeling that it may be something else in my setup causing this, but it only seems to have happened to pale moon the past few months, so I figured I should finally post about it. Every once in a while, Pale Moon will abruptly close itself. I started running it via a terminal so I could see what causes it, and every time it abruptly closes, it outputs:
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:259: poll_for_event: Assertion `!xcb_xlib_threads_sequence_lost' failed.
Aborted
I did a small amount of digging, and I haven't seen anyone else having this issue (let alone for the past monthish or so like I have), but I'm not sure what could be causing this to specifically affect Pale Moon, let alone Pale Moon across many versions. The builds this has been happening on are the ones installed via the official tool (pm-installer.sh) and not ones that I've compiled or anything. If anyone might have any insight, I thank you in advance; this has begun to confuse me a fair bit.
-
Moonchild
- Pale Moon guru
![Pale Moon guru Pale Moon guru](./images/ranks/founder.png)
- Posts: 35648
- Joined: 2011-08-28, 17:27
- Location: Motala, SE
Unread post
by Moonchild » 2018-05-02, 09:50
From what little I know (and I may be wrong) using xcb instead of xlib might not work very well; our cairo lib only has experimental support for xcb.
Not that I'd have any idea how to help you configure your X server to use something else though, but that seems to be a clue. Other people more familiar with X should chime in.
"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
-
Walter Dnes
- Astronaut
![Astronaut Astronaut](./images/ranks/rank8.png)
- Posts: 652
- Joined: 2015-07-30, 20:29
- Location: Vaughan, ON, Canada
Unread post
by Walter Dnes » 2018-05-02, 21:22
Angii wrote:The builds this has been happening on are the ones installed via the official tool (pm-installer.sh) and not ones that I've compiled or anything.
Your personal builds are not crashing, while the official build is; correct? Maybe we can narrow things down by looking at the differences in the builds, to see what's causing the different behaviour. Which compiler are you using, and can you post your mozconfig? What distro (32/64 bits) are you using?
There's a right way
There's a wrong way
And then there's my way
-
Angii
Unread post
by Angii » 2018-05-03, 00:59
Moonchild wrote: [...] our cairo lib only has experimental support for xcb. [...]
That could be it, I genuinely am not particularly knowledgeable about Xlib and xcb, so I suppose anything is possible here; I thought applications could choose which they wanted to use when both are present, but I could be mistaken for sure.
Walter Dnes wrote:
Your personal builds are not crashing, while the official build is; correct?[...] What distro (32/64 bits) are you using?
Ah, sorry for the misunderstanding, I was just saying that they were official builds so nobody thought it was just my own builds messing up; I have not tried compiling Pale Moon myself to see if that corrects the issue. Mozconfig is used in building Pale Moon/Firefox, right? I don't think I have one, as such. The distro I'm using is Void Linux (64bit), though; it's possible it's a distro issue, but I haven't seen any xcb errors on the distro's forums (first place I looked to, figuring it was a bad lib update or something). This genuinely does not generally happen that often, maybe every couple of days (sometimes not for a week+) of Pale Moon being open (but then sometimes multiple times in a row quickly upon reopening PM), dmesg never has anything to say during these times, either. I'm not sure where else I would look for relevant log information regarding the issue.
-
Angii
Unread post
by Angii » 2018-05-05, 21:39
A small secondary question (I'm not a fan of double posting, but I just noticed this today), I noticed Pale Moon has a launch option (--sync) which has as its description: "Make X calls synchronous." Is it possible that this would solve my problem as a band-aid, so to speak? I'm not exactly sure what is causing the xcb error, but it seems (to my untrained eye, I guess) to be things somehow being lost in a sequence, so perhaps this would solve it? I'm not aware what --sync does beyond it's description, so it's possible it's entirely unrelated, but, I thought it might be worth an ask.
EDIT: Can already confirm it doesn't help, had the same issue pop up while running PM with --sync just to see if it helped at all. Oh well, that was worth a shot at least.
Last edited by Angii on 2018-05-05, 23:05, edited 1 time in total.
-
vannilla
- Moon Magic practitioner
![Moon Magic practitioner Moon Magic practitioner](./images/ranks/rank11.png)
- Posts: 2194
- Joined: 2018-05-05, 13:29
Unread post
by vannilla » 2018-05-06, 12:07
XCB supports thread out of the box, so in a pure XCB setup there shouldn't be thread-related issues unless the programmer does some dark magic with the library (it is not 100% thread safe, even though normally there are no problems).
Threads are a problem with Xlib, and, in fact, what you see is an error from that library. It's prefixed with "[xcb]" because whoever is using XCB calls is configured to intercept events and errors generated by Xlib calls.
Since I don't know what uses XCB in Pale Moon, I can't think of any possible cause, but my guess is that there's something that normally would use XCB but for some actions require the use of Xlib, like OpenGL.
About the "--sync" flag, that has nothing to do with multithread, but with communication between the application (in this case Pale Moon) and the X server.
Most messages are asynchronous, as they send a request to the server which will apply them when the application says so (e.g. with XFlush).
Making them synchronous means that the server will apply the request as soon as it's received, which is the last thing you want (it makes things slower, and in some cases can actually cause problems).
I hope my explanation can help finding the issue (I never had this problem by the way).
-
dinosaur
- Fanatic
![Fanatic Fanatic](./images/ranks/rank6.png)
- Posts: 165
- Joined: 2014-06-03, 09:26
- Location: France
Unread post
by dinosaur » 2018-05-12, 12:10
To ensure Xlib (and all libraries consuming it) is properly initialized in thread-safe mode, you must make sure that XInitThreads() is called before any other call (direct or indirect) to Xlib.
In Pale Moon, this call appears in toolkit/xre/nsAppRunner.cpp (around line 3242 in current PM version), where you can see:
Code: Select all
#ifdef MOZ_X11
// Init X11 in thread-safe mode. Must be called prior to the first call to XOpenDisplay
// (called inside gdk_display_open). This is a requirement for off main tread compositing.
// This is done only on X11 platforms if the environment variable MOZ_USE_OMTC is set so
// as to avoid overhead when omtc is not used.
//
// On nightly builds, we call this by default to enable OMTC for Electrolysis testing. On
// aurora, beta, and release builds, there is a small tpaint regression from enabling this
// call, so it sits behind an environment variable.
//
// An environment variable is used instead of a pref on X11 platforms because we start having
// access to prefs long after the first call to XOpenDisplay which is hard to change due to
// interdependencies in the initialization.
# ifndef NIGHTLY_BUILD
if (PR_GetEnv("MOZ_USE_OMTC") ||
PR_GetEnv("MOZ_OMTC_ENABLED"))
# endif
{
XInitThreads();
}
#endif
Obviously, if NIGHTLY_BUILD is undefined (or 0) and neither of MOZ_USE_OMTC or MOZ_OMTC_ENABLED environment variables are set, then XInitThreads() is *not* called.
I suggest systematically calling XInitThreads() instead (it won't hurt PM since Electrolysis is not used).
Note that some OpenGL drivers (e.g. NVIDIA's proprietary driver) will need Xlib to be initialized multi-threaded in order to be able to themselves use multi-threaded rendering.
Last edited by dinosaur on 2018-05-12, 12:21, edited 4 times in total.
-
Moonchild
- Pale Moon guru
![Pale Moon guru Pale Moon guru](./images/ranks/founder.png)
- Posts: 35648
- Joined: 2011-08-28, 17:27
- Location: Motala, SE
Unread post
by Moonchild » 2018-05-12, 12:30
@Dinosaur: If this was a systematic issue then Pale Moon would fail on ANY Linux/X11 system -- that's obviously not the case.
It would be interesting to know if setting MOZ_USE_OMTC solves the issue for the OP. If so, then for some reason they system assumes or uses xlib multithreaded even if consumers do not.
"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
-
dinosaur
- Fanatic
![Fanatic Fanatic](./images/ranks/rank6.png)
- Posts: 165
- Joined: 2014-06-03, 09:26
- Location: France
Unread post
by dinosaur » 2018-05-12, 13:14
Moonchild wrote:@Dinosaur: If this was a systematic issue then Pale Moon would fail on ANY Linux/X11 system -- that's obviously not the case.
Not systematic, no... There are so many desktop environments, window managers, compositors, plus X11, (X)Wayland versions, display drivers, not to count the amount of Linux distros, each with their own versions of the various libraries...
Moonchild wrote:It would be interesting to know if setting MOZ_USE_OMTC solves the issue for the OP.
Yep, for a start...
Note that I am currently running a XInitThreads()-forced custom PM build, with no trouble whatsoever.
-
Angii
Unread post
by Angii » 2018-05-13, 22:26
Thanks for looking into the problem, everyone! I've set the environment variable MOZ_OMTC_ENABLED=1 to see if this solves the problem; as the issue was rather sporadic (could go a week or more before having a sudden close) I won't know for sure if this has resolved the problem until nothing happens for a while, I suppose. I've stuck this into my /etc/environment as well to ensure I don't forget to set it whenever I restart my laptop. Again, thanks so much for the help, I know I never would've figured this out on my own, nor did I really know enough about Xlib/xcb to know where to start looking, either. If I don't have any sudden problems for a week or two I guess it's safe to assume setting the variable solved my problem and report back here. I'll swing back by if it doesn't solve my problem as well; although, if setting this environment variable ensures Pale Moon calls XInitThreads() I can't imagine it not solving my problem. Thanks again, everyone.
-
Angii
Unread post
by Angii » 2018-05-15, 22:07
Weirdly enough, the sudden close just happened for me again. Same error as before was printed:
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.
I was sure to check my environment variables afterwards, and yes, MOZ_OMTC_ENABLED=1 is still present; I'm not quite sure what to make of this now. I suppose it may be an issue with the xlib or xcb libraries present in my distro, but PM is the only program which experiences this problem. I suppose my next step is to try a fresh profile just to ensure there isn't some odd lingering issue there. As I'm the only one with this problem, I think it's fairly clear isn't a defect in Pale Moon however, so I'll mark this as solved and try that. Thanks for all the help, everyone! If starting a fresh profile solves it I'll be sure to post a note about it later.
-
Moonchild
- Pale Moon guru
![Pale Moon guru Pale Moon guru](./images/ranks/founder.png)
- Posts: 35648
- Joined: 2011-08-28, 17:27
- Location: Motala, SE
Unread post
by Moonchild » 2018-05-17, 18:18
Well, it's clear then that not calling XinitThreads isn't the issue. So, it was a nice theory, but alas incorrect.
If this was the case I would have expected to have heard from this much much much sooner, anyway.
"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
-
Walter Dnes
- Astronaut
![Astronaut Astronaut](./images/ranks/rank8.png)
- Posts: 652
- Joined: 2015-07-30, 20:29
- Location: Vaughan, ON, Canada
Unread post
by Walter Dnes » 2018-05-27, 16:52
Yes, I know "Pale Moon is not Firefox", but it still shares a lot of code. On the Gentoo mailing list, there's a similar report for Firefox.
https://archives.gentoo.org/gentoo-user/message/b95e1d9f66afad5bb53f225ad35cf203 It may be related to a recent "upgrade" in components of X,
Since the last Xorg upgrade the week of May 20th, firefox seems to quit
(ie. crash) sporadically when I play chess on lichess.org. That leaves
me very unhappy
![Sad :-(](./images/smilies/icon_e_sad.gif)
There is a log message:
[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.
firefox: /var/tmp/portage/x11-libs/libX11-1.6.5/work/libX11-1.6.5/src/xcb_io.c:259: poll_for_event: Assertion `!xcb_xlib_threads_sequence_lost' failed.
At first I thought this was a firefox problem because it was updated
about the same time. But then I intentionally downgraded firefox back
to what I thought was the "stable" version (52.6.0), and the problem
persists, so I now think it is X, either xcb or some other piece.
There's a right way
There's a wrong way
And then there's my way
-
Moonchild
- Pale Moon guru
![Pale Moon guru Pale Moon guru](./images/ranks/founder.png)
- Posts: 35648
- Joined: 2011-08-28, 17:27
- Location: Motala, SE
Unread post
by Moonchild » 2018-05-28, 02:31
If anyone has more info or a related bugzilla bug to follow, I'd be interested.
"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
-
Walter Dnes
- Astronaut
![Astronaut Astronaut](./images/ranks/rank8.png)
- Posts: 652
- Joined: 2015-07-30, 20:29
- Location: Vaughan, ON, Canada
Unread post
by Walter Dnes » 2018-05-28, 04:05
Moonchild wrote:If anyone has more info or a related bugzilla bug to follow, I'd be interested.
A bit of Googling turns up a couple of items
There's a right way
There's a wrong way
And then there's my way
-
Moonchild
- Pale Moon guru
![Pale Moon guru Pale Moon guru](./images/ranks/founder.png)
- Posts: 35648
- Joined: 2011-08-28, 17:27
- Location: Motala, SE
Unread post
by Moonchild » 2018-05-28, 06:55
Walter: see posts above -- XInitThreads does not fix the issue.
"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
-
linuxrocks123
- Moonbather
![Moonbather Moonbather](./images/ranks/rank4.png)
- Posts: 50
- Joined: 2015-12-14, 07:57
- Location: Moon Base Alpha
Unread post
by linuxrocks123 » 2018-12-04, 10:31
This issue has been a problem for me for some time after updating Slackware Current on my desktop; I've avoided updating Slackware on my laptop for fear of causing the problem to happen on it as well.
It appears this issue is happening with Fedora as well:
https://forums.fedoraforum.org/showthre ... n-crashing
It must have something to do with a recent version of some library update; my guess would be libpthread-stubs from the fact that xcb is complaining. I'm willing to answer questions or do tests about the differences between versions of packages installed on my desktop and laptop if it would help narrow down what is causing this. It's frustrating because Pale Moon has become almost unusable on my desktop.
Last edited by linuxrocks123 on 2018-12-04, 10:38, edited 1 time in total.
-
OllyBain
Unread post
by OllyBain » 2018-12-23, 10:04
It's quite an annoying problem. It was not present in Fedora 27 (LXDE), but appeared for Fedora 28 (LXDE), with gigabytes of hard drive space vanishing after the crash. Now, I have switched to Manjaro LXDE, and it is still occurring. The error messages are the same. Could it be the LXDE library files as opposed to the choice of linux?
The error messages are still similar: (22 December 2018)
[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.
Aborted (core dumped)
-
vannilla
- Moon Magic practitioner
![Moon Magic practitioner Moon Magic practitioner](./images/ranks/rank11.png)
- Posts: 2194
- Joined: 2018-05-05, 13:29
Unread post
by vannilla » 2018-12-23, 13:23
OllyBain wrote:Could it be the LXDE library files as opposed to the choice of linux?
Most likely.
After all, the X server isn't Linux-specific; it runs even on Windows.
Do the LXDE developers apply particular patches or special build configurations to GTK or whatever they use for their environment?