RE: static constructors and GC initialization

["Boehm, Hans" <hans_boehm at hp dot com>]

In theory the collector should be self-initializing if you call
GC_malloc_atomic first, and it shouldn't crash.  It is not safe to use
gcj-specific allocation at this stage, though we could probably set things
up so that collector initialization invokes the gcj-specific initialization
routines as well.

Here the collector is trying to initialize itself.  It triggers a GC
immediately, before allocating anything in the heap, so that it can locate
potential bogus pointers later on.

I suspect the issue here is that list of dynamic libraries was somehow
invalid when it tried to walk it, and it thus ends up trying to mark from a
region of memory that isn't mapped yet.  Alternatively, it's somehow
confused about some other part of the root set.

It would be nice to know more about what's happening, e.g. the fault address
(i.e. the value of "limit" in mark.c), and the output of GC_dump() when it
fails, if that's possible.

Hans

> -----Original Message-----
> From: Bryce McKinlay [mailto:bryce@albatross.co.nz]
> Sent: Sunday, January 28, 2001 10:41 PM
> To: java@gcc.gnu.org
> Subject: static constructors and GC initialization
> 
> 
> I'm trying to figure out why sprof fails to dlopen libgcj.so.
> 
> We're crashing in the GC because _Jv_AllocBytes (called from the
> static constructors in natClass.cc) seems to result in a collection
> being attempted while the dlopen is in progress.
> 
> Is it supposed to be safe to call _Jv_AllocBytes before _Jv_InitGC?
> (This can happen because the natClass initializers might be called
> before _Jv_RegisterClasses.)
> 
> Should we try and get rid of all the static constructors that allocate
> and move them to an initialization routine that is guaranteed to be
> run after the GC initialization?
> 
> regards
> 
>   [ bryce ]
> 
> 
> #0  GC_mark_from_mark_stack () at ../../../boehm-gc/mark.c:584
> #1  0x40471a72 in GC_mark_some (cold_gc_frame=0xbffff350 "")
>     at ../../../boehm-gc/mark.c:278
> #2  0x4046bf82 in GC_stopped_mark (stop_func=0x4046ba40
> <GC_never_stop_func>)
>     at ../../../boehm-gc/alloc.c:445
> #3  0x4046bda5 in GC_try_to_collect_inner (
>     stop_func=0x4046ba40 <GC_never_stop_func>) at
> ../../../boehm-gc/alloc.c:324
> #4  0x40473d90 in GC_init_inner () at ../../../boehm-gc/misc.c:561
> #5  0x40470a9d in GC_generic_malloc_inner (lb=10, k=0)
>     at ../../../boehm-gc/malloc.c:63
> #6  0x40470baf in GC_generic_malloc (lb=10, k=0)
>     at ../../../boehm-gc/malloc.c:133
> #7  0x40470c74 in GC_malloc_atomic (lb=10) at
> ../../../boehm-gc/malloc.c:172
> #8  0x4033309d in _Z14_Jv_AllocBytesi (size=10)
>     at ../../../libjava/boehm.cc:375
> #9  0x4024ce17 in _Z17_Jv_makeUtf8ConstPci (s=0x403409b8 "()V", len=3)
> 
>     at ../../../libjava/prims.cc:252
> #10 0x4026745a in __static_initialization_and_destruction_0
> (__initialize_p=1,
>     __priority=65535) at ../../../libjava/java/lang/natClass.cc:70
> #11 0x40267482 in global constructors keyed to
> _ZN4java4lang5Class7forNameEPNS0_6StringEPNS0_11ClassLoaderE () at
> ../../../libjava/java/lang/natClass.cc:311
> #12 0x40339aa7 in __do_global_ctors_aux ()
>     at ../../../../libstdc++-v3/libsupc++/vec.cc:56
> #13 0x402450be in _init () from /usr/local/gcc/lib/libgcj.so.1
> #14 0x4000e167 in _dl_init (main_map=0x804e990, argc=2,
> argv=0xbffff9ac,
>     env=0xbffff9b8) at dl-init.c:112
> #15 0x401310a3 in dl_open_worker (a=0xbffff708) at dl-open.c:325
> 
>