Bug 173367 - seqfault message during "Reading repository metadata in from local files"
seqfault message during "Reading repository metadata in from local files"
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: yum (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jeremy Katz
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-11-16 12:06 EST by Jef Spaleta
Modified: 2014-01-21 17:53 EST (History)
1 user (show)

See Also:
Fixed In Version: FC5
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-04-19 16:51:34 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 Jef Spaleta 2005-11-16 12:06:13 EST
Description of problem:
I'm getting an actual segfault during yum operation. It's not 100% reproducable
but it's happening repeatably during the metadata prep stage of yum operation.
I'm not sure how to report it, so I'm reporting it against yum. It's been
suggested in #fedora-devel that that might be some python binding refcounting
madness that is going on, but I sure has hell don't know enough to be able to
narrow this down further on my own.  I can't seem to get a segfault beyond a
certain point in the yum process. If the segfault occurs it occurs in the
"Reading repository metadata in from local files" step. 


Here is a procedure that works about half the time to produce a segfault message.
<clean old metadata cache files to ensure rebuilding of dbcache>
yum clean dbcache
yum clean cache

<attempt a yum command>
yum list HelixPlayer

Setting up repositories
development               100% |=========================| 1.1 kB    00:00
extras-development        100% |=========================| 1.1 kB    00:00
Reading repository metadata in from local files
developmen: #                                                 
152/4212Segmentation fault


yum makecache
Making cache files for all metadata files.
This may take a while depending on the speed of this computer
Setting up repositories
development               100% |=========================| 1.1 kB    00:00
extras-development        100% |=========================| 1.1 kB    00:00
developmen: ###########################################       
3636/4212Segmentation fault

Running with yum -d6 doesn't provide anything useful leading up to the seg message
...
extras-development        100% |=========================| 1.1 kB    00:00
primary.xml.gz            100% |=========================| 1.2 MB    00:05
primary sqlite cache needs updating, reading in metadata
developmen: ################################                  
2705/4212Segmentation fault


The exact moment in the prep where the seg occurs changes. Sometimes it makes it
through development and fails on extras-development. Sometimes it makes it
through completely.

If there is anything specific I should attempt to narrow down the problem, I'll
gladly report back.

-jef

Version-Release number of selected component (if applicable):
yum-2.4.0-13
python-2.4.1-16
python-sqlite-1.1.6-1
python-elementtree-1.2.6-4
Comment 1 Jeremy Katz 2005-11-16 14:04:37 EST
Can you try running ulimit -c unlimited before running yum -- that should then
give you a core file that you can get a backtrace from
Comment 2 Jef Spaleta 2005-11-16 15:46:35 EST
after getting the rpm,glibc and python debuginfo packages installed.. looks to
my unexpert eye like i'm probably suffering from busted memory since the
backtrace seems to be saying i'm failing on a malloc.

Here's the backtrace from the core generated using yum check-update
>gdb python core.21475
...
(gdb) thread apply all bt
Thread 1 (process 21475):
#0  0x00443d13 in _int_malloc () from /lib/libc.so.6
#1  0x00444cef in malloc () from /lib/libc.so.6
#2  0x0059cbcf in sqlite3Malloc () from /usr/lib/libsqlite3.so.0
#3  0x0058c4d6 in sqlite3ParserAlloc () from /usr/lib/libsqlite3.so.0
#4  0x00599ffd in sqlite3RunParser () from /usr/lib/libsqlite3.so.0
#5  0x005914d3 in sqlite3_prepare () from /usr/lib/libsqlite3.so.0
#6  0x00a12268 in sqlite_exec_callback ()
   from /usr/lib/python2.4/site-packages/_sqlite.so
#7  0x00a13763 in sqlite_exec_callback ()
   from /usr/lib/python2.4/site-packages/_sqlite.so
#8  0x006917c3 in PyCFunction_Call () from /usr/lib/libpython2.4.so.1.0
#9  0x006caa53 in PyEval_EvalFrame () from /usr/lib/libpython2.4.so.1.0
#10 0x006cb8d8 in PyEval_EvalCodeEx () from /usr/lib/libpython2.4.so.1.0


-jef
Comment 3 Jeremy Katz 2005-11-16 15:50:29 EST
Or a corrupted cache causing a malloc of way too big.  Can you try moving any
sqlite caches (find /var/cache/yum -name '*.sqlite') out of the way and see if
it still happens?
Comment 4 Jef Spaleta 2005-11-16 16:05:19 EST
I've gone as far as as to obliterate the /var/cache/yum/  directory completely
and recreate an empty one.  still get the segfaults on the metadata processins.

What's very odd to me, is that I'm not getting segfaults from other parts of the
yum process or from other intensive operations not even package rebuilding which
I would have though would reveal memory problems more consistently.

Its only happening with the sqlite manipulation when there is new metadata to
process.

-jef
Comment 5 Jeremy Katz 2006-04-19 16:21:35 EDT
Jef -- are you still seeing this at all?  I'm thinking it was probably a bug in
sqlite at one point that's since gone away.
Comment 6 Jef Spaleta 2006-04-19 16:31:49 EDT
I don't think I'm seeing it anymore.. which means if I'm seeing its far less
common an event than it was when I was originally reported it. If its happening
still its much rarer than mirror sync issues which have me run off the end of
the mirrorlist.

-jef

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