createrepo-0.4.6 creates defective metadata if filesystem is full
Hans-Peter Jansen <[email protected]>
| Newsgroups | gmane.linux.rpm.metadata |
|---|---|
| Message-ID | <[email protected]> |
Hi, just wanted to let you know, that in case of a full filesystem, createrepo creates defective repodata without any error indication, finally leading to segfaults in yum. Here's a related backtrace: devel-tools 100% |=========================| 951 B 00:00 devel-tool: ############# 31/119 Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1211885888 (LWP 22227)] 0xb7cad5c1 in strlen () from /lib/libc.so.6 (gdb) bt #0 0xb7cad5c1 in strlen () from /lib/libc.so.6 #1 0xb741bc01 in g_string_chunk_insert_len () from /opt/gnome/lib/libglib-2.0.so.0 #2 0xb741bc70 in g_string_chunk_insert () from /opt/gnome/lib/libglib-2.0.so.0 #3 0xb74894ec in init_sqlitecache () from /usr/lib/python2.5/site-packages/_sqlitecache.so #4 0xb7485933 in package_new () from /usr/lib/python2.5/site-packages/_sqlitecache.so #5 0xb72d0322 in xmlParseXMLDecl () from /usr/lib/libxml2.so.2 #6 0xb72de12a in xmlParseElement () from /usr/lib/libxml2.so.2 #7 0xb72d9fe5 in xmlParseContent () from /usr/lib/libxml2.so.2 #8 0xb72de0c4 in xmlParseElement () from /usr/lib/libxml2.so.2 #9 0xb72de4d8 in xmlParseDocument () from /usr/lib/libxml2.so.2 #10 0xb72df0bb in xmlSAXUserParseFile () from /usr/lib/libxml2.so.2 #11 0xb74869ce in yum_xml_parse_primary () from /usr/lib/python2.5/site-packages/_sqlitecache.so #12 0xb748911e in init_sqlitecache () from /usr/lib/python2.5/site-packages/_sqlitecache.so #13 0xb74893d8 in init_sqlitecache () from /usr/lib/python2.5/site-packages/_sqlitecache.so #14 0xb7e07ddd in PyCFunction_Call () from /usr/lib/libpython2.5.so.1.0 #15 0xb7e502bf in PyEval_EvalFrameEx () from /usr/lib/libpython2.5.so.1.0 #16 0xb7e5008b in PyEval_EvalFrameEx () from /usr/lib/libpython2.5.so.1.0 #17 0xb7e51734 in PyEval_EvalCodeEx () from /usr/lib/libpython2.5.so.1.0 I haven't investigated deeply, since the whole process of generating such defective output should be suppressed somehow (by removing the offending files in the FS full case), and let yum simply bail out instead of just crash, when accessing such a repo. Well, I know, this message is missing the corrective patch, but "doing the whole druidic festival around the tree thing"¹ has higher precedence ATM.. Pete ¹) stolen from Linus announcing 2.6.24-rc6 on LKML