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
LP64 alignment issue in 4.4.9 and CVS
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
--
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
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
