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