Bug 227333 - rpmbuild segfaults with a given URL
rpmbuild segfaults with a given URL
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: rpm (Show other bugs)
rawhide
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Paul Nasrat
:
: 221532 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-02-05 07:01 EST by Jindrich Novy
Modified: 2013-07-02 19:19 EDT (History)
2 users (show)

See Also:
Fixed In Version: 4.4.2-43
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-07-03 07:40:09 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jindrich Novy 2007-02-05 07:01:14 EST
Description of problem:
SSIA

Version-Release number of selected component (if applicable):
rpm-4.4.2-39.fc7

How reproducible:
always

Steps to Reproduce:
1. rpmbuild --rebuild --force http://pmrb.free.fr/texlive/texlive.spm
2.
3.
  
Actual results:
error: cannot open http://pmrb.free.fr/texlive/texlive.spm:
Segmentation fault

Expected results:
no segfault

Additional info:
[root@prdell ~]# gdb --args rpmbuild --rebuild --force
http://pmrb.free.fr/texlive/texlive.spm
GNU gdb Red Hat Linux (6.6-2.fc7rh)
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu"...
(no debugging symbols found)
Using host libthread_db library "/lib64/libthread_db.so.1".
(gdb) run
Starting program: /usr/bin/rpmbuild --rebuild --force
http://pmrb.free.fr/texlive/texlive.spm
[Thread debugging using libthread_db enabled]
[New Thread 46912496261520 (LWP 3589)]
error: cannot open http://pmrb.free.fr/texlive/texlive.spm: 

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 46912496261520 (LWP 3589)]
0x00000037f2675930 in strlen () from /lib64/libc.so.6
(gdb) bt
#0  0x00000037f2675930 in strlen () from /lib64/libc.so.6
#1  0x00000037f26460d8 in _IO_vfprintf_internal (s=0x7fffc2de3c90, format=<value
optimized out>, ap=0x7fffc2de4480) at vfprintf.c:1559
#2  0x00000037f2646a93 in buffered_vfprintf (s=0x37f2947840, format=0x3a4026341b
"%s %s)\n", args=0x7fffc2de4570) at vfprintf.c:2155
#3  0x00000037f264268f in _IO_vfprintf_internal (s=0x37f2947840,
format=0x3a402633f0 "warning: _url_cache[%d] %p nrefs(%d) != 1 (%s %s)\n", 
    ap=0x7fffc2de4480) at vfprintf.c:1270
#4  0x00000037f26e11cb in ___fprintf_chk (fp=0x722f534547415353, flag=1,
format=0x37f2712bc0 "0123456789abcdefghijklmnopqrstuvwxyz") at fprintf_chk.c:37
#5  0x0000003a40231d06 in urlFreeCache () at url.c:177
#6  0x00000000004035f2 in ?? ()
#7  0x00000037f261d974 in __libc_start_main (main=0x403260, argc=4,
ubp_av=0x7fffc2de4798, init=<value optimized out>, fini=<value optimized out>, 
    rtld_fini=<value optimized out>, stack_end=0x7fffc2de4788) at libc-start.c:222
