GNOME Bugzilla – Bug 164262
Crashes (segfault SIGSEGV in/usr/lib/libmozjs.so) on some javascript, Mozilla doesn't, PPC only?
Last modified: 2009-08-15 18:40:50 UTC
Hi, Galeon crashes with some javascript, for examples on the links of the second part of this site: <http://secunia.com/multiple_browsers_window_injection_vulnerability_test/> Sadly, I could not reproduce this behavior on i386, and the submitter of this bug in the Debian BTS (this is <http://bugs.debian.org/285404>) claims this is PPC specific. I asked someone on IRC to reproduce on PPC, and he couldn't. The submitter sent the following backtrace made with Debian package 1.3.18-2: Program received signal SIGSEGV, Segmentation fault.
+ Trace 54574
Thread 16384 (LWP 24311)
5 Thread 98308 (LWP 24422) 0x0e3b0888 in nanosleep () from /lib/libpthread.so.0 4 Thread 32771 (LWP 24335) 0x0e3b0888 in nanosleep () from /lib/libpthread.so.0 3 Thread 16386 (LWP 24318) 0x0e0d1580 in poll () from /lib/libc.so.6 2 Thread 32769 (LWP 24317) 0x0e0d1580 in poll () from /lib/libc.so.6 * 1 Thread 16384 (LWP 24311) 0x0ddae44c in js_ExecuteRegExp () from /usr/lib/libmozjs.so The submitter couldn't reproduce with mozilla-browser or epiphany-browser. I wonder how it is possible that Galeon segfaults so deep in a libmozjs lib, belonging to mozilla-browser, and not mozilla-browser. May be you have an idea? I fear to ask the submitter for a recompilation of the mozilla package with debugging symbols, and I don't have a PPC with Debian right now, do you have access to a Debian PPC box? Thanks! [Category: general, please change to "Mozilla interaction" if necessary]
As noted in the original Debian bug report: The strange thing is, I only get the crash if Galeon was started from GNOME's applications menu or a launcher on the GNOME panel. If Galeon gets started from a terminal everything works fine.
Hmm, to be honest I've no idea with this, is possible, a debug backtrace is needed, without it, I'm not entirely sure what we can do about this :-(
Juergen, could you please run the following to get a debug version of galeon: apt-get install build-essential devscripts apt-get install build-dep galeon mkdir tmp-galeon && cd tmp-tmp-galeon apt-get source galeon cd galeon-1.3.19 DEB_BUILD_OPTIONS="nostrip noopt" debuild You should then get a "./debian/tmp/usr/bin/galeon" which has debug symbols, could you then provide a backtrace with debugging symbols ("thread apply all bt full"). Thanks!
Created attachment 36202 [details] GDB backtrace The backtrace doesn't look that interesting. Anyhow, using a debug build of mozilla shows an assertion failure (_q >= _p, at jsregexp.c:2864) in JS_ARENA_ALLOCATE_CAST. Closer inspection shows that _p + _nb overflows (0xffffe184 + 8000 == 0xc4). Somehow that only happens when Galeon is started from the GNOME panel, otherwise the values are only close to overflowing (0xfffffe44).
The crash only happens with ppc64 kernels. With ppc32 kernels it just goes from 7xxxxxxx to 8xxxxxxx (when using the default CONFIG_TASK_SIZE of 0x80000000).
I tried talking through this on #debian-devel, and it seems: - it could be the stack, thoughts: . vorlon already saw deep stack traces in galeon (70 / 80 calls) . might be limited somehow . strange that the BT says "corrupt stack?" - it could be something else, it isn't explicitely segfaulting in the stack, and we should find out what exactly segfaults The two actions suggested are: - try with higher ulimit, what does "ulimit" report? - try with a ppc64 kernel with CONFIG_STACK_SIZE 0x80000000 Juergen, do you think you could try this? Thanks!
Created attachment 36241 [details] [review] JS Arena Fix > The two actions suggested are: > - try with higher ulimit, what does "ulimit" report? That won't help, the stack grows in the other direction. > - try with a ppc64 kernel with CONFIG_STACK_SIZE 0x80000000 No, the TASK_SIZE (not STACK...) for 32-bit processes on ppc64 kernels is hardcoded to 4G minus one page (compared to 2G on ppc32 kernels) and all apps should work fine with that. (BTW, this problem might be reproducible with 32-bit mozilla builds on x86_64 too.) The real problem is broken pointer arithmetic in the jsarena code: It should use "lowerbound > upperbound - size" instead of "lowerbound + size > upper_bound". I've attached a patch which fixes the problem for me. The relevant parts are the JS_ARENA_ALLOCATE_CAST and JS_ArenaAllocate changes. I've also modified JS_ARENA_GROW_CAST because it looked wrong too but that part wasn't needed to get it working. There might be more issues like that in the JS arena code, the Mozilla guys probably should make a review. So you can close this bug, it's a mozilla problem. You might want to open a bug at bugzilla.mozilla.org. It would be nice if the patch got added to Debian's mozilla before upstream gets around to fix it.
Ok, thanks for your patch and time!
There was a close-enough looking bug in the Mozilla BTS at: https://bugzilla.mozilla.org/show_bug.cgi?id=270878 I've added your patch (with your name) in the report and linked to this bug and the Debian bug. (I'm closing this bug.)
Hm, that's some other bug. Stack direction is OK in my case. Sorry if I caused some confusion with "the stack grows in the other direction." What I meant was: Raising the maximum stack size limit won't help because it enlarges the stack in the wrong direction (towards lower addresses). The stack still would start at the same address and there still wouldn't be more memory for the pool (which would just hide the problem anyway). The only effect is that it would be possible to get more stack frames on the stack. But it won't have any effect on the overflow I see, the pool still would start on the same address and the overflow still would happen at the same point. It's really just a case of bad pointer arithmetic.
Ah sorry, I understood the underlying problem was pointer arithmetic, but I thought that was related to the stack being too small in some way. I'm sorry to ask to subscribe to another bugzilla again, but could you please subscribe to the upstream Mozilla bug and explain this? It would lessen the chances of me getting in the way... :-/