rawhide report: 20060802 changes
Andrew Haley
aph at redhat.com
Wed Aug 2 12:49:23 UTC 2006
Erwin Rol writes:
> On Wed, 2006-08-02 at 12:44 +0100, Andrew Haley wrote:
> > Erwin Rol writes:
> > > This update also caused the following errors on x86_&4;
> > >
> > > Running Transaction
> > > Updating : java-1.4.2-gcj-compat ####################### [ 1/66]
> > > dirname: missing operand
> > > Try `dirname --help' for more information.
> > > mkdir: missing operand
> > > Try `mkdir --help' for more information.
> > > /usr/bin/rebuild-gcj-db: line 17: 20713 Segmentation fault /usr/bin/gcj-dbtool -n $dbLocation 64
> > > xargs: /usr/bin/gcj-dbtool: terminated by signal 11
> >
> > I use x86_64, and I've never seen this. Can you try running
> > gcj-dbtool in gdb? Also, please let us know which gcc and libgcj RPMs
> > you have installed.
>
> rpm -q libgcc
> libgcc-4.1.1-13
> libgcc-4.1.1-13
>
> rpm -q libgcj
> libgcj-4.1.1-13
> libgcj-4.1.1-13
>
> rpm -q glibc
> glibc-2.4.90-15
> glibc-2.4.90-15
>
> uname -a
> Linux xpc.home.erwinrol.com 2.6.17-1.2488.fc6 #1 SMP Mon Jul 31 21:09:02 EDT 2006 x86_64 x86_64 x86_64 GNU/Linux
>
> [erwin at xpc de_bv]$ gdb /usr/bin/gcj-dbtool
> GNU gdb Red Hat Linux (6.5-3.fc6rh)
> Copyright (C) 2006 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB. Type "show warranty" for details.
> This GDB was configured as "x86_64-redhat-linux-gnu"...Using host libthread_db library "/lib64/libthread_db.so.1".
>
> (gdb) r
> Starting program: /usr/bin/gcj-dbtool
> [Thread debugging using libthread_db enabled]
> [New Thread 46912496314704 (LWP 27871)]
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 46912496314704 (LWP 27871)]
> *__GI__dl_addr (address=0x606020, info=0x7fffe9437a00, mapp=0x0, symbolp=0x0) at dl-addr.c:90
> 90 if ((ELFW(ST_BIND) (symtab->st_info) == STB_GLOBAL
> (gdb) bt
> #0 *__GI__dl_addr (address=0x606020, info=0x7fffe9437a00, mapp=0x0, symbolp=0x0) at dl-addr.c:90
> #1 0x000000349052350b in _Jv_RegisterLibForGc (p=0x0) at ../../../libjava/boehm.cc:672
> #2 0x00000034905183bc in _Jv_RegisterClasses (classes=0x0) at ../../../libjava/java/lang/natClassLoader.cc:191
OK, this is the problem: _Jv_RegisterClasses shouldn't be passed NULL.
It's called from frame_dummy() and __do_global_ctors_1() in
crtstuff.c:
#ifdef JCR_SECTION_NAME
if (__JCR_LIST__[0])
{
void (*register_classes) (void *) = _Jv_RegisterClasses;
__asm ("" : "+r" (register_classes));
if (register_classes)
register_classes (__JCR_LIST__);
}
#endif /* JCR_SECTION_NAME */
OK, now here is the real weirdness: gcj-dbtool is *used* during the
RPM build, so that exact same gcj-dbtool binary that is now
segfaulting must have worked once.
> #3 0x000000000040271e in _init ()
OK, so this address indicates that we're being called from the main
program, not while initializing a library.
Maybe something has broken /lib/ld-linux.so.2. I'll try updating;
here goes.
Andrew.
More information about the fedora-devel-list
mailing list