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

[Timothy Wall <twall at oculustech dot com>]

Sure enough, natClass.cc wasn't patched.  After rebuild, the shared lib is successfully
loaded, but on calling the entry point, it looks like allocation is still causing a crash:

#0  0x405d8c13 in GC_mark_from_mark_stack ()
    at ../../../gcc/boehm-gc/mark.c:584
#1  0x405d85d7 in GC_mark_some (
    cold_gc_frame=0xbffff8c0 " *]@<-^@èøÿ¿\001)]@ $]@<-^@èøÿ¿ê(]@P(]@<-^@\030ùÿ\
¿\200´]@ $]@<-^@\030ùÿ¿r´]@Hùÿ¿àÏ") at ../../../gcc/boehm-gc/mark.c:315
#2  0x405d2b0c in GC_stopped_mark (stop_func=0x405d24a0 <GC_never_stop_func>)
    at ../../../gcc/boehm-gc/alloc.c:445
#3  0x405d2901 in GC_try_to_collect_inner (
    stop_func=0x405d24a0 <GC_never_stop_func>)
    at ../../../gcc/boehm-gc/alloc.c:324
#4  0x405db480 in GC_init_inner () at ../../../gcc/boehm-gc/misc.c:561
#5  0x405d741f in GC_generic_malloc_inner (lb=10, k=0)
    at ../../../gcc/boehm-gc/malloc.c:61
#6  0x405d75d5 in GC_generic_malloc (lb=10, k=0)
    at ../../../gcc/boehm-gc/malloc.c:133
#7  0x405d7674 in GC_malloc_atomic (lb=10)
    at ../../../gcc/boehm-gc/malloc.c:172
#8  0x4045c92d in _Z14_Jv_AllocBytesi (size=10)
    at ../../../gcc/libjava/boehm.cc:375
#9  0x40326077 in _Z17_Jv_makeUtf8ConstPci (s=0x40463424 "()V", len=3)
    at ../../../gcc/libjava/prims.cc:252
#10 0x40326ab0 in _Z15initVMConstantsv () at ../../../gcc/libjava/prims.cc:689
#11 0x40326b44 in _Z9main_initv () at ../../../gcc/libjava/prims.cc:705
#12 0x403270fa in JvRunMain (klass=0x4001ec40, argc=1, argv=0xbffffb40)
    at ../../../gcc/libjava/prims.cc:914
#13 0x4001b54c in callable () from /nfs/users/twall/jrel/./test.so
#14 0x8048b05 in main (argc=1, argv=0xbffffbe4) at loader.cc:18
#15 0x400d1b5c in __libc_start_main (main=0x8048a50 <main>, argc=1,
    ubp_av=0xbffffbe4, init=0x804881c <_init>, fini=0x8048dac <_fini>,
    rtld_fini=0x4000d634 <_dl_fini>, stack_end=0xbffffbdc)
    at ../sysdeps/generic/libc-start.c:129
(gdb) p GC_dump()
***Static roots:
>From 0x0 to 0x804a1d8
>From 0x40022d8c to 0x40022f34  (temporary)
>From 0x4007c7e0 to 0x4008a1e8  (temporary)
>From 0x400a9820 to 0x400a99b8  (temporary)
>From 0x400b4054 to 0x400b4630  (temporary)
>From 0x401ce6e0 to 0x401d6cc8  (temporary)
>From 0x40015ba0 to 0x4001627c  (temporary)
>From 0x4001ebc0 to 0x4001f3ac  (temporary)
>From 0x404c2180 to 0x405ca8cc  (temporary)
>From 0x405e2940 to 0x405eb340  (temporary)
>From 0x40604200 to 0x4060af5c  (temporary)
>From 0x4061b6a0 to 0x4061cb48  (temporary)
Total size: 135769340

***Heap sections:
Total heap size: 65536
Section 0 from 0x8063000 to 0x8073000 1/16 blacklisted

***Free blocks:
Free list 16:
        0x8063000 size 65536 not black listed
Total of 65536 bytes on free list

***Blocks in use:
(kind(0=ptrfree,1=normal,2=unc.,3=stubborn):size_in_bytes, #_marks_set)

blocks = 0, bytes = 0
$5 = void


Bryce McKinlay wrote:

> Timothy Wall wrote:
>
> > Here's the result, with the patch, and GC_dump output.
>
> Are you sure you applied the patch correctly? From your stack trace, it looks like static
> initializers are still being run in natClass.cc:
>
> > #9  0x403260b7 in _Z17_Jv_makeUtf8ConstPci (s=0x40467398 "()V", len=3)
> >     at ../../../gcc/libjava/prims.cc:252
> > #10 0x4034048a in __static_initialization_and_destruction_0 (__initialize_p=1,
> >     __priority=65535) at ../../../gcc/libjava/java/lang/natClass.cc:70
> > #11 0x403404b2 in global constructors keyed to
> > _ZN4java4lang5Class7forNameEPNS0_6StringEPNS0_11ClassLoaderE ()
> >     at ../../../gcc/libjava/java/lang/natClass.cc:316
> > #12 0x404605c7 in __do_global_ctors_aux ()
> >     at ../../../../gcc/libstdc++-v3/libsupc++/vec.cc:59
>
> regards
>
>   [ bryce ]