Yesterday i recompiled the naoko SRPMS on Fedora Core 1, and was able to enjoy the insane speed increase when using the resulting ant binary to build small ant projects. Howerver, when i try to do the same thing today ant dies with a segfault. How do I investigate this further. Running 'gdb ant' gives the following output: Starting program: /usr/bin/ant [Thread debugging using libthread_db enabled] [New Thread -1084473216 (LWP 4823)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1084473216 (LWP 4823)] 0x00751ada in org.apache.xerces.impl.xs.XSDDescription.equals(java.lang.Object) (this=@6811c02, descObj=@bf37d8a0) at upstream/src/org/apache/xerces/impl/xs/XSDDescription.java:226 226 public boolean equals(Object descObj) { Current language: auto; currently java To my knowledge, nothing has changed on the system. How should I go about debugging this? cheers/noa ps. I have no previous experience using gcj, so segfaults from java code is a new thing to me.
Noa Resare wrote: > Starting program: /usr/bin/ant > [Thread debugging using libthread_db enabled] > [New Thread -1084473216 (LWP 4823)] > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread -1084473216 (LWP 4823)] > 0x00751ada in > org.apache.xerces.impl.xs.XSDDescription.equals(java.lang.Object) > (this=@6811c02, descObj=@bf37d8a0) > at upstream/src/org/apache/xerces/impl/xs/XSDDescription.java:226 > 226 public boolean equals(Object descObj) { > Current language: auto; currently java > > How should I go about debugging this? The way I debug things is to keep a copy of gcc and RHUG built with -O0, etc, and try and reproduce the failure in that. That way I can change things easily. Can you generate a backtrace for the above? Also, are you using the very latest Naoko packages? Including Naoko gcc-ssa? The gcc-ssa in Fedora will not work. > ps. I have no previous experience using gcj, so segfaults from java > code is a new thing to me. Debugging them is pretty much like debugging C or C++, except that listings come up in Java ;) Gary
[-- Attachment #1: Type: text/plain, Size: 786 bytes --] fre 2003-11-28 klockan 13.04 skrev Gary Benson: > Noa Resare wrote: > > Program received signal SIGSEGV, Segmentation fault. > > > > How should I go about debugging this? > > The way I debug things is to keep a copy of gcc and RHUG built with > -O0, etc, and try and reproduce the failure in that. That way I can > change things easily. In a few days perhaps I'll have the time to try setting up such an environment. > Can you generate a backtrace for the above? Also, are you using the > very latest Naoko packages? Including Naoko gcc-ssa? The gcc-ssa in > Fedora will not work. Backtrace is attached. I use the following versions which I believe are the latest: [noa@molly bin]$ rpm -q gcc-ssa xerces-j ant gcc-ssa-3.5ssa-0.20030801.43 xerces-j-2.2.1-11 ant-1.5.2-23 /noa [-- Attachment #2: ant-bt.txt --] [-- Type: text/plain, Size: 2457 bytes --] (gdb) bt #0 0x00751ada in org.apache.xerces.impl.xs.XSDDescription.equals(java.lang.Object) (this=@6811c02, descObj=@bf2c48a0) at upstream/src/org/apache/xerces/impl/xs/XSDDescription.java:226 #1 0x068481fd in gnu::gcj::runtime::StackTrace::getClass(gnu::gcj::RawData*) ( p=@6811cea) at ../../../libjava/gnu/gcj/runtime/natStackTrace.cc:129 #2 0x068482ce in gnu::gcj::runtime::StackTrace::classAt(int) (this=@6ca1688, n=109124610) at ../../../libjava/gnu/gcj/runtime/natStackTrace.cc:150 #3 0x0684b8c0 in java::lang::Class::forName(java::lang::String*) ( className=@6811cea) at ../../../libjava/java/lang/natClass.cc:102 #4 0x06811c02 in gnu.gcj.convert.UnicodeToBytes.getDefaultEncoder() () at ../../../libjava/gnu/gcj/convert/UnicodeToBytes.java:49 #5 0x0688cf0c in java.io.PrintStream.PrintStream(java.io.OutputStream, boolean) (this=@bf2c9fa8, out=@6811cea) at ../../../libjava/java/io/PrintStream.java:128 #6 0x068733fc in java.lang.System.<clinit>() () at ../../../libjava/java/lang/System.java:135 #7 0x0684cf81 in java::lang::Class::initializeClass() (this=@6bcd8e0) at ../../../libjava/java/lang/natClass.cc:831 #8 0x069fb8f8 in _Jv_InitClass (klass=@6811cea) at Class.h:265 #9 0x06872d24 in java.lang.System.getProperty(java.lang.String) ( key=@bf2e6f00) at ../../../libjava/java/lang/System.java:393 #10 0x06876170 in java.lang.Throwable.<clinit>() () at ../../../libjava/java/lang/Throwable.java:403 #11 0x0684cf81 in java::lang::Class::initializeClass() (this=@6bce7c0) at ../../../libjava/java/lang/natClass.cc:831 #12 0x0684d068 in java::lang::Class::initializeClass() (this=@6bc7760) at Class.h:265 #13 0x0684d068 in java::lang::Class::initializeClass() (this=@6bcaee0) at Class.h:265 #14 0x0684d068 in java::lang::Class::initializeClass() (this=@6bca140) at Class.h:265 #15 0x0682bb38 in _Jv_AllocObjectNoFinalizer (klass=@6bca140, size=20) at Class.h:265 #16 0x0682bb6c in _Jv_AllocObject (klass=@6bca140, size=109124842) at ../../../libjava/prims.cc:415 #17 0x0682c9ce in _Jv_CreateJavaVM(void*) () at ../../../libjava/prims.cc:921 #18 0x0682cbaf in _Jv_RunMain(java::lang::Class*, char const*, int, char const**, bool) (klass=@8049a20, name=null, argc=1, argv=@bfef4224, is_jar=false) at ../../../libjava/prims.cc:973 #19 0x0682cd5b in JvRunMain (klass=@6811cea, argc=109124842, argv=@6811cea) at ../../../libjava/prims.cc:1011 #20 0x0804877c in main ()
Noa Resare wrote: > Backtrace is attached. I use the following versions which I believe are > the latest: > > [noa@molly bin]$ rpm -q gcc-ssa xerces-j ant > gcc-ssa-3.5ssa-0.20030801.43 > xerces-j-2.2.1-11 > ant-1.5.2-23 Indeed they are. > (gdb) bt [snip] Hmmm, looks like it's failing somewhere deep in libgcj. Do any of the gcj hackers here recognise it? Gary
On Fri, 28 Nov 2003, Noa Resare wrote:
> Backtrace is attached.
The failure is very early in libgcj's initialization, most likely before
any application code has run.
In cases like these I've learned (the hard way) to first suspect binutils
problems. Any chance that the binutils you used for a successful build
were somehow different?
Jeff
fre 2003-11-28 klockan 12.41 skrev Noa Resare:
> Yesterday i recompiled the naoko SRPMS on Fedora Core 1, and was able to
> enjoy the insane speed increase when using the resulting ant binary to
> build small ant projects.
>
> Howerver, when i try to do the same thing today ant dies with a
> segfault.
This is really puzzling. When I tried now to rebuild from .src.rpm the
problem went away. The really strange part is that when I installed the
old rpms (the same binaries that consistently produced segfaults some
minutes ago) they work as expected now.
So I'm afraid I can't help you find the root of this evil unless it
shows it's ugly face again :)
/noa
ps. keep up the good work!
fre 2003-11-28 klockan 12.41 skrev Noa Resare:
> Yesterday i recompiled the naoko SRPMS on Fedora Core 1, and was able to
> enjoy the insane speed increase when using the resulting ant binary to
> build small ant projects.
>
> Howerver, when i try to do the same thing today ant dies with a
> segfault.
The reason for this was the nightly 'prelink' run:
[root@dublin tmp]# ant
Buildfile: build.xml does not exist!
Build failed
[root@dublin tmp]# /etc/cron.daily/prelink
[root@dublin tmp]# ant
Segmenteringsfel
The "correct" fix for this (other than disabling daily prelinking) is
beyond me to find. I'll leave that to the people @redhat.com :)
cheers/noa