Created attachment 569029 [details] glibc backtrace Description of problem: When making or updating a repository with createrepo, there's a double free within sqlite. Looking at the yum history, it seems to be the only package updated since I last remember it working that could affect it. Version-Release number of selected component (if applicable): createrepo-0.9.9-11.fc18.noarch sqlite-3.7.10-1.fc18.x86_64 Additional info: Updated sqlite-3.7.9-1.fc17.x86_64 @rawhide/17 Update 3.7.10-1.fc18.x86_64 @rawhide #0 0x00007fb72ed1e8d5 in raise () from /lib64/libc.so.6 #1 0x00007fb72ed20088 in abort () from /lib64/libc.so.6 #2 0x00007fb72ed5dd0b in __libc_message () from /lib64/libc.so.6 #3 0x00007fb72ed6764b in realloc_check () from /lib64/libc.so.6 #4 0x00007fb72490af80 in sqlite3MemRealloc (pPrior=0x1879a90, nByte=96) at sqlite3.c:15284 #5 0x00007fb7248efe3b in sqlite3Realloc (pOld=0x1879a90, nBytes=93) at sqlite3.c:19053 #6 0x00007fb7248fd644 in sqlite3_realloc (pOld=<optimized out>, n=<optimized out>) at sqlite3.c:19078 #7 0x00007fb7248fd6a4 in sqlite3DbRealloc (db=0x1940be0, p=0x1879a90, n=<optimized out>) at sqlite3.c:19188 #8 0x00007fb724901365 in sqlite3StrAccumAppend (N=12, z=0x7fb724968c60 ", rootpage=#%d, sql=%Q WHERE rowid=#%d", p=0x7fff37616260) at sqlite3.c:20013 #9 sqlite3StrAccumAppend (p=0x7fff37616260, z=0x7fb724968c60 ", rootpage=#%d, sql=%Q WHERE rowid=#%d", N=<optimized out>) at sqlite3.c:19979 #10 0x00007fb7249014f3 in sqlite3VXPrintf (pAccum=pAccum@entry=0x7fff37616260, useExtended=useExtended@entry=1, fmt=0x7fb724968c6c "%d, sql=%Q WHERE rowid=#%d", ap=ap@entry=0x7fff376162f8) at sqlite3.c:19499 #11 0x00007fb724904924 in sqlite3VMPrintf (db=db@entry=0x1940be0, zFormat=<optimized out>, ap=ap@entry=0x7fff376162f8) at sqlite3.c:20096 #12 0x00007fb72493e9cf in sqlite3NestedParse (pParse=pParse@entry=0x19511c0, zFormat=zFormat@entry=0x7fb724968c30 "UPDATE %Q.%s SET type='%s', name=%Q, tbl_name=%Q, rootpage=#%d, sql=%Q WHERE rowid=#%d") at sqlite3.c:81301 #13 0x00007fb72493f123 in sqlite3EndTable (pParse=pParse@entry=0x19511c0, pCons=pCons@entry=0x1951528, pEnd=pEnd@entry=0x1951548, pSelect=pSelect@entry=0x0) at sqlite3.c:82651 #14 0x00007fb72493ae34 in yy_reduce (yyruleno=32, yypParser=0x1951470) at sqlite3.c:109744 #15 sqlite3Parser (yyp=yyp@entry=0x1951470, yymajor=yymajor@entry=1, yyminor=..., pParse=pParse@entry=0x19511c0) at sqlite3.c:45379 #16 0x00007fb72493e1f2 in sqlite3RunParser (pParse=pParse@entry=0x19511c0, zSql=zSql@entry=0x7fb71d133d40 "CREATE TABLE db_info (dbversion INTEGER, checksum TEXT)", pzErrMsg=pzErrMsg@entry=0x7fff37616858) at sqlite3.c:111752 #17 0x00007fb72493fd52 in sqlite3Prepare (db=db@entry=0x1940be0, zSql=zSql@entry=0x7fb71d133d40 "CREATE TABLE db_info (dbversion INTEGER, checksum TEXT)", nBytes=nBytes@entry=-1, saveSqlFlag=saveSqlFlag@entry=0, pReprepare=pReprepare@entry=0x0, ppStmt=ppStmt@entry=0x7fff37616968, pzTail=pzTail@entry=0x7fff37616960) at sqlite3.c:94079 #18 0x00007fb72493ffb9 in sqlite3LockAndPrepare (pzTail=0x7fff37616960, ppStmt=0x7fff37616968, pOld=0x0, saveSqlFlag=0, nBytes=-1, zSql=0x7fb71d133d40 "CREATE TABLE db_info (dbversion INTEGER, checksum TEXT)", db=0x1940be0) at sqlite3.c:94171 #19 sqlite3LockAndPrepare (db=0x1940be0, zSql=0x7fb71d133d40 "CREATE TABLE db_info (dbversion INTEGER, checksum TEXT)", nBytes=-1, saveSqlFlag=0, pOld=0x0, ppStmt=0x7fff37616968, pzTail=0x7fff37616960) at sqlite3.c:28618 #20 0x00007fb724940415 in sqlite3_prepare (db=db@entry=0x1940be0, zSql=zSql@entry=0x7fb71d133d40 "CREATE TABLE db_info (dbversion INTEGER, checksum TEXT)", nBytes=nBytes@entry=-1, ppStmt=ppStmt@entry=0x7fff37616968, pzTail=pzTail@entry= 0x7fff37616960) at sqlite3.c:94234 #21 0x00007fb724946908 in sqlite3_exec (db=0x1940be0, zSql=0x7fb71d133d40 "CREATE TABLE db_info (dbversion INTEGER, checksum TEXT)", xCallback=0, pArg=0x0, pzErrMsg=0x0) at sqlite3.c:90722 #22 0x00007fb71d130f9b in yum_db_open () from /usr/lib64/python2.7/site-packages/_sqlitecache.so #23 0x00007fb71d132fc3 in ?? () from /usr/lib64/python2.7/site-packages/_sqlitecache.so #24 0x00007fb71d13336a in ?? () from /usr/lib64/python2.7/site-packages/_sqlitecache.so #25 0x00007fb72fa99c9a in PyEval_EvalFrameEx () from /lib64/libpython2.7.so.1.0 #26 0x00007fb72fa998d1 in PyEval_EvalFrameEx () from /lib64/libpython2.7.so.1.0 #27 0x00007fb72fa998d1 in PyEval_EvalFrameEx () from /lib64/libpython2.7.so.1.0 #28 0x00007fb72fa998d1 in PyEval_EvalFrameEx () from /lib64/libpython2.7.so.1.0 #29 0x00007fb72fa9a6cf in PyEval_EvalCodeEx () from /lib64/libpython2.7.so.1.0 #30 0x00007fb72fa9a7a2 in PyEval_EvalCode () from /lib64/libpython2.7.so.1.0 #31 0x00007fb72fab379a in ?? () from /lib64/libpython2.7.so.1.0 #32 0x00007fb72fab4592 in PyRun_FileExFlags () from /lib64/libpython2.7.so.1.0 #33 0x00007fb72fab4fab in PyRun_SimpleFileExFlags () from /lib64/libpython2.7.so.1.0 #34 0x00007fb72fac6051 in Py_Main () from /lib64/libpython2.7.so.1.0 #35 0x00007fb72ed0a735 in __libc_start_main () from /lib64/libc.so.6 #36 0x00000000004006f1 in _start ()
The backtrace sure looks like an sqlite bug. I'm not able to reproduce it with a basic createrepo execution here though, can you give the exact createrepo invocation you're using (in case the crash depends on some specific option or so)?
I got it to occur with just a "createrepo -d .".
Hmm, I can't reproduce it even on fully updated rawhide (previous tests were on F16). How reproducable is this crash, and does the crash actually go away if you downrev sqlite to 3.7.9 from F17?
Downgrading works. I haven't been able to get createrepo to work with 3.7.10.
Ping? I also saw crashes with fetching git repos over https inside of sqlite. Not sure what that's about (when I forget to --exclude=sqlite* next time, I'll be sure to grab backtraces for that one too).
3.7.11 has similar behavior.
See also bug 815962, probably related.
(In reply to comment #7) > See also bug 815962, probably related. I have the following set: MALLOC_CHECK_=3 for all of my shells which may be the trigger for it.
Ahh... MALLOC_CHECK_ was the missing piece of the puzzle, with that I can trivially reproduce.
Ok, should be fixed (or rather, worked around, by disabling buggy memory allocation code in sqlite >= 3.7.10 when malloc_usable_size() is detected) in sqlite-3.7.11-2.
*** Bug 815742 has been marked as a duplicate of this bug. ***
For posterity, I investigated to see if upstream are aware of this issue. I had a look through the archives of sqlite-users. The issue has been discussed once, last year. You have to sign up to the mailing list to read the archives so I'll take the liberty of reposting the mail here: On Mon, 23 Jul 2012, Richard Hipp <drh at sqlite.org> wrote: >On Mon, Jul 23, 2012 at 9:31 AM, Shlomi Fish <shlomif at shlomifish.org> wrote: >> >> I first suspected svn was the culprit, so I rebuilt it, but it still >> happened. >> Then I tried build SQLite and running its tests and I got this (below). I >> should note that svn works fine after I type "unset MALLOC_CHECK_" in the >> console (don't know about the sqlite tests). >> >> What is the underlying problem and how can it be fixed? >> > > Thanks for the report. > > As best I can tell, this appears to be a bug in MALLOC_CHECK_ in that it > does not play well with malloc_usable_size(). There does not appear to be > anything wrong with SQLite in this respect, at least as not as far as I can > see. > > We test SQLite using a variety of memory allocator that do things similar > to MALLOC_CHECK_. (See http://www.sqlite.org/testing.html#valgrind for > example.) In particular, SQLite tests run clean under valgrind. > > If you edit the "config.h" file generated by the ./configure script and > remove the HAVE_MALLOC_USABLE_SIZE define, then the resulting SQLite will > not attempt to use malloc_usable_size() and it then appears to work fine > with MALLOC_CHECK_. However, if you do this, then SQLite will increase the > size of every memory allocation by 8 bytes and store the allocation size in > those 8 bytes so that it can figure out the allocation size for itself when > it needs it, meaning that the code will run a little slower and use a > little more memory. > > -- > D. Richard Hipp > drh at sqlite.org I've not yet tried to find what the GLIBC developers have said to this, if anything.