428497 - crash in js_GC

Status: RESOLVED DUPLICATE of bug 425576

(Core :: JavaScript Engine, defect)

Description

[Kai Engert [:KaiE:]]

I use SeaMonkey 1.1.9 (1.8 branch, equivalent to Firefox 2.0.0.x) for private stuff (Linux RPM on Fedora), and every couple of days it eventually crashes.

Since a couple of days I've been running a build in the debugger, and here's the stack:

#0  0x00110402 in __kernel_vsyscall ()
#1  0x00957891 in raise () from /lib/libpthread.so.0
#2  0x0278fc36 in nsProfileLock::FatalSignalHandler (signo=11) at nsProfileLock.cpp:206
#3  <signal handler called>
#4  0x00227a44 in js_GC (cx=0xa6b364c0, gckind=GC_NORMAL) at jsgc.c:2947
#5  0x001fd532 in JS_GC (cx=0xa6b364c0) at jsapi.c:1873
#6  0x018b1170 in nsJSContext::Notify (this=0xb282e9a8, timer=0xb26f3130) at nsJSEnvironment.cpp:2227
#7  0x0018c6ad in nsTimerImpl::Fire (this=0xb26f3130) at nsTimerImpl.cpp:397
#8  0x0018d398 in handleTimerEvent (event=0x9df0830) at nsTimerImpl.cpp:459
#9  0x00187da7 in PL_HandleEvent (self=0x9df0830) at plevent.c:688
#10 0x001880bb in PL_ProcessPendingEvents (self=0x9a1ee28) at plevent.c:623
#11 0x0018a2ec in nsEventQueueImpl::ProcessPendingEvents (this=0x9a1ede0) at nsEventQueue.cpp:448
#12 0x05022ed5 in event_processor_callback (source=0x9bd4958, condition=G_IO_IN, data=0xab6d7230) at nsAppShell.cpp:67
#13 0x0051cd9d in g_io_unix_dispatch (source=0x9bd49a0, callback=0x5022ec0 <event_processor_callback>, user_data=0x9a1ede0)
    at giounix.c:162
#14 0x004ed1ac in IA__g_main_context_dispatch (context=0x994bd38) at gmain.c:2061
#15 0x004f05ef in g_main_context_iterate (context=0x994bd38, block=1, dispatch=1, self=0x992a440) at gmain.c:2694
#16 0x004f0999 in IA__g_main_loop_run (loop=0x9bd3680) at gmain.c:2898
#17 0x03d10422 in IA__gtk_main () at gtkmain.c:1163
#18 0x05023302 in nsAppShell::Run (this=0xb7002e70) at nsAppShell.cpp:139
#19 0x02edcd04 in nsAppStartup::Run (this=0xb7002e28) at nsAppStartup.cpp:207
#20 0x0804d581 in main1 (argc=3, argv=0xbfd84fb4, nativeApp=<value optimized out>) at nsAppRunner.cpp:1276
#21 0x0804e113 in main (argc=162012244, argv=0xa5ae0728) at nsAppRunner.cpp:1803
#22 0x007d3390 in __libc_start_main (main=0x804dc30 <main>, argc=4, ubp_av=0xbfd84fb4, init=0x8050b10 <__libc_csu_init>,
    fini=0x8050b00 <__libc_csu_fini>, rtld_fini=0x7ac940 <_dl_fini>, stack_end=0xbfd84fac) at libc-start.c:220
#23 0x08049ff1 in _start ()

  191 Thread -1602151536 (LWP 28219) (Exiting)  0x0094e811 in __nptl_death_event () from /lib/libpthread.so.0
  189 Thread -1591661680 (LWP 28209)  0x00110402 in __kernel_vsyscall ()
  180 Thread -1364251760 (LWP 27905)  0x00110402 in __kernel_vsyscall ()
  131 Thread -1394611312 (LWP 12458)  0x00110402 in __kernel_vsyscall ()
  59 Thread -1353761904 (LWP 11900)  0x00110402 in __kernel_vsyscall ()
  54 Thread -1384121456 (LWP 11816)  0x00110402 in __kernel_vsyscall ()
  7 Thread -1262490736 (LWP 23318)  0x00110402 in __kernel_vsyscall ()
  6 Thread -1252000880 (LWP 23317)  0x00110402 in __kernel_vsyscall ()
  3 Thread -1226835056 (LWP 23224)  0x00110402 in __kernel_vsyscall ()
  2 Thread -1212351600 (LWP 23223)  0x00110402 in __kernel_vsyscall ()
* 1 Thread -1208817968 (LWP 23220)  0x00110402 in __kernel_vsyscall ()


2532 #define GC_MARK_JSVALS(cx, len, vec, name)
2533     JS_BEGIN_MACRO
2534         jsval _v, *_vp, *_end;
2535
2536         for (_vp = vec, _end = _vp + len; _vp < _end; _vp++) {
2537             _v = *_vp;
2538             if (JSVAL_IS_GCTHING(_v))
2539                 GC_MARK(cx, JSVAL_TO_GCTHING(_v), name);
2540         }
2541     JS_END_MACRO


#4  0x00227a44 in js_GC (cx=0xa6b364c0, gckind=GC_NORMAL) at jsgc.c:2947
2947                    GC_MARK_JSVALS(cx, tvr->count, tvr->u.array, "tvr->u.array");

(gdb) print tvr
$9 = (JSTempValueRooter *) 0xa6b364c0
(gdb) print *tvr
$10 = {down = 0x9a81c54, count = -1418890704, u = {value = 0, object = 0x0, string = 0x0, function = 0x0, xml = 0x0, qname = 0x0,
    marker = 0, sprop = 0x0, weakRoots = 0x0, script = 0x0, array = 0x0}}


The macro doesn't assure that parameter vec is null before it dereferences it.

Comment 1

[Kai Engert [:KaiE:]]

I don't need this profile for the next couple of hours and will keep the debugger open.

So if you're quick and want to know the state of additional variables, let me know.

Comment 2

[Matthias Versen [:Matti]]

I'm sure that I saw this stack trace in the last 2 weeks but i can't find it now :-(