Red Hat Bugzilla – Bug 82522
Python module causes assertion failure in python's stringobject.c
Last modified: 2014-03-16 22:33:48 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003
Description of problem:
The symptom is that when I start hwbrowser, the "searching" window pops up and
dissappears again almost instantly. I tracked it to a failure in the kudzu
python module that's used in the hwbrowser script. It causes an assertion
failure at python's Objects/stringobject.c (line 111). The assertion is "str !=
((void *)0)". The called function in stringobject.c is PyString_FromString, and
it's called from line 141 in kudzumodule.c (in addParallelInfo). I have at least
one similar report from someone else.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
I just have to start hwbrowser.
Actual Results: It aborts due to the assertion failure.
Expected Results: It shouldn't have.
This is the complete backtrace from gdb:
#0 0x42028cc1 in kill () from /lib/i686/libc.so.6
#1 0x4002f07d in raise () from /lib/i686/libpthread.so.0
#2 0x4202a019 in abort () from /lib/i686/libc.so.6
#3 0x42021cd6 in __assert_fail () from /lib/i686/libc.so.6
#4 0x0805897b in PyString_FromString ()
#5 0x409e03d8 in addParallelInfo (dict=0x836b2e4,
#6 0x409e0f0f in createDict (probedDevice=0x8357138)
#7 0x409e108b in doProbe (self=0x0, args=0x0) at
#8 0x080ceb13 in PyCFunction_Call ()
#9 0x080796bc in eval_frame ()
#10 0x0807a10e in PyEval_EvalCodeEx ()
#11 0x0807b6a4 in fast_function ()
#12 0x08079601 in eval_frame ()
#13 0x0807a10e in PyEval_EvalCodeEx ()
#14 0x0807b6a4 in fast_function ()
#15 0x08079601 in eval_frame ()
#16 0x0807a10e in PyEval_EvalCodeEx ()
#17 0x080c21bc in function_call ()
#18 0x080b1557 in PyObject_Call ()
#19 0x080b827b in instancemethod_call ()
#20 0x080b1557 in PyObject_Call ()
#21 0x080687fa in slot_tp_init ()
---Type <return> to continue, or q <return> to quit---
#22 0x08060267 in type_call ()
#23 0x080b1557 in PyObject_Call ()
#24 0x0807b975 in do_call ()
#25 0x08079583 in eval_frame ()
#26 0x0807a10e in PyEval_EvalCodeEx ()
#27 0x08077025 in PyEval_EvalCode ()
#28 0x08096a49 in run_node ()
#29 0x080959c3 in PyRun_SimpleFileExFlags ()
#30 0x0809530a in PyRun_AnyFileExFlags ()
#31 0x0805381c in Py_Main ()
#32 0x08053269 in main ()
#33 0x420158d4 in __libc_start_main () from
Created attachment 89539 [details]
patch for kudzu python module
Does the attached patch help?
Woops, make that char *str, *none = "(none)"
Created attachment 89541 [details]
new, better patch
Created attachment 89542 [details]
take three ;)
I'm not sure if it worked...
I downloaded the source for kudzu and did everything applicable. I'm really not
familiar with python, though. What I did was that I just overwrote the existing
/usr/lib/python2.2/site-packages/_kudzumodule.so (that's the filename as
indicated by /proc/?/maps) with the patched lib. It didn't change a thing,
though, and when I run it in gdb, that frame doesn't seem to be quite
synchronized with the new source, so it seems it wasn't updated anyway, which I
find strange, since I guess it should be. Is there anything more that I need to
do to make it work?
Hm, this was rebuilding with the new patch? I can attach a new module at some
point if you just want that to test.
Can you attach your /etc/sysconfig/hwconf?
Created attachment 89557 [details]
I guess you should be aware that my /etc/sysconfig/hwconf in unsync'ed with my
actual hardware, since I don't run kudzu on startup. I don't know if that could
have something with it to do.
Also, I did some (not much) extended debugging now that I have the source, and
the null string was device->pnpmodes when adding my HP laserjet 6 printer.
However, the gdb backtrace still points at line 141, which, in the patched file,
adds device->pnpmfr, which is not null. That's one of the reasons to why I think
that python doesn't seem to be using the patched lib.
Now I got it. I looked at the makefile, and apparently, _kudzumodule.so didn't
depend on kudzumodule.c, so since I had already compiled it once, it didn't
recompile after I had patched kudzumodule.c.
I recompiled it now, and it worked like a charm.
Good. It's fixed in 0.99.90 or later.