* gcj 4.6 on OpenBSD/x86
@ 2012-10-08 20:08 Kurt Miller
2012-10-08 20:35 ` David Daney
0 siblings, 1 reply; 9+ messages in thread
From: Kurt Miller @ 2012-10-08 20:08 UTC (permalink / raw)
To: java
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: gcj 4.6 on OpenBSD/x86
2012-10-08 20:08 gcj 4.6 on OpenBSD/x86 Kurt Miller
@ 2012-10-08 20:35 ` David Daney
2012-10-08 22:10 ` Kurt Miller
0 siblings, 1 reply; 9+ messages in thread
From: David Daney @ 2012-10-08 20:35 UTC (permalink / raw)
To: Kurt Miller; +Cc: java
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: gcj 4.6 on OpenBSD/x86
2012-10-08 20:35 ` David Daney
@ 2012-10-08 22:10 ` Kurt Miller
2012-10-09 0:51 ` Andrew Haley
0 siblings, 1 reply; 9+ messages in thread
From: Kurt Miller @ 2012-10-08 22:10 UTC (permalink / raw)
To: David Daney; +Cc: java
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: gcj 4.6 on OpenBSD/x86
2012-10-08 22:10 ` Kurt Miller
@ 2012-10-09 0:51 ` Andrew Haley
2012-10-09 13:06 ` Kurt Miller
0 siblings, 1 reply; 9+ messages in thread
From: Andrew Haley @ 2012-10-09 0:51 UTC (permalink / raw)
To: Kurt Miller; +Cc: David Daney, java
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: gcj 4.6 on OpenBSD/x86
2012-10-09 0:51 ` Andrew Haley
@ 2012-10-09 13:06 ` Kurt Miller
2012-10-09 17:22 ` Boehm, Hans
0 siblings, 1 reply; 9+ messages in thread
From: Kurt Miller @ 2012-10-09 13:06 UTC (permalink / raw)
To: Andrew Haley; +Cc: David Daney, java
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* RE: gcj 4.6 on OpenBSD/x86
2012-10-09 13:06 ` Kurt Miller
@ 2012-10-09 17:22 ` Boehm, Hans
2012-10-09 18:27 ` Kurt Miller
2012-10-10 13:33 ` Kurt Miller
0 siblings, 2 replies; 9+ messages in thread
From: Boehm, Hans @ 2012-10-09 17:22 UTC (permalink / raw)
To: Kurt Miller, Andrew Haley; +Cc: David Daney, java
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: gcj 4.6 on OpenBSD/x86
2012-10-09 17:22 ` Boehm, Hans
@ 2012-10-09 18:27 ` Kurt Miller
2012-10-10 13:33 ` Kurt Miller
1 sibling, 0 replies; 9+ messages in thread
From: Kurt Miller @ 2012-10-09 18:27 UTC (permalink / raw)
To: Boehm, Hans; +Cc: Andrew Haley, David Daney, java
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: gcj 4.6 on OpenBSD/x86
2012-10-09 17:22 ` Boehm, Hans
2012-10-09 18:27 ` Kurt Miller
@ 2012-10-10 13:33 ` Kurt Miller
2012-10-14 11:26 ` Kurt Miller
1 sibling, 1 reply; 9+ messages in thread
From: Kurt Miller @ 2012-10-10 13:33 UTC (permalink / raw)
To: Boehm, Hans; +Cc: java
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)
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: gcj 4.6 on OpenBSD/x86
2012-10-10 13:33 ` Kurt Miller
@ 2012-10-14 11:26 ` Kurt Miller
0 siblings, 0 replies; 9+ messages in thread
From: Kurt Miller @ 2012-10-14 11:26 UTC (permalink / raw)
To: Boehm, Hans; +Cc: java
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
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2012-10-14 11:26 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-10-08 20:08 gcj 4.6 on OpenBSD/x86 Kurt Miller
2012-10-08 20:35 ` David Daney
2012-10-08 22:10 ` Kurt Miller
2012-10-09 0:51 ` Andrew Haley
2012-10-09 13:06 ` Kurt Miller
2012-10-09 17:22 ` Boehm, Hans
2012-10-09 18:27 ` Kurt Miller
2012-10-10 13:33 ` Kurt Miller
2012-10-14 11:26 ` Kurt Miller
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).