gcj 4.6 on OpenBSD/x86

gcj 4.6 on OpenBSD/x86

[Kurt Miller]

Hi,

Previously I ported gcj in gcc 4.2.4 to OpenBSD. I currently use it to build classpath-0.98 and bootstrap Oracle's 1.6 JVM using classpath and jamvm. I'm now working on gcj from gcc 4.6.3 on x86 and have run into an issue that I could use some help with.

gjar is segfaulting while throwing a ClassCastException from frame 3. Here is some debugging output showing the state and some variables leading up to the segfault. I'm not sure where to go from here. I can't seem to find the root cause of this issue other than something is wrong with 'obj' in frame 3 and obj->getClass()->getName() fails. Any ideas on how to proceed with the debugging on this issue?

Core was generated by `egjar'.
Program terminated with signal 11, Segmentation fault.
#0  0x0c392970 in _Jv_NewStringUTF (bytes=0xfc408b05 <Address 0xfc408b05 out of bounds>)
    at /usr/obj/i386/ports/gcc-4.6.3/gcc-4.6.3/libjava/java/lang/natString.cc:245
245       int size = strlen (bytes);


(gdb) bt full
#0  0x0c392970 in _Jv_NewStringUTF (bytes=0xfc408b05 <Address 0xfc408b05 out of bounds>)
    at /usr/obj/i386/ports/gcc-4.6.3/gcc-4.6.3/libjava/java/lang/natString.cc:245
        length = -2043263696
        chrs = 0x83244620
        limit = 0xc38e18c <java::lang::Class::isArray()+32> "<[\017\224\300\203\304\024[]\303\220U\211\345S\203\354\024\350\222\r\372\377\201\303\070\227) \213E\b\211\004$\350\347z\370\377\204\300t\b\213E\b\213@$\353\005\270"
        size = 310
        p = 0x3 <Address 0x3 out of bounds>
        jstr = 0xcfbc01a8
#1  0x0c348e2a in _Jv_Utf8Const::toString (this=0xfc408b01) at /usr/obj/i386/ports/gcc-4.6.3/gcc-4.6.3/libjava/gcj/javaprims.h:970
No locals.
#2  0x0c38a734 in java::lang::Class::getName (this=0xc3b75fb <gnu.gcj.runtime.BootClassLoader.bootLoadClass(java.lang.String)java.lang.Class+123>)
    at /usr/obj/i386/ports/gcc-4.6.3/gcc-4.6.3/libjava/java/lang/natClass.cc:442
No locals.
#3  0x0c38daba in _Jv_CheckCast (c=0x23896b60 <gnu::classpath::tools::getopt::Option::class$>, obj=0x8321e480)
    at /usr/obj/i386/ports/gcc-4.6.3/gcc-4.6.3/libjava/java/lang/natClass.cc:1897
No locals.
#4  0x039a3de4 in gnu.classpath.tools.getopt.Parser.handleShortOptions(java.lang.String)void (this=@82f21968, option=@8323b858)
    at /usr/obj/i386/ports/gcc-4.6.3/gcc-4.6.3/libjava/classpath/tools/gnu/classpath/tools/getopt/Parser.java:394
        i = 9
        found = 0x0
        charIndex = 1
#5  0x039a4a54 in gnu.classpath.tools.getopt.Parser.parse(java.lang.String[], gnu.classpath.tools.getopt.FileArgumentCallback)void (this=@82f21968,
    inArgs=@82db8f90, files=@832b2c80) at /usr/obj/i386/ports/gcc-4.6.3/gcc-4.6.3/libjava/classpath/tools/gnu/classpath/tools/getopt/Parser.java:455
No locals.
#6  0x039b6e20 in gnu.classpath.tools.common.ClasspathToolParser.parse(java.lang.String[], gnu.classpath.tools.getopt.FileArgumentCallback, boolean)void (
    this=@82f21968, inArgs=@82db8f90, files=@832815d0, handleFileLists=true)
    at /usr/obj/i386/ports/gcc-4.6.3/gcc-4.6.3/libjava/classpath/tools/gnu/classpath/tools/common/ClasspathToolParser.java:105
        cb = 0x0
#7  0x039b32c8 in gnu.classpath.tools.jar.Main.run(java.lang.String[])void (this=@82e3fac8, args=@82db8f90)
    at /usr/obj/i386/ports/gcc-4.6.3/gcc-4.6.3/libjava/classpath/tools/gnu/classpath/tools/jar/Main.java:272
        p = 0x82f21968
#8  0x039b3408 in gnu.classpath.tools.jar.Main.main(java.lang.String[])void (args=@82db8f90)
    at /usr/obj/i386/ports/gcc-4.6.3/gcc-4.6.3/libjava/classpath/tools/gnu/classpath/tools/jar/Main.java:284
        jarprogram = 0x0
#9  0x0c380881 in gnu::java::lang::MainThread::call_main (this=0x82dc1f00)
    at /usr/obj/i386/ports/gcc-4.6.3/gcc-4.6.3/libjava/gnu/java/lang/natMainThread.cc:54
        main_signature = 0x82d43de0
        main_name = 0x82d3dbb0
        meth = 0x2389c224 <_MT_gnu_classpath_tools_jar_Main+100>
        msg = 0x0
        status = 205084852
        real_main = 0x39b33a0 <gnu.classpath.tools.jar.Main.main(java.lang.String[])void>
#10 0x0c464f9a in gnu.java.lang.MainThread.run()void (this=@82dc1f00) at /usr/obj/i386/ports/gcc-4.6.3/gcc-4.6.3/libjava/gnu/java/lang/MainThread.java:106
No locals.
#11 0x0c395be0 in _Jv_ThreadRun (thread=0x82dc1f00) at /usr/obj/i386/ports/gcc-4.6.3/gcc-4.6.3/libjava/java/lang/natThread.cc:335
No locals.
#12 0x0c332ec7 in _Jv_RunMain (vm_args=0x0, klass=0x3c003180 <gnu::classpath::tools::jar::Main::class$>, name=0x0, argc=9, argv=0xcfbc082c, is_jar=false)
    at /usr/obj/i386/ports/gcc-4.6.3/gcc-4.6.3/libjava/prims.cc:1790
        runtime = 0x82db49f0
#13 0x0c332fea in _Jv_RunMain (klass=0x3c003180 <gnu::classpath::tools::jar::Main::class$>, name=0x0, argc=9, argv=0xcfbc082c, is_jar=false)
    at /usr/obj/i386/ports/gcc-4.6.3/gcc-4.6.3/libjava/prims.cc:1815
No locals.
#14 0x0c33302b in JvRunMain (klass=0x3c003180 <gnu::classpath::tools::jar::Main::class$>, argc=9, argv=0xcfbc082c)
    at /usr/obj/i386/ports/gcc-4.6.3/gcc-4.6.3/libjava/prims.cc:1821
---Type <return> to continue, or q <return> to quit---
No locals.
#15 0x1c000861 in main (argc=9, argv=0xcfbc082c) at /tmp//ccaCFDWE.i:11
No locals.


(gdb) frame 0
#0  0x0c392970 in _Jv_NewStringUTF (bytes=0xfc408b05 <Address 0xfc408b05 out of bounds>)
    at /usr/obj/i386/ports/gcc-4.6.3/gcc-4.6.3/libjava/java/lang/natString.cc:245
245       int size = strlen (bytes);
(gdb) p bytes
$35 = 0xfc408b05 <Address 0xfc408b05 out of bounds>
(gdb) up
#1  0x0c348e2a in _Jv_Utf8Const::toString (this=0xfc408b01) at /usr/obj/i386/ports/gcc-4.6.3/gcc-4.6.3/libjava/gcj/javaprims.h:970
970       jstring toString() { return _Jv_NewStringUTF(data); }
(gdb) p data
Cannot access memory at address 0xfc408b05
(gdb) up
#2  0x0c38a734 in java::lang::Class::getName (this=0xc3b75fb <gnu.gcj.runtime.BootClassLoader.bootLoadClass(java.lang.String)java.lang.Class+123>)
    at /usr/obj/i386/ports/gcc-4.6.3/gcc-4.6.3/libjava/java/lang/natClass.cc:442
442       return name->toString();
(gdb) p name
$36 = (_Jv_Utf8Const *) 0xfc408b01
(gdb) p *name
Cannot access memory at address 0xfc408b01
(gdb) up
#3  0x0c38daba in _Jv_CheckCast (c=0x23896b60 <gnu::classpath::tools::getopt::Option::class$>, obj=0x8321e480)
    at /usr/obj/i386/ports/gcc-4.6.3/gcc-4.6.3/libjava/java/lang/natClass.cc:1897
1897           (JvNewStringUTF(" cannot be cast to "))->append
(gdb) list
1892      if (__builtin_expect
1893          (obj != NULL && ! _Jv_IsAssignableFrom(JV_CLASS (obj), c), false))
1894        throw new java::lang::ClassCastException
1895          ((new java::lang::StringBuffer
1896            (obj->getClass()->getName()))->append
1897           (JvNewStringUTF(" cannot be cast to "))->append
1898           (c->getName())->toString());
1899
1900      return obj;
1901    }
(gdb) p c
$38 = (jclass) 0x23896b60 <gnu::classpath::tools::getopt::Option::class$>
(gdb) p *c
$39 = {<java::lang::Object> = {<No data fields>}, static class$ = {<java::lang::Object> = {<No data fields>},
    static class$ = <same as static member of an already seen type>, next_or_version = 0x0, name = 0x2b854788 <_Utf161>, accflags = 49,
    superclass = 0x2bf34ae0 <java::lang::Object::class$>, constants = {size = 37, tags = 0x2bf34bc0 <_CT_java_lang_Class> "",
      data = 0x2bf35500 <_CD_java_lang_Class>}, {methods = 0x2bf34d60 <_MT_java_lang_Class>, element_type = 0x2bf34d60 <_MT_java_lang_Class>},
    method_count = 82, vtable_method_count = 65, fields = 0x0, size_in_bytes = 148, field_count = 0, static_field_count = 0,
    vtable = 0x2bf34c48 <vtable for java::lang::Class+8>, otable = 0x0, otable_syms = 0x0, atable = 0x0, atable_syms = 0x0, itable = 0x0,
    itable_syms = 0x0, catch_classes = 0x2bf34be8 <_catch_classes_java_lang_Class>, interfaces = 0x2bf353c8 <_IF_java_lang_Class>, loader = 0x0,
    interface_count = 4, state = 14 '\016', thread = 0x1, depth = 1, ancestors = 0x82d41ff0, {idt = 0x82d46fc8, ioffsets = 0x82d46fc8},
    arrayclass = 0x82d49ed8, protectionDomain = 0x0, assertion_table = 0x0, hack_signers = 0x0, chain = 0x2c086ca0 <java::lang::Cloneable::class$>,
    aux_info = 0x0, engine = 0x2c63be40 <_Jv_soleCompiledEngine>, reflection_data = 0x2b8547a0 <_reflection_data_0> "\001"},
  next_or_version = 0x238969c0 <gnu::classpath::tools::jarsigner::Main$ToolParser::class$>, name = 0x237ff9f4 <_Utf8>, accflags = 1057,
  superclass = 0x2bf34ae0 <java::lang::Object::class$>, constants = {size = 4, tags = 0x23870d4c <_CT_gnu_classpath_tools_getopt_Option> "",
    data = 0x23896ab8 <_CD_gnu_classpath_tools_getopt_Option>}, {methods = 0x238f4ce0 <_MT_gnu_classpath_tools_getopt_Option>,
    element_type = 0x238f4ce0 <_MT_gnu_classpath_tools_getopt_Option>}, method_count = 15, vtable_method_count = 13,
  fields = 0x23896a60 <_FL_gnu_classpath_tools_getopt_Option>, size_in_bytes = 28, field_count = 5, static_field_count = 0, vtable = 0x82e4e840,
  otable = 0x23936428 <_otable_gnu_classpath_tools_getopt_Option>, otable_syms = 0x23896ac8 <_otable_syms_gnu_classpath_tools_getopt_Option>,
  atable = 0x23936444 <_atable_gnu_classpath_tools_getopt_Option>, atable_syms = 0x23896b10 <_atable_syms_gnu_classpath_tools_getopt_Option>,
  itable = 0x0, itable_syms = 0x0, catch_classes = 0x23870d50 <_catch_classes_gnu_classpath_tools_getopt_Option>, interfaces = 0x0, loader = 0x82d5b000,
  interface_count = 0, state = 14 '\016', thread = 0x82dc1f01, depth = 1, ancestors = 0x82d41a40, {idt = 0x0, ioffsets = 0x0}, arrayclass = 0x0,
  protectionDomain = 0x0, assertion_table = 0x23896b34 <_type_assert_gnu_classpath_tools_getopt_Option>, hack_signers = 0x0,
  chain = 0x23897dc0 <gnu::classpath::tools::getopt::Parser$1::class$>, aux_info = 0x0, engine = 0x2c63be40 <_Jv_soleCompiledEngine>,
  reflection_data = 0x0}
(gdb) p obj
$37 = (jobject) 0x8321e480
(gdb) p *obj
$44 = <incomplete type>
(gdb) x/20w obj
0x8321e480:     0x82e4e100      0x00000000      0x0000006d      0x00000000
0x8321e490:     0x83292738      0x83244080      0x00000000      0x82e3fac8
0x8321e4a0:     0x2c07d8e8      0x00000000      0x832207e0      0x8321e4a0
0x8321e4b0:     0x00000000      0x832285f0      0x00000000      0x00000000
0x8321e4c0:     0x2c08d248      0x00000000      0x83222ab0      0x83222ab0
(gdb)
0x8321e4d0:     0x00000000      0x00000000      0x00000000      0x00000000
0x8321e4e0:     0x2c07d8e8      0x00000000      0x83220810      0x8321e4e0
0x8321e4f0:     0x00000000      0x83228620      0x00000000      0x00000000
0x8321e500:     0x2c07d8e8      0x00000000      0x832208e8      0x8321e500
0x8321e510:     0x00000000      0x83228680      0x00000000      0x00000000
(gdb)
0x8321e520:     0x2c07d8e8      0x00000000      0x83220918      0x8321e520
0x8321e530:     0x00000000      0x832286b0      0x00000000      0x00000000
0x8321e540:     0x2c07d8e8      0x00000000      0x832209c0      0x8321e540
0x8321e550:     0x00000000      0x83228710      0x00000000      0x00000000
0x8321e560:     0x2c07d8e8      0x00000000      0x832209f0      0x8321e560
(gdb)
0x8321e570:     0x00000000      0x83228740      0x00000000      0x00000000
0x8321e580:     0x2c07d8e8      0x00000000      0x83220a98      0x8321e580
0x8321e590:     0x00000000      0x832287a0      0x00000000      0x00000000
0x8321e5a0:     0x2c07d8e8      0x00000000      0x83220ac8      0x8321e5a0
0x8321e5b0:     0x00000000      0x832287d0      0x00000000      0x00000000
(gdb)
0x8321e5c0:     0x2c07d8e8      0x00000000      0x83220b70      0x8321e5c0
0x8321e5d0:     0x00000000      0x83228830      0x00000000      0x00000000
0x8321e5e0:     0x2c07d8e8      0x00000000      0x83220ba0      0x8321e5e0
0x8321e5f0:     0x00000000      0x83228860      0x00000000      0x00000000
0x8321e600:     0x2c07d8e8      0x00000000      0x83220c48      0x8321e600

Re: gcj 4.6 on OpenBSD/x86

[David Daney]

On 10/08/2012 01:07 PM, Kurt Miller wrote:
> Hi,
>
> Previously I ported gcj in gcc 4.2.4 to OpenBSD. I currently use it to build classpath-0.98 and bootstrap Oracle's 1.6 JVM using classpath and jamvm. I'm now working on gcj from gcc 4.6.3 on x86 and have run into an issue that I could use some help with.
>
> gjar is segfaulting while throwing a ClassCastException from frame 3. Here is some debugging output showing the state and some variables leading up to the segfault. I'm not sure where to go from here. I can't seem to find the root cause of this issue other than something is wrong with 'obj' in frame 3 and obj->getClass()->getName() fails. Any ideas on how to proceed with the debugging on this issue?
>
> Core was generated by `egjar'.
> Program terminated with signal 11, Segmentation fault.
> #0  0x0c392970 in _Jv_NewStringUTF (bytes=0xfc408b05 <Address 0xfc408b05 out of bounds>)
>      at /usr/obj/i386/ports/gcc-4.6.3/gcc-4.6.3/libjava/java/lang/natString.cc:245
> 245       int size = strlen (bytes);
>
>

