Summary: | [gnome-overlay] gnome-base/gnome-shell-3.2.0-r1 crashes in libmozjs185 (dev-lang/spidermonkey-1.8.5) | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Tilo Prütz <tilo> |
Component: | [OLD] GNOME | Assignee: | Gentoo Linux Gnome Desktop Team <gnome> |
Status: | RESOLVED WORKSFORME | ||
Severity: | critical | CC: | mozilla, n-roeser |
Priority: | Normal | ||
Version: | 10.1 | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
Backtrace
Gnome-Shell backtrace for all threads Debug-Output-Patch Backtrace for all threads with gnome-shell-3.2.1-r1 and spidermonkey-1.8.5-r1 |
Description
Tilo Prütz
2011-10-08 21:15:32 UTC
Created attachment 289265 [details]
Backtrace
Could you please 1. provide a backtrace from all threads (use the "t a a bt" command in gdb); and 2. say in what function the crash is occurring (e.g. if gdb prints something like "Program received signal SIGSEGV [...] in foo_bar ()", then the crash is in function foo_bar()). for 1.: will attach for 2.: Core was generated by `gnome-shell --replace'. Program terminated with signal 11, Segmentation fault. #0 0xb6732884 in array_extra (cx=0x830e760, mode=MAP, argc=<value optimized out>, vp=0xac8fd140) at jsarray.cpp:2838 2838 jsarray.cpp: Datei oder Verzeichnis nicht gefunden. in jsarray.cpp Created attachment 289401 [details]
Gnome-Shell backtrace for all threads
Mozilla team, is there a way for line 2838 of jsarray.cpp in dev-lang/spidermonkey-1.8.5 to result in a segfault? The only way that I can think of is if tvr.addr() returned an invalid pointer. However, looking at the definition of the AutoValueRooter class, that seems to be impossible :/ Something weird is happening. I put some debug code into jsarray.cpp (since I am not a C++ hacker it’s dumb) and now it does no longer crash :(. In Objective-C (where I am from) this would be a good indicator for freed memory which is wrongfully still in use. I will apply the patch just for the sake of completeness. Created attachment 289509 [details, diff]
Debug-Output-Patch
The problem vanished with the last update (which included gnome-shell-3.2.1). It now works without problems with the original spidermonkey-1.8.5 ebuild. Created attachment 295823 [details] Backtrace for all threads with gnome-shell-3.2.1-r1 and spidermonkey-1.8.5-r1 I am seeing this problem with gnome-base/gnome-shell-3.2.1-r1 and dev-lang/spidermonkey-1.8.5-r1. Backtrace attached, but it looks like attachment 289401 [details]. I’d suggest to set the status of this bug report to REOPENED. (In reply to comment #9) > Created attachment 295823 [details] > Backtrace for all threads with gnome-shell-3.2.1-r1 and spidermonkey-1.8.5-r1 > > I am seeing this problem with gnome-base/gnome-shell-3.2.1-r1 and > dev-lang/spidermonkey-1.8.5-r1. Backtrace attached, but it looks like > attachment 289401 [details]. > > I’d suggest to set the status of this bug report to REOPENED. Please re-emerge spidermonkey with USE="debug" and try again? This will enable a bunch of 'assert' logic that will give a useful message to the segfault instead of just a failure. When I build spidermonkey with USE="debug", I get another segfault, which is described in bug 388521. |