Bug 112643 - rpmbuild segfaults after %doc
Summary: rpmbuild segfaults after %doc
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Raw Hide
Classification: Retired
Component: rpm-build
Version: 1.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jeff Johnson
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-12-25 22:00 UTC by Kaj J. Niemi
Modified: 2007-04-18 17:00 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2003-12-26 03:18:07 UTC
Embargoed:


Attachments (Terms of Use)
problematic mysql.spec attached (7.99 KB, text/plain)
2003-12-25 22:01 UTC, Kaj J. Niemi
no flags Details

Description Kaj J. Niemi 2003-12-25 22:00:44 UTC
Description of problem:
rpmbuild 4.2.2-0.7 segfaults every time while building a specific
.spec (attached), I tried with some others (yum.spec for example) and
it builds just fine. Also, the .spec builds cleanly with rpmbuild
4.2.2-0.6.

Wasn't able to find the debuginfo package for rpm so the backtrace is
a bit bare. I guess I could rebuild it myself, though.

How reproducible:
Always

Steps to Reproduce:
1. rpmbuild -ba mysql.spec
2.
3.
  
Actual results:
(gdb) bt
#0  0x0018a76c in _int_realloc () from /lib/tls/libc.so.6
#1  0x001891bf in realloc () from /lib/tls/libc.so.6
#2  0x005385a7 in file_showstr () from /usr/lib/librpmio-4.2.so
#3  0x00538a02 in file_showstr () from /usr/lib/librpmio-4.2.so
#4  0x00538d08 in file_showstr () from /usr/lib/librpmio-4.2.so
#5  0x00538ef3 in fmagicSetup () from /usr/lib/librpmio-4.2.so
#6  0x00586f54 in rpmfcClassify () from /usr/lib/librpmbuild-4.2.so
#7  0x00587811 in rpmfcGenerateDepends () from /usr/lib/librpmbuild-4.2.so
#8  0x0057a5c0 in processBinaryFiles () from /usr/lib/librpmbuild-4.2.so
#9  0x00573e29 in buildSpec () from /usr/lib/librpmbuild-4.2.so
#10 0x0804a2a6 in ?? ()
#11 0x081bbd98 in ?? ()
#12 0x081c5218 in ?? ()
#13 0x000000df in ?? ()
(gdb)

Comment 1 Kaj J. Niemi 2003-12-25 22:01:33 UTC
Created attachment 96698 [details]
problematic mysql.spec attached

Comment 2 Jeff Johnson 2003-12-26 01:07:22 UTC
Your spec file fails to build.

Can you supply a src.rpm that reproduces the problem please.

Comment 3 Kaj J. Niemi 2003-12-26 01:51:48 UTC
Sure. You'll find the SRPM at
<http://www.a51.org/sw/foo/mysql-5.0.0-1.src.rpm>, no sense in putting
16 megabytes into bugzilla.

Let me know if there is anything else you require. :)


Comment 4 Jeff Johnson 2003-12-26 02:03:05 UTC
Built for me with a couple tweaks, but older version of file.
Checking with valgrind, then same with newer version of internal
file.

Comment 5 Jeff Johnson 2003-12-26 02:11:34 UTC
All I see is a known problem in file accessing off the end
of an array at end of loop:

==29568== 413 errors in context 8 of 8:
==29568== Invalid read of size 2
==29568==    at 0x5B117B: fmagicSMatch (softmagic.c:991)
==29568==    by 0x5B13F8: fmagicS (softmagic.c:1073)
==29568==    by 0x5AD524: fmagicF (fsmagic.c:257)
==29568==    by 0x5AD712: fmagicProcess (fsmagic.c:335)
==29568==    Address 0xF3764880 is not stack'd, malloc'd or free'd

On to latest internal file ...


Comment 6 Jeff Johnson 2003-12-26 02:27:30 UTC
Ah there's the sucker:

