This program makes Python segfault - no other does

Tim Peters tim.one at comcast.net
Mon May 17 22:27:57 EDT 2004


...
>> There may or may not be other C bugs here, but for starters change the
>> last line to
>>
>>     sout = (char *)PyMem_Malloc(slen + 1);

[Juho Saarikko]
> YES ! It works !

That's only because it was broken <wink>.  Really, that's a common C coding
error when working with C strings.

> After making this change and recompiling the module, the segfaults
> stopped. Thank you, you saved me days of work. I'll send the
> fix to the pyPgSQL project.

>From Michael's posts, it sounds like they already fixed this in their CVS.

>> BTW, running under a debug-build Python would have told you that the
>> program wrote beyond the bounds of the memory allocated for sout.

> It didn't. But, as I said, it was the first time I tried using a debugger.
> And I only read enough instructions to figure out how to get a stack
> trace.

No, "running under a debug-build Python" != "using a debugger".  A
debug-build Python requires compiling Python itself in a different way, and
a debug-build Python (among other things) wraps malloc() and free() with
special, more-expensive code that checks for over- and under-writes.  I'll
repeat that it would have caught the overwrite in this case:  it would have.
Everyone writing Python extension modules in C should learn how to build and
run them, and Python, in debug mode -- it will, over time, save them
literally months.  The Python core is routinely built and tested in debug
mode.  That's a large part of why the kind of segfault you saw here almost
never gets blamed on core Python code.






More information about the Python-list mailing list