Re: Segfault in in PyString_FromStringAndSize
James Henstridge <[email protected]>
| Newsgroups | gmane.comp.python.db.psycopg.devel |
|---|---|
| Message-ID | <[email protected]> |
On Fri, Mar 6, 2009 at 9:27 AM, Fernando M. Maresca <[email protected]> wrote: > Hi. > Sorry for start a new thread; I'd just not got my previous message > bounced from the list reflector. > > It's seems the segfault comes from the buffer Py_Malloc'd inside > utils.c psycopg_escape_string() > It's called from adapter_qstring.c qstring_quote(qstringObject *self) > function, circa :101, with the argument "to" as NULL, so the > allocation is performed inside the former, and returned to the > caller. Trying to use the returned allocated buffer produces a segfault. > > So, the pointer is inaccessible once returned from psycopg_escape_string(), > at least at some times. > > I've modified adapter_qstring.c to get a buffer allocated before > calling psycopg_escape_string() and pass it as the "to" arg instead > of NULL, so the ret value is discarded, and the same buffer is used in > the rest of the function. This *may* have corrected the segfaults, or at > least no one arose since this change. Of course, I don't know if > this is a solution or not, nor if it's really is the cause of the > problem, but looks like there is from where the segfault comes. > > I've looking inside psycopg_escape_string() before it returns (in the > original form, e.g. with to == NULL) and the allocated buffer is sane, I > can get its size and content through prinft inside this function, even > until the segfault. Hi Fernando, For these sort of bugs, I'd recommend using valgrind to track down the problem. First you'll need a test program that triggers the bug, but it sounds like you've got that already. Unfortunately, to get best results you'll probably need to compile your own Python interpreter with the --disable-pymalloc flag to configure. This is needed because valgrind doesn't know how to track allocations made by Python's special purpose memory allocator. Disabling that allocator causes Python to do standard malloc/free calls, giving useful results. [I've got a patch for Python that would do this automatically at runtime, but it hasn't been reviewed or merged yet]. You can then try something like: valgrind --tool=memcheck --log-file=valgrind.log --leak-check=full --num-callers=20 /path/to/my/python test-script.py That should produce some interesting information. James.