On Jul 6, 2008, at 1:55 AM, Alexey Tourbin wrote:

> On Sun, Jul 06, 2008 at 06:24:43AM +0200, Alexey Tourbin wrote:
>>   Server: rpm5.org                         Name:   Alexey Tourbin
>>   Root:   /v/rpm/cvs                       Email:  at@rpm5.org
>>   Module: rpm                              Date:   06-Jul-2008  
>> 06:24:43
>>   Branch: HEAD                             Handle: 2008070604244200
>>
>>   Modified files:
>>     rpm                     CHANGES
>>     rpm/build               files.c
>>     rpm/lib                 librpm.vers rpmfi.c rpmfi.h
>>
>>   Log:
>>     rpmfi: changed fi->fnlen meaning, added rpmfiFMaxLen() function
>>
>>     - fi->fnlen: now indicates max file name lengith, without  
>> '\0' (like strlen)
>>     - rpmfiNew: find the exact max file name lengith, not dnlmax +  
>> bnlmax
>>     - rpmfiFN: allocate (fi->fnlen + 1) bytes
>>     - rpmfiFMaxLen: new function
>
> rpmfiFNMaxLen is possibly a better name - s/F/FN/.
> However, there is also rpmfiFNlink.


Names are tough. Dunno, either name WORKSFORME.

Meanwhile there's some problem with the calculation.

I'm seeing this with valgrind (note my debugging, yr lines will be  
different):
...
Executing(%check): /bin/sh -e /X/src/wdj/tests/tmp/rpm-tmp.93298
+ umask 022
+ cd /X/src/wdj/tests/devtool-sanity
+ exit 0
Processing files: devtool-sanity-1.0-1.noarch
==3228==
==3228== Use of uninitialised value of size 4
==3228==    at 0x4E28434: b64encode (in /usr/lib/libbeecrypt.so.6.4.0)
*** fi->fnlen 17
==3228==
==3228== Invalid write of size 1
==3228==    at 0x4825CEB: stpcpy (mc_replace_strmem.c:468)
==3228==    by 0x48ACDCE: rpmfiFN (rpmfi.c:152)
==3228==    by 0x48ABC82: rpmfcGenerateDepends (in /usr/lib/ 
librpm-5.0.so)
==3228==    by 0x4851916: processBinaryFiles (files.c:3091)
==3228==    by 0x484812C: buildSpec (in /usr/lib/librpmbuild-5.0.so)
==3228==    by 0x29B7: buildForTarget (in /usr/bin/rpm)
==3228==    by 0x2AD8: build (in /usr/bin/rpm)
==3228==    by 0x42D3: main (rpmqv.c:884)
==3228==  Address 0x6449aba is 0 bytes after a block of size 18 alloc'd
==3228==    at 0x4824AEE: malloc (vg_replace_malloc.c:207)
==3228==    by 0x48ACD40: rpmfiFN (rpmfi.c:147)
==3228==    by 0x48ABC82: rpmfcGenerateDepends (in /usr/lib/ 
librpm-5.0.so)
==3228==    by 0x4851916: processBinaryFiles (files.c:3091)
==3228==    by 0x484812C: buildSpec (in /usr/lib/librpmbuild-5.0.so)
==3228==    by 0x29B7: buildForTarget (in /usr/bin/rpm)
==3228==    by 0x2AD8: build (in /usr/bin/rpm)
==3228==    by 0x42D3: main (rpmqv.c:884)
==3228==
==3228== Invalid write of size 1
==3228==    at 0x4825CFE: stpcpy (mc_replace_strmem.c:468)
==3228==    by 0x48ACDCE: rpmfiFN (rpmfi.c:152)
==3228==    by 0x48ABC82: rpmfcGenerateDepends (in /usr/lib/ 
librpm-5.0.so)
==3228==    by 0x4851916: processBinaryFiles (files.c:3091)
==3228==    by 0x484812C: buildSpec (in /usr/lib/librpmbuild-5.0.so)
==3228==    by 0x29B7: buildForTarget (in /usr/bin/rpm)
==3228==    by 0x2AD8: build (in /usr/bin/rpm)
==3228==    by 0x42D3: main (rpmqv.c:884)
==3228==  Address 0x6449ad1 is not stack'd, malloc'd or (recently)  
free'd
==3228==
...

I've hot wired a fix by doing:

Index: lib/rpmfi.c
===================================================================
RCS file: /v/rpm/cvs/rpm/lib/rpmfi.c,v
retrieving revision 2.125
diff -u -b -B -w -p -r2.125 rpmfi.c
--- lib/rpmfi.c 6 Jul 2008 04:24:42 -0000       2.125
+++ lib/rpmfi.c 7 Jul 2008 02:55:01 -0000
@@ -142,8 +142,13 @@ const char * rpmfiFN(rpmfi fi)
      if (fi != NULL && fi->i >= 0 && fi->i < (int)fi->fc) {
         const char *dn;
         char * t;
-       if (fi->fn == NULL)
+       if (fi->fn == NULL) {
+#ifdef HACKAROUND
             fi->fn = xmalloc(fi->fnlen + 1);
+#else
+           fi->fn = xmalloc(BUFSIZ);
+#endif
+       }
         FN = t = fi->fn;
         (void) urlPath(fi->dnl[fi->dil[fi->i]], &dn);
         *t = '\0';

I don't see anything obviously wrong in yer changes, but
the reordering, and more extensive use of rpmfiFoo() methods,
may have exposed a previously sneaky use of a rpmfi internals.

The issue is likely that build paths are used with and without
a %{buildroot} prefix would be my guess. The rpmfc methods are
likely needing space for the %{buildroot} prefix too. Just a guess ....

73 de Jeff