Bug 173367
| Summary: | seqfault message during "Reading repository metadata in from local files" | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Jef Spaleta <jspaleta> |
| Component: | yum | Assignee: | Jeremy Katz <katzj> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | rawhide | CC: | katzj |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | FC5 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2006-04-19 20:51:34 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Jef Spaleta
2005-11-16 17:06:13 UTC
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 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
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? 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 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. 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 |