#8  0x00000000004026b9 in ?? ()
#9  0x00007fffc2de4788 in ?? ()
#10 0x0000000000000000 in ?? ()
(gdb) frame 5 
#5  0x0000003a40231d06 in urlFreeCache () at url.c:177
177                     fprintf(stderr,
(gdb) list
172             int i;
173             for (i = 0; i < _url_count; i++) {
174                 if (_url_cache[i] == NULL) continue;
175                 _url_cache[i] = urlFree(_url_cache[i], "_url_cache");
176                 if (_url_cache[i])
177                     fprintf(stderr,
178                             _("warning: _url_cache[%d] %p nrefs(%d) != 1 (%s
%s)\n"),
179                             i, _url_cache[i], _url_cache[i]->nrefs,
180                             (_url_cache[i]->host ? _url_cache[i]->host : ""),
181                             (_url_cache[i]->scheme ? _url_cache[i]->scheme :
""));
(gdb)
Comment 1 Jeff Johnson 2007-02-05 08:18:28 EST
Here is rpm-4.4.8 behavior:

    # rpmbuild --rebuild --force http://pmrb.free.fr/texlive/texlive.spm
    error: cannot open http://pmrb.free.fr/texlive/texlive.spm: Input/output error

The issue is that the server at the URI does not support OPTIONS header, and the error return
missed a reference count (iirc, another bugzilla bug for details).

No matter what, attempting to build from a remote srpm is, well, optimistic. Have fun!

UPSTREAM
Comment 2 Jindrich Novy 2007-02-05 08:55:52 EST
Jeff, thanks for analysis. I agree that to build stuff directly from remote srpm
is a bit unusual, but rpm shouldn't segfault in that case anyway ;) So here I go
with a bug.
Comment 3 Jeff Johnson 2007-02-05 11:31:55 EST
We agree, which is why I fixed the segfault ;-)

Someone ought to point out to TexLive that their advertised means of
using rpmbuild is unlikely to work anywhere, and that the extension *.spm is unconventional.

There are other problems with the texlive.spm SRPM, try
    rpm -qp --xml texlive.spm
which is triggering an assertion failure that I will sort through this evening.

And, if you're going to use an SRPM as a distribution format, ya really ought
to sign the *.src.rpm.
Comment 4 Jeff Johnson 2007-02-05 11:34:19 EST
Bot "you" personally in my comments, but you (personally) might help improve texlive rpm packaging
Comment 5 Jeff Johnson 2007-02-05 11:45:45 EST
Here's the assertion failure I see:

$ rpm -qp --xml texlive.spm 
rpmq: header.c:3489: singleSprintf: Assertion `tagN != ((void *)0)' failed.
Aborted

And this query is kinda unconventional (note off version) as well:

$ rpm -qp /tmp/texlive.spm 
texlive-3427-4.src.rpm

Digging now to find out which vendor's rpmbuild produced texlive.spm ...
Comment 6 Jindrich Novy 2007-02-05 11:57:32 EST
Well, the texlive.spm is used just as an example. It's not created by me and I
have almost finished the TeXLive packaging based on texjive which is completely
different from the texlive.spm you see here (this one seems to be designed more
for SuSE/Novell distros) and pretty much matches the Fedora standards.

So you can use this only as a reproducer for the segfault, nothing more and
nothing less :)
Comment 7 Jeff Johnson 2007-02-05 12:16:09 EST
The assertion failiure was a (lazy;-) fix to control for unidentified tag numbers
while displaying all metadate. A small fix to use snprintf instead shows

  Tag1051:
    - 5
    - 4
    - 3
    - 2
    - 1
    - 0
  Rpmversion: 4.1.1

Hmmm ... 4.1.1 is likely SuSE9 ...

Tag 1051 (if actually RPMTAG_NOSOURCE) should never ever be in headers (from rpmlib.h)

    RPMTAG_REQUIREVERSION       = 1050, /* s[] */
    RPMTAG_NOSOURCE             = 1051, /*!< internal */
    RPMTAG_NOPATCH              = 1052, /*!< internal */

And yes, rpm should not segfault. My rpm-4.4.8 does not, perhaps what other vendors are calling rpm 
does not segfault as well.

Have fun! I'm glad to see texlive getting packagaged. The doxygen doco in rpm and beecrypt is (or was) 
producing LaTeX, which broke in FC6+ in November because of some arcane ghostscript <-> LaTeX 
integration issue.

Here's a reproducer if you care (or just look at a beecrypt build):
Index: Doxyfile.in
===============================================================
====
RCS file: /cvs/devel/rpm/Doxyfile.in,v
retrieving revision 2.70.2.15
diff -u -b -B -w -p -r2.70.2.15 Doxyfile.in
--- Doxyfile.in 14 Jan 2007 21:11:18 -0000      2.70.2.15
+++ Doxyfile.in 5 Feb 2007 17:15:14 -0000
@@ -967,7 +967,7 @@ TREEVIEW_WIDTH         = 250
 # If the GENERATE_LATEX tag is set to YES (the default) Doxygen will 
 # generate Latex output.
 
-GENERATE_LATEX         = NO
+GENERATE_LATEX         = YES
 
 # The LATEX_OUTPUT tag is used to specify where the LaTeX docs will be put. 
 # If a relative path is entered the value of OUTPUT_DIRECTORY will be 

Comment 8 Panu Matilainen 2007-07-03 07:35:03 EDT
*** Bug 221532 has been marked as a duplicate of this bug. ***
Comment 9 Panu Matilainen 2007-07-03 07:40:09 EDT
F7 and rawhide are not affected by this as they don't use neon transport, but
the missing refcount is now in rpm.org tree as well (thanks Jeff) and will be in
4.4.2.1 whether neon is used or not.

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