On Jun 18, 2007, at 3:00 PM, Jakub Bogusz wrote: > > 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? >
Nope. All that is needed is a tag existence check, using NULL skips the test. Index: rpmdb.c =================================================================== RCS file: /v/rpm/cvs/rpm/rpmdb/rpmdb.c,v retrieving revision 1.130 diff -u -b -B -w -p -r1.130 rpmdb.c --- rpmdb.c 10 Jun 2007 20:44:43 -0000 1.130 +++ rpmdb.c 18 Jun 2007 19:16:38 -0000 @@ -3101,7 +3101,7 @@ memset(data, 0, sizeof(*data)); } /* Add the package color if not present. */ - if (!hge(h, RPMTAG_PACKAGECOLOR, &bnt, &hcolor, &count)) { + if (!hge(h, RPMTAG_PACKAGECOLOR, &bnt, NULL, &count)) { hcolor = hGetColor(h); xx = hae(h, RPMTAG_PACKAGECOLOR, RPM_INT32_TYPE, &hcolor, 1); } A better approach would be to use headerIsEntry(h, RPMTAG_PACKAGECOLOR) instead. I'll get a final fix checked in this evening. >> FWIW, tag=1184 is RPMTAG_PACKAGECOLOR added on >> multilib systems. That's likely not PLD/sparc64. > > That sparc64 experiment uses multilib. > Good. And sparc's are always useful for finding alignment (and other) bugs. Thanks for the report. 73 de Jeff _______________________________________________ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en