rpm 4.4.9 on sparcv9-sun-solaris2.8 (LP64) compiled with the Sun Workshop
11 compiler gets a reproduceable SIGBUS when installing a package or
importing a key with a fresh database.  I haven't seen this problem on
my x86_64-sun-solaris2.10 workstation which is also running rpm 4.4.9.
x86_64 must be more forgiving of alignment than LP64 sparc.

I've done some digging and I think the problem is basically the same as
this one, but in a different spot:

 	https://lists.dulug.duke.edu/pipermail/rpm-devel/2006-October/001791.html


The stack trace looks like

$ dbx .libs/rpmk core
core file header read successfully
Reading ld.so.1
Reading librpm-4.4.so
Reading librpmdb-4.4.so
Reading librpmio-4.4.so
Reading libpopt.so.0
Reading libelf.so.1
Reading libbeecrypt.so.7
Reading libneon.so.26
Reading libexpat.so.1
Reading libm.so.1
Reading libdl.so.1
Reading libz.so
Reading libintl.so.8
Reading libc.so.1
Reading librt.so.1
Reading libpthread.so.1
Reading libsocket.so.1
Reading libnsl.so.1
Reading libthread.so.1
Reading libCstd.so.1
Reading libCrun.so.1
Reading libaio.so.1
Reading libmp.so.2
Reading libc_psr.so.1
t@1 (l@1) terminated by signal BUS (invalid address alignment)
Current function is intGetEntry
  1784           if (p) *p = NULL;
(dbx) print p 
p = 0xffffffff7fffe78c
(dbx) print *p
*p = (nil)
(dbx) where 
current thread: t@1
=>[1] intGetEntry(h = 0x100145960, tag = 1184, type = (nil), p = 0xffffffff7fffe78c, c = 0xffffffff7fffe75c, minMem = 1), line 1784 in "header.c"
   [2] headerGetEntryMinMemory(h = 0x100145960, tag = 1184, type = 0xffffffff7fffe77c, p = 0xffffffff7fffe78c, c = 0xffffffff7fffe75c), line 1876 in "header.c"
   [3] headerGetEntryMinMemory(h = 0x100145960, tag = 1184, type = 0xffffffff7fffe77c, p = 0xffffffff7fffe78c, c = 0xffffffff7fffe75c), line 299 in "hdrinline.h"
   [4] rpmdbAdd(db = 0x10012cc00, iid = 1182551776, h = 0x100145960, ts = (nil), hdrchk = (nil)), line 3125 in "rpmdb.c"
   [5] rpmcliImportPubkey(ts = 0x10013fc00, pkt = 0x100142e00 "\x99^A\xa1^D:\xb1Br^Q^D", pktlen = 1638), line 539 in "rpmchecksig.c"
   [6] rpmcliImportPubkeys(ts = 0x10013fc00, qva = 0xffffffff7f286d18, argv = 0x100111c38), line 620 in "rpmchecksig.c"
   [7] rpmcliSign(ts = 0x10013fc00, qva = 0xffffffff7f286d18, argv = 0x100111c30), line 1080 in "rpmchecksig.c"
   [8] main(argc = 3, argv = 0xffffffff7fffee28, envp = 0xffffffff7fffee48), line 794 in "rpmqv.c"




It looks like the problem begins in rpmdbAdd() in rpmdb.c, with:

     uint32_t hcolor = 0;

...

     if (!hge(h, RPMTAG_PACKAGECOLOR, &bnt, (void **) &hcolor, &count)) {


Because hcolor starts out as a 32 bit quantity, it's aligned on a 4-byte
boundary.  It's later used in a context where it would need to be aligned
on an 8-byte boundary.  If I make the same "fix" that I did for the
problem I reported last October, changing the type from uint32_t to
uint64_t, the problem goes away.

It looks like there might be another problem lurking nearby with the

 	int32_t tid = iid;

but I haven't actually triggered that problem yet.

Jeff, if you need any additional information to formulate a correct fix,
let me know.


Tim
-- 
Tim Mooney                                        Tim.Mooney@ndsu.edu
Information Technology Services                   (701) 231-1076 (Voice)
Room 242-J6, IACC Building                        (701) 231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164