Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 82522 - Python module causes assertion failure in python's stringobject.c
Summary: Python module causes assertion failure in python's stringobject.c
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kudzu
Version: 8.0
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2003-01-23 02:46 UTC by Fredrik Tolf
Modified: 2014-03-17 02:33 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2003-01-24 01:25:01 UTC

Attachments (Terms of Use)
patch for kudzu python module (deleted)
2003-01-23 04:05 UTC, Bill Nottingham
no flags Details | Diff
new, better patch (deleted)
2003-01-23 04:31 UTC, Bill Nottingham
no flags Details | Diff
take three ;) (deleted)
2003-01-23 04:33 UTC, Bill Nottingham
no flags Details | Diff
/etc/sysconfig/hwconf (deleted)
2003-01-24 01:00 UTC, Fredrik Tolf
no flags Details

Description Fredrik Tolf 2003-01-23 02:46:23 UTC
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:

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/
#1  0x4002f07d in raise () from /lib/i686/
#2  0x4202a019 in abort () from /lib/i686/
#3  0x42021cd6 in __assert_fail () from /lib/i686/
#4  0x0805897b in PyString_FromString ()
#5  0x409e03d8 in addParallelInfo (dict=0x836b2e4,
    at kudzumodule.c:141
#6  0x409e0f0f in createDict (probedDevice=0x8357138)
at kudzumodule.c:319
#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

Comment 1 Bill Nottingham 2003-01-23 04:05:21 UTC
Created attachment 89539 [details]
patch for kudzu python module

Comment 2 Bill Nottingham 2003-01-23 04:05:42 UTC
Does the attached patch help?

Comment 3 Bill Nottingham 2003-01-23 04:30:41 UTC
Woops, make that char *str, *none = "(none)"

Comment 4 Bill Nottingham 2003-01-23 04:31:54 UTC
Created attachment 89541 [details]
new, better patch

Comment 5 Bill Nottingham 2003-01-23 04:33:36 UTC
Created attachment 89542 [details]
take three ;)

Comment 6 Fredrik Tolf 2003-01-23 23:48:10 UTC
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/ (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?

Comment 7 Bill Nottingham 2003-01-24 00:48:07 UTC
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?

Comment 8 Fredrik Tolf 2003-01-24 01:00:18 UTC
Created attachment 89557 [details]

Comment 9 Fredrik Tolf 2003-01-24 01:05:55 UTC
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.

Comment 10 Fredrik Tolf 2003-01-24 01:13:59 UTC
Now I got it. I looked at the makefile, and apparently, 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.

Comment 11 Bill Nottingham 2003-01-24 01:25:01 UTC
Good. It's fixed in 0.99.90 or later.

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