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)
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
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.
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.
Bot "you" personally in my comments, but you (personally) might help improve texlive rpm packaging
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 ...
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 :)
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
*** Bug 221532 has been marked as a duplicate of this bug. ***
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.