Have you tried compiling w/ -mstrict-align (assuming you are using gcc)?
 This might at the least work around the issue.

--Mark

Tim Mooney wrote:
> 
> 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