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