Bug 82522 - Python module causes assertion failure in python's stringobject.c
Summary: Python module causes assertion failure in python's stringobject.c
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kudzu
Version: 8.0
Hardware: i386
OS: Linux
medium
high
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact: David Lawrence
URL:
Whiteboard:
Depends On:
Blocks:
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:
Environment:
Last Closed: 2003-01-24 01:25:01 UTC


Attachments (Terms of Use)
patch for kudzu python module (1.35 KB, patch)
2003-01-23 04:05 UTC, Bill Nottingham
no flags Details | Diff
new, better patch (1.35 KB, patch)
2003-01-23 04:31 UTC, Bill Nottingham
no flags Details | Diff
take three ;) (1.39 KB, patch)
2003-01-23 04:33 UTC, Bill Nottingham
no flags Details | Diff
/etc/sysconfig/hwconf (4.12 KB, text/plain)
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:
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

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/_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?

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]
/etc/sysconfig/hwconf

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, _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.

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.