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): How reproducible: Always Steps to Reproduce: I just have to start hwbrowser. Actual Results: It aborts due to the assertion failure. Expected Results: It shouldn't have. Additional info: 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, device=0x40035e20) at kudzumodule.c:141 #6 0x409e0f0f in createDict (probedDevice=0x8357138) at kudzumodule.c:319 #7 0x409e108b in doProbe (self=0x0, args=0x0) at kudzumodule.c:362 #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 /lib/i686/libc.so.6
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] /etc/sysconfig/hwconf
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.