Calling java code from C/C++ code.

Fri Mar 2 18:57:00 GMT 2001

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 ]