On Mon, Jun 18, 2007 at 02:40:27PM -0400, Jeff Johnson wrote: > On Jun 18, 2007, at 2:10 PM, Tomasz Mateja wrote: > >> removed and it's built right now, btw binutils are current. > >> > > not working: > > > > [EMAIL PROTECTED] RPMS]# gdb rpm > > GNU gdb 6.6 > > 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 "sparc64-pld-linux"... > > Using host libthread_db library "/lib64/libthread_db.so.1". > > (gdb) run --rebuilddb > > Starting program: /bin/rpm --rebuilddb > > > > Program received signal SIGBUS, Bus error. > > 0xfffff8010000fbec in intGetEntry (h=0x26b4e0, tag=1184, > > type=0x7feffef9518, p=0x7feffef951c, c=0x7feffef950c, minMem=1) at > > header.c:1785 > > 1785 if (p) *p = NULL; > > Likely alignment on sparc64. Pointers aligned on 64bit boundary on > sparc64? > > One hack-a-round is: > memset(p, 0, sizeof(*p)); > instead of > *p = NULL; > but you may die in caller instead.
Something odd. In rpmdbAdd() (rpmdb.c) hcolor is declared locally as uint32_t (so it's OK for it to be just 4-byte aligned). Then (in rpmdb.c:3125) its address is casted to void** and passed as *p through hge() finally to intGetEntry(). So intGetEntry() tries to set hcolor as (64-bit) pointer... and on sparc64 it finally crashes on alignment, but on x86_64 it seems that it overwrites some other value on stack (signalMask?). Am I wrong? > FWIW, tag=1184 is RPMTAG_PACKAGECOLOR added on > multilib systems. That's likely not PLD/sparc64. That sparc64 experiment uses multilib. -- Jakub Bogusz http://qboosh.pl/ _______________________________________________ pld-devel-en mailing list [email protected] http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
