Re: Calling java code from C/C++ code.

[Timothy Wall <twall at oculustech dot com>]

Here's the stack trace from the fault.  I'll try the no-allocation patch and
see what happens.

T.

#0  0x404a9e32 in GC_mark_from_mark_stack () from /usr/lib/libgcjgc.so.1
#1  0x404a991d in GC_mark_some () from /usr/lib/libgcjgc.so.1
#2  0x404a4601 in GC_stopped_mark () from /usr/lib/libgcjgc.so.1
#3  0x404a440f in GC_try_to_collect_inner () from /usr/lib/libgcjgc.so.1
#4  0x404ab9fc in GC_init_inner () from /usr/lib/libgcjgc.so.1
#5  0x404a8821 in GC_generic_malloc_inner () from /usr/lib/libgcjgc.so.1
#6  0x404a899f in GC_generic_malloc () from /usr/lib/libgcjgc.so.1
#7  0x403a9903 in _Jv_AllocBytes (size=10) at ../../../libjava/boehm.cc:320
#8  0x402c4986 in _Jv_makeUtf8Const (s=0x403ec139 "()V", len=3)
    at ../../../libjava/prims.cc:247
#9  0x40394135 in __static_initialization_and_destruction_0 (__initialize_p=1,

    __priority=65535) at ../../../libjava/java/lang/natClass.cc:70
#10 0x403941ce in global constructors keyed to java::lang::Class::forName ()
    at ../../../libjava/java/lang/natClass.cc:630
#11 0x403afed5 in __do_global_ctors_aux () from /usr/lib/libgcj.so.1
#12 0x402bd0ee in _init () from /usr/lib/libgcj.so.1
#13 0x4000d549 in _dl_init (main_map=0x8050b18, argc=1, argv=0xbffffa44,
    env=0xbffffa4c) at dl-init.c:112
#14 0x401ba38a in dl_open_worker (a=0xbffff830) at dl-open.c:325
#15 0x4000d2e5 in _dl_catch_error (objname=0xbffff828, errstring=0xbffff82c,
    operate=0x401ba0bc <dl_open_worker>, args=0xbffff830) at dl-error.c:149
#16 0x401ba606 in _dl_open (file=0x8048e34 "./test.so", mode=-2147483647,
    caller=0x8048a65) at dl-open.c:380
#17 0x400213bf in dlopen_doit (a=0xbffff990) at dlopen.c:39
#18 0x4000d2e5 in _dl_catch_error (objname=0x40022f24, errstring=0x40022f28,
    operate=0x40021394 <dlopen_doit>, args=0xbffff990) at dl-error.c:149
#19 0x40021712 in _dlerror_run (operate=0x40021394 <dlopen_doit>,
    args=0xbffff990) at dlerror.c:130
#20 0x4002137f in __dlopen_check (file=0x8048e34 "./test.so", mode=1)
    at dlopen.c:53
#21 0x8048a65 in main (argc=1, argv=0xbffffa44) at loader.cc:10
#22 0x400d1b5c in __libc_start_main (main=0x8048a50 <main>, argc=1,
    ubp_av=0xbffffa44, init=0x804881c <_init>, fini=0x8048e0c <_fini>,
    rtld_fini=0x4000d634 <_dl_fini>, stack_end=0xbffffa3c)
    at ../sysdeps/generic/libc-start.c:129


"Boehm, Hans" wrote:

> If we want to understand this a bit better, it would be very useful to know
> exactly where in mark.c it is faulting (I have a good guess, but ...), and
> what address it was trying to access at the time.  The output of a call to
> GC_dump() at around that time would also be useful.
>
> Hans
>
> > -----Original Message-----
> > From: Bryce McKinlay [mailto:bryce@albatross.co.nz]
> > Sent: Tuesday, February 27, 2001 2:02 PM
> > To: tromey@redhat.com
> > Cc: twall@oculustech.com; java@gcc.gnu.org
> > Subject: Re: Calling java code from C/C++ code.
> >
> >
> > Tom Tromey wrote:
> >
> > > >>>>> "Bryce" == Bryce McKinlay <bryce@albatross.co.nz> writes:
> > >
> > > Bryce> So, I wrote a patch to remove all the static
> > initializers from
> > > Bryce> libgcj. It still didn't allow me to profile (There
> > seems to be
> > > Bryce> another problem. I can profile the GC, and arbitrary Java
> > > Bryce> .so's, but not libgcj itself. Weird.)
> > >
> > > I thought gcj also generated static initializers that call
> > > _Jv_RegisterClass.  Maybe this could account for your problem?
> >
> > It does, but with the patch, _Jv_RegisterClass doesn't do
> > anything that
> > might result in an allocation.
> >
> > regards
> >
> >   [ bryce ]
> >
> >