Re: LP64 alignment issue in 4.4.9 and CVS
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 > [EMAIL PROTECTED] ([EMAIL PROTECTED]) terminated by signal BUS (invalid > address alignment) > Current function is intGetEntry > 1784 if (p) *p = NULL; > (dbx) print p p = 0x7fffe78c > (dbx) print *p > *p = (nil) > (dbx) where current thread: [EMAIL PROTECTED] > =>[1] intGetEntry(h = 0x100145960, tag = 1184, type = (nil), p = > 0x7fffe78c, c = 0x7fffe75c, minMem = 1), line 1784 in > "header.c" > [2] headerGetEntryMinMemory(h = 0x100145960, tag = 1184, type = > 0x7fffe77c, p = 0x7fffe78c, c = 0x7fffe75c), > line 1876 in "header.c" > [3] headerGetEntryMinMemory(h = 0x100145960, tag = 1184, type = > 0x7fffe77c, p = 0x7fffe78c, c = 0x7fffe75c), > 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 = 0x7f286d18, > argv = 0x100111c38), line 620 in "rpmchecksig.c" > [7] rpmcliSign(ts = 0x10013fc00, qva = 0x7f286d18, argv = > 0x100111c30), line 1080 in "rpmchecksig.c" > [8] main(argc = 3, argv = 0x7fffee28, envp = > 0x7fffee48), 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 __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: LP64 alignment issue in 4.4.9 and CVS
In regard to: Re: LP64 alignment issue in 4.4.9 and CVS, Mark Hatle said...: Have you tried compiling w/ -mstrict-align (assuming you are using gcc)? This might at the least work around the issue. I'm not using gcc, although your comment is still useful, since it got me looking at the alignment options for the Sun compilers. I think if I wanted to work around this issue, I could use -xmemalign=8i Also: 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. After looking at it further, I don't think "int32_t tid" is going to be a problem, since it's used in a different way and not cast to (void **). Tim -- Tim Mooney[EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building(701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: LP64 alignment issue in 4.4.9 and CVS
On Jun 26, 2007, at 12:28 PM, 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. This bug was reported by PLD/sparc64 abt a week ago. There's an alignment issues with &hcolor. See recent checkin for fix on both HEAD and rpm-4_5. hth 73 de Jeff __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: LP64 alignment issue in 4.4.9 and CVS
In regard to: Re: LP64 alignment issue in 4.4.9 and CVS, Jeff Johnson said...: On Jun 26, 2007, at 12:28 PM, 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. This bug was reported by PLD/sparc64 abt a week ago. There's an alignment issues with &hcolor. See recent checkin for fix on both HEAD and rpm-4_5. Thanks for the info, sorry for the duplicate report. Tim -- Tim Mooney[EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building(701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: LP64 alignment issue in 4.4.9 and CVS
On Jun 27, 2007, at 2:55 PM, Tim Mooney wrote: This bug was reported by PLD/sparc64 abt a week ago. There's an alignment issues with &hcolor. See recent checkin for fix on both HEAD and rpm-4_5. Thanks for the info, sorry for the duplicate report. Heh, thanks for reporting even if duplicate. The bug has been there for a while, easy fixing when reported. The problem is seen only on sparc64. 73 de Jeff __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org