I haven't studied it closely, but it would appear that 'bytes=0xfc408b05 
<Address 0xfc408b05 out of bounds>' indicates a real problem.  If it is 
truly a bad pointer value, you need to figure out where it came from and 
fix it.

David Daney

Re: gcj 4.6 on OpenBSD/x86

[Kurt Miller]

On Monday 08 October 2012 04:35:19 pm David Daney wrote:
> On 10/08/2012 01:07 PM, Kurt Miller wrote:
> > Hi,
> >
> > Previously I ported gcj in gcc 4.2.4 to OpenBSD. I currently use it to build classpath-0.98 and bootstrap Oracle's 1.6 JVM using classpath and jamvm. I'm now working on gcj from gcc 4.6.3 on x86 and have run into an issue that I could use some help with.
> >
> > gjar is segfaulting while throwing a ClassCastException from frame 3. Here is some debugging output showing the state and some variables leading up to the segfault. I'm not sure where to go from here. I can't seem to find the root cause of this issue other than something is wrong with 'obj' in frame 3 and obj->getClass()->getName() fails. Any ideas on how to proceed with the debugging on this issue?
> >
> > Core was generated by `egjar'.
> > Program terminated with signal 11, Segmentation fault.
> > #0  0x0c392970 in _Jv_NewStringUTF (bytes=0xfc408b05 <Address 0xfc408b05 out of bounds>)
> >      at /usr/obj/i386/ports/gcc-4.6.3/gcc-4.6.3/libjava/java/lang/natString.cc:245
> > 245       int size = strlen (bytes);
> >
> >
> 
> I haven't studied it closely, but it would appear that 'bytes=0xfc408b05 
> <Address 0xfc408b05 out of bounds>' indicates a real problem.  If it is 
> truly a bad pointer value, you need to figure out where it came from and 
> fix it.

Indeed. I've done that already and included the details in the initial email.
Frame 3 is throwing an exception where obj->getClass()->getName() is
called. 'obj' is the likely source of the problem but the debugger believes it is
an incomplete type and I can't inspect it; see the end of initial email.

Thanks,
-Kurt

Re: gcj 4.6 on OpenBSD/x86

[Andrew Haley]

On 10/08/2012 03:09 PM, Kurt Miller wrote:
> Indeed. I've done that already and included the details in the initial email.
> Frame 3 is throwing an exception where obj->getClass()->getName() is
> called. 'obj' is the likely source of the problem but the debugger believes it is
> an incomplete type and I can't inspect it; see the end of initial email.

I'd put a breakpoint earlier and step through.
I don't think there's an easier way to do it.

_Jv_Debug(obj) prints an object.

Andrew.

Re: gcj 4.6 on OpenBSD/x86

[Kurt Miller]

On 10/8/12 8:51 PM, Andrew Haley wrote:
> On 10/08/2012 03:09 PM, Kurt Miller wrote:
>> Indeed. I've done that already and included the details in the initial email.
>> Frame 3 is throwing an exception where obj->getClass()->getName() is
>> called. 'obj' is the likely source of the problem but the debugger believes it is
>> an incomplete type and I can't inspect it; see the end of initial email.
> I'd put a breakpoint earlier and step through.
> I don't think there's an easier way to do it.
>
> _Jv_Debug(obj) prints an object.
>
> Andrew.
>

Thanks. It looks like the root of the problem lies in boehm-gc. Using 
GC_DONT_GC=1 works-around the problem. Time to dig into boehm-gc ifdef 
hell again...

-Kurt

RE: gcj 4.6 on OpenBSD/x86

[Boehm, Hans]

It may be worth checking whether the garbage collector tests, particularly gctest, run correctly in your environment.  If not, that might give you an easier debugging task.

Hans

> -----Original Message-----
> From: java-owner@gcc.gnu.org [mailto:java-owner@gcc.gnu.org] On Behalf
> Of Kurt Miller
> Sent: Tuesday, October 09, 2012 6:06 AM
> To: Andrew Haley
> Cc: David Daney; java@gcc.gnu.org
> Subject: Re: gcj 4.6 on OpenBSD/x86
> 
> On 10/8/12 8:51 PM, Andrew Haley wrote:
> > On 10/08/2012 03:09 PM, Kurt Miller wrote:
> >> Indeed. I've done that already and included the details in the
> initial email.
> >> Frame 3 is throwing an exception where obj->getClass()->getName() is
> >> called. 'obj' is the likely source of the problem but the debugger
> believes it is
> >> an incomplete type and I can't inspect it; see the end of initial
> email.
> > I'd put a breakpoint earlier and step through.
> > I don't think there's an easier way to do it.
> >
> > _Jv_Debug(obj) prints an object.
> >
> > Andrew.
> >
> 
> Thanks. It looks like the root of the problem lies in boehm-gc. Using
> GC_DONT_GC=1 works-around the problem. Time to dig into boehm-gc ifdef
> hell again...
> 
> -Kurt

Re: gcj 4.6 on OpenBSD/x86

[Kurt Miller]

On Tuesday 09 October 2012 01:21:40 pm Boehm, Hans wrote:
> It may be worth checking whether the garbage collector tests, particularly gctest, run correctly in your environment.  If not, that might give you an easier debugging task.
> 
> Hans

Thank you. Will do. I'm quite sure the problem is in the OpenBSD specific ifdefs. It was quite tricky to get it right the first time and OpenBSD has some OS specific quirks that need to be handled right.

-Kurt

Re: gcj 4.6 on OpenBSD/x86

[Kurt Miller]

On 10/9/12 1:21 PM, Boehm, Hans wrote:
> It may be worth checking whether the garbage collector tests, particularly gctest, run correctly in your environment.  If not, that might give you an easier debugging task.
>
> Hans
Hi Hans,

Initially gctest was failing which was caused by OpenBSD not having 
pthread_getattr_np(). We have pthread_stackseg_np() so I put an OpenBSD 
specific implementation into pthread_support.c 
GC_get_thread_stack_base(). This corrected the gctest failure and 'gmake 
check' passes all tests now. However gjar still segfaults  unless 
GC_DONT_GC is used.

Based on the output below is there a place you can suggest I look for 
the problem? or can you suggest a way for me to isolate which part of GC 
is not setup correctly on OpenBSD?

Thanks,
-Kurt

$ GC_PRINT_STATS=1 ./.libs/gjar cf test.jar headers.stamp
Increasing heap size by 65536 after 0 allocated bytes
Initiating full world-stop collection 1 after 0 allocd bytes
--> Marking for collection 1 after 0 allocd bytes + 0 wasted bytes
Collection 0 finished ---> heapsize = 65536 bytes
World-stopped marking took 30 msecs
Complete collection took 30 msecs
Grew fo table to 1 entries
Grew fo table to 2 entries
Grew fo table to 4 entries
Grew fo table to 8 entries
Increasing heap size by 65536 after 11436 allocated bytes
Grew fo table to 16 entries
Grew fo table to 32 entries
Grew fo table to 64 entries
Grew fo table to 128 entries
Increasing heap size by 65536 after 22796 allocated bytes
Grew fo table to 256 entries
Grew fo table to 512 entries
Increasing heap size by 69632 after 78976 allocated bytes
Increasing heap size by 90112 after 146000 allocated bytes
Increasing heap size by 122880 after 224344 allocated bytes
Grew fo table to 1024 entries
Grew dl table to 1 entries
Grew dl table to 2 entries
Grew dl table to 4 entries
Grew dl table to 8 entries
Increasing heap size by 163840 after 328216 allocated bytes
Increasing heap size by 217088 after 480352 allocated bytes
Increasing heap size by 290816 after 704192 allocated bytes
Increasing heap size by 385024 after 1003400 allocated bytes
Increasing heap size by 516096 after 1367328 allocated bytes
Grew dl table to 16 entries
Grew fo table to 2048 entries
Increasing heap size by 733184 after 1869512 allocated bytes
Increasing heap size by 929792 after 2607408 allocated bytes
Increasing heap size by 1241088 after 3531840 allocated bytes
Initiating full world-stop collection 2 after 4753976 allocd bytes
--> Marking for collection 2 after 4753976 allocd bytes + 36728 wasted bytes
Mark stack overflow; current size = 4096 entries
Mark stack overflow; current size = 4096 entries
Mark stack overflow; current size = 4096 entries
Mark stack overflow; current size = 4096 entries
Mark stack overflow; current size = 4096 entries
Mark stack overflow; current size = 4096 entries
Mark stack overflow; current size = 4096 entries
Mark stack overflow; current size = 4096 entries
Mark stack overflow; current size = 4096 entries
Mark stack overflow; current size = 4096 entries
Mark stack overflow; current size = 4096 entries
Mark stack overflow; current size = 4096 entries
Mark stack overflow; current size = 4096 entries
Mark stack overflow; current size = 4096 entries
Mark stack overflow; current size = 4096 entries
Mark stack overflow; current size = 4096 entries
Mark stack overflow; current size = 4096 entries
Mark stack overflow; current size = 4096 entries
Mark stack overflow; current size = 4096 entries
Mark stack overflow; current size = 4096 entries
Mark stack overflow; current size = 4096 entries
Mark stack overflow; current size = 4096 entries
Mark stack overflow; current size = 4096 entries
Grew mark stack to 8192 frames
Collection 1 finished ---> heapsize = 4988928 bytes
World-stopped marking took 90 msecs
Complete collection took 90 msecs
Segmentation fault (core dumped)

Re: gcj 4.6 on OpenBSD/x86

[Kurt Miller]

I found the root cause was OpenBSD was missing a #define for
HAVE_DL_ITERATE_PHDR. gcj is working now on both x86/x86-64
on OpenBSD. Thanks for the help.

-Kurt