==6368==
==6368== Invalid free() / delete / delete[]
==6368==    at 0x7E88D7: realloc (vg_replace_malloc.c:310)
==6368==    by 0xE10A78: mkdbname (apprentice.c:804)
==6368==    by 0xE10E0B: apprentice_map (apprentice.c:936)
==6368==    by 0xE110A7: apprentice_1 (apprentice.c:1044)
==6368==    Address 0x122BDC0 is 0 bytes inside a block of size 23 free'd
==6368==    at 0x7E85AC: free (vg_replace_malloc.c:231)
==6368==    by 0x135BA2: rpmdsNext (rpmlib.h:61)
==6368==    by 0xAA4EDC: printDeps (rpmfc.c:1320)
==6368==    by 0xAA55B3: rpmfcGenerateDepends (rpmfc.c:1620)
rpmbuild: out of memory


Frobbed attempt to plug a memory leak.

Comment 7 Kaj J. Niemi 2003-12-26 02:52:47 UTC
Yeah looks that way.. 

I took the time to rebuild rpm-4.2.2-0.7 to get the debug symbols into
 the backtrace included below for completeness:

(gdb) bt
#0  0x0056276c in _int_realloc () from /lib/tls/libc.so.6
#1  0x005611bf in realloc () from /lib/tls/libc.so.6
#2  0x0012f5a7 in mkdbname (fn=0x627180 "\001") at apprentice.c:804
#3  0x0012fa02 in apprentice_map (fm=0x14f700, magicp=0xbfe620d4,
nmagicp=0xbfe620d8, fn=0x5f6c70e1 <Address 0x5f6c70e1 out of bounds>,
    action=0) at apprentice.c:936
#4  0x0012fd08 in apprentice_1 (fm=0x14f700, fn=0x9e15d00
"/usr/lib/rpm/magic", action=0) at apprentice.c:1044
#5  0x0012fef3 in fmagicSetup (fm=0x14f700, fn=0x9e15d00
"/usr/lib/rpm/magic", action=0) at apprentice.c:1101
#6  0x00b5bf54 in rpmfcClassify (fc=0x9e34d68, argv=0x9e224f8) at
rpmfc.c:1171
#7  0x00b5c811 in rpmfcGenerateDepends (spec=0x5f6c70e1,
pkg=0x9e17df8) at rpmfc.c:1523
#8  0x00b4f5c0 in processBinaryFiles (spec=0x9e0d200,
installSpecialDoc=4, test=0) at files.c:2419
#9  0x00b48e29 in buildSpec (ts=0x9e03d98, spec=0x9e0d200, what=223,
test=0) at build.c:332
#10 0x0804a2a6 in ?? ()
#11 0x09e03d98 in ?? ()
#12 0x09e0d200 in ?? ()
#13 0x000000df in ?? ()
(gdb)



Comment 8 Jeff Johnson 2003-12-26 03:18:07 UTC
This should fix ya up (checking with valgrind on your build now,
my test case was time, which did not walk the double free):

Index: file/src/apprentice.c
===================================================================
RCS file: /cvs/devel/rpm/file/src/apprentice.c,v
retrieving revision 1.6
diff -u -b -B -w -p -r1.6 apprentice.c
--- file/src/apprentice.c       23 Dec 2003 06:56:46 -0000      1.6
+++ file/src/apprentice.c       26 Dec 2003 03:18:41 -0000
@@ -793,17 +793,13 @@ byteswap(/*@null@*/ struct magic *m, uin
 /*
  * make a dbname
  */
+/*@only@*/
 static char *
 mkdbname(const char *fn)
        /*@*/
 {
-       static const char ext[] = ".mgc";
-       /*@only@*/
-       static char *buf = NULL;
-
-       buf = xrealloc(buf, strlen(fn) + sizeof(ext) + 1);
-       (void)strcpy(buf, fn);
-       (void)strcat(buf, ext);
+       char * buf = xmalloc(strlen(fn) + sizeof(".mgc"));
+       (void) stpcpy( stpcpy(buf, fn), ".mgc");
        return buf;
 }
  
You'll have to revert to -0.6 or wait until next year for -0.8.
I'll try to get there earlier, but ...

Comment 9 Kaj J. Niemi 2003-12-26 03:27:26 UTC
I'll go with 0.6 since it works well although I'll try your patch to
0.7 and see what happens.

Merry Xmas and thanks for your help!



Comment 10 Jeff Johnson 2003-12-26 03:36:24 UTC
np. worksforme, look for -0.8, possibly tomorrow, but ...

Comment 11 Kaj J. Niemi 2003-12-26 03:52:10 UTC
Works for me, too.


Note You need to log in before you can comment on or make changes to this bug.