[Th] rpm at sparc64

[Jeff Johnson]

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