GNOME Bugzilla – Bug 688197
Dead lock of the shell
Last modified: 2018-09-25 14:29:41 UTC
Once or twice a day, I'm ending up with a dead lock in the shell (whole screen frozen). It never happened before 3.6. I'm a little bit surprise that another thread also uses libnspr. (gdb) thread apply all bt
+ Trace 231168
Thread 1 (Thread 0x7f51834e59a0 (LWP 29930))
The dead lock is happening by a GC triggered automatically on the main thread and the actual GC thread. We saw these in the past, and solved them by not running the GC periodically. Now I'm increasingly convinced this is an actual SpiderMonkey bug.
I am too. js185 is from 2010, so it's fairly old. There's apparently a js187 release right around the corner, but it's been right around the corner for a year and a half now. I wonder if we should just give up and port gjs to JavaScriptCore like Andy Wingo wants us to do.
I've noticed the shell relies on a particular version of SpiderMonkey. Aren't we missing fixes from more recent version of SpiderMonkey?
We're using the latest version of SpiderMonkey. It's old, but it's the latest version.
(In reply to comment #2) > I wonder if we should just give up and port gjs to JavaScriptCore like Andy > Wingo wants us to do. I've been thinking of that lately, but it won't happen until we have let [a,b] = array; i.e. lexical scoping and destructuring assignment. Also, we need a replacement for E4X too (working GMarkup? that might be a good idea on its own). However, seeing that js 1.8.5 (Firefox 4!) is really the latest standalone SpiderMonkey version, maybe we could put some pressure to have those implemented in JSC?
just to be sure, can you get a trace with debuginfo installed for nspr and spidermonkey?
I can only get debug symbols for nspr, not spidermonkey.
backtrace https://bugzilla.redhat.com/show_bug.cgi?id=878323#c1 similar issue?
Sounds like the same problem to me.
*** Bug 685369 has been marked as a duplicate of this bug. ***
> However, seeing that js 1.8.5 (Firefox 4!) is really the latest standalone > SpiderMonkey version, maybe we could put some pressure to have those > implemented in JSC? Gentoo have spidermonkey 1.8.7 apparently standalone but not mentioned on webpage (unofficial release). IIRC it is not API/ABI compatible though. (My guess is - if the upstream does not support spidermonkey that it would be better to move to jsc/v8. I belive this problem was risen when upstream dropped support for xulrunner). (In reply to comment #6) > just to be sure, can you get a trace with debuginfo installed for nspr and > spidermonkey? I get the trace in bug which was marked as duplicate (trace #231284). I guess it is the most detailed so far.
(In reply to comment #12) > > However, seeing that js 1.8.5 (Firefox 4!) is really the latest standalone > > SpiderMonkey version, maybe we could put some pressure to have those > > implemented in JSC? > > Gentoo have spidermonkey 1.8.7 apparently standalone but not mentioned on > webpage (unofficial release). IIRC it is not API/ABI compatible though. > > (My guess is - if the upstream does not support spidermonkey that it would be > better to move to jsc/v8. I belive this problem was risen when upstream dropped > support for xulrunner). > Does anyone knows what will be future after release of IonMonkey? PS. Is there any plan for solving this bug? I can reproduce the hangs at will (if I have a single program running gnome-shell crashes after unlocking screen and many times even during normal operations).
*** Bug 692356 has been marked as a duplicate of this bug. ***
> Is there any plan for solving this bug? Looks like so: http://imagemacros.files.wordpress.com/2009/06/roomful.jpeg?w=720
Wolfram, I hope that comment was not sarcastic, considering that gjs developers are active right now to make it possible to use js 1.8.8 (Firefox 17), which solves this issue and many more. There is a branch (gjs/wip/mozjs-188) you can test, if you want to speedup the process.
I didn't see mozjs 188 or -9999 in portage, so could you give me any directions to update to latest version?
Indeed, there is no mozjs 188 official tarball, and we're working with firefox developers to have one (see bug 690982). Meanwhile, you can use ricotz's tarball from http://people.ubuntu.com/~ricotz/mozjs/
Do anybody has ebuild for this version? I'm afraid of installing something without portage and doesn't able to implement ebuild for this library for now.
(In reply to comment #16) > Wolfram, I hope that comment was not sarcastic, considering that gjs developers > are active right now to make it possible to use js 1.8.8 (Firefox 17), which > solves this issue and many more. > There is a branch (gjs/wip/mozjs-188) you can test, if you want to speedup the > process. Great. I'm sorry for the form of original question but WM crashing every half an hour or so makes user grumpy even if it is not bug in said WM - and no comments on bug might mean either that devs are busy fixing it or that are busy with other things.
(In reply to comment #19) > Do anybody has ebuild for this version? I'm afraid of installing something > without portage and doesn't able to implement ebuild for this library for now. You should be able to modify the ebuild for mozjs185 and update it to use the new tarball, and apply the three patches. If you're uncomfortable with the tarball as created, you can use the script provided to make one directly from the upstream mozilla-central repository, ff17-esr branch.
I got repro on mozjs188:
+ Trace 231472
Thread 1 (Thread 0x7ff2d84b6940 (LWP 25049))
Inferior 1 [process 25049] will be detached. Quit anyway? (y or n) Detaching from program: /usr/bin/gnome-shell, process 25049
That does not appear to be a GC deadlock
(In reply to comment #23) > That does not appear to be a GC deadlock Posted as bug #692991 .
*** Bug 693407 has been marked as a duplicate of this bug. ***
FWIW, we've fixed the GC deadlock in bug 670200
(In reply to comment #2) > I am too. js185 is from 2010, so it's fairly old. There's apparently a js187 > release right around the corner, but it's been right around the corner for a > year and a half now. > > I wonder if we should just give up and port gjs to JavaScriptCore like Andy > Wingo wants us to do. Honestly, I know this was just an tangent thought, but it would solve the (what seems to be fairly major) issue of an application pulling in a second JS engine just because it wants to show a WebKit canvas. That'd be a nice bonus to getting more regular upstream releases.
We use JS1.7/1.8 features that are part of ES6 but aren't implemented in JSC last I checked, like "let" and destructuring assignment.