segv in _Jv_MarkObj and line number wierdness

Wed Mar 20 12:07:00 GMT 2002

Two questions:
1. Is it normal for gdb to report the line number from a source file
 and the function name from a header when printing out the
 source/line info for an inlined function? It's kinda
 confusing. (See below for example: Class.h contains a function
 inlined into boehm.cc, but line 189 refers to boehm.cc, *not*
 to Class.h).
2. Any idea what's going wrong here, or where to start looking? This
 is on mingw, it only happens when windows has been running for a
 long time (ie never happens right after a reboot). As such, it
 could very well just be plain old windows instability. I've only
 seen this on Win98, never on NT/2k/XP, although I do most of my
 testing on 98, so it's more likely to show bugs.
 I've also noticed that this problem only happens very rarely, but
 once it happens, it will happen every time you run the same program
 until you reboot. I guess this makes it even more likely that some
 internal Windows structure has become corrupted, and that it's an
 OS problem.
 I'm using exactly what's in CVS, no patches (never thought I'd be
 able to say that...)
 - a
Program received signal SIGSEGV, Segmentation fault.
0x005b1b31 in _Jv_MarkObj (addr=0x2645b60, msp=0x1fc0040, msl=0x1fc8000)
 at ../../../gcc/libjava/java/lang/Class.h:189
189 ../../../gcc/libjava/java/lang/Class.h: No such file or directory.
 in ../../../gcc/libjava/java/lang/Class.h
Current language: auto; currently c++
(gdb) bt
#0 0x005b1b31 in _Jv_MarkObj (addr=0x2645b60, msp=0x1fc0040, msl=0x1fc8000)
 at ../../../gcc/libjava/java/lang/Class.h:189
#1 0x0061f6d2 in GC_mark_from (mark_stack_top=0x1fc0040, 
 mark_stack=0x1fc0000, mark_stack_limit=0x1fc8000)
 at ../../../gcc/boehm-gc/mark.c:594
#2 0x0061ee94 in GC_mark_some (cold_gc_frame=0x157f6b8 "HvW001円x:a")
 at ../../../gcc/boehm-gc/mark.c:289
#3 0x0061c3fd in GC_stopped_mark (stop_func=0x61baf8 <GC_never_stop_func>)
 at ../../../gcc/boehm-gc/alloc.c:489
#4 0x0061c044 in GC_try_to_collect_inner (
 stop_func=0x61baf8 <GC_never_stop_func>)
 at ../../../gcc/boehm-gc/alloc.c:350
#5 0x0061cf67 in GC_collect_or_expand (needed_blocks=1, ignore_off_page=0)
 at ../../../gcc/boehm-gc/alloc.c:974
#6 0x0061cffa in GC_allocobj (sz=6, kind=1)
 at ../../../gcc/boehm-gc/alloc.c:1019
#7 0x00620631 in GC_generic_malloc_inner (lb=24, k=1)
 at ../../../gcc/boehm-gc/malloc.c:134
#8 0x0061e294 in GC_register_finalizer_inner (obj=0x2645b60, 
 fn=0x5b2198 <call_finalizer(void*, void*)>, cd=0x53bdd8, ofn=0x0, ocd=0x0, 
 mp=0x61e168 <GC_null_finalize_mark_proc>)
 at ../../../gcc/boehm-gc/finalize.c:429
#9 0x0061e48d in GC_register_finalizer_no_order (obj=0x2645b60,