C-Module for Python: segmentation violation problems

[Donn Cave]

Quoth Sebastian Huber <sebastian-huber at web.de>:
| Hello,
| I write a C-module for Python. This module contains the function
| PyObject* execute( PyObject*, PyObject*) which encapsulates a call to
| another function (it uses RPC functions and XDR types) which returns a dynamically allocated C-string.
|
| If I want to free this string, I get this error:
|
| #0  0x40029d38 in pthread_mutex_lock () from /lib/libpthread.so.0
| #1  0x400d598b in free () from /lib/libc.so.6
| #2  0x402361eb in TACOPythonClient::freeOutputArgument (outputType=6, argout=0x8136628) at TACOPythonClient.h:346
...
| If I don't free the string, this arises:
|
| #0  0x400d5c53 in chunk_free () from /lib/libc.so.6
| #1  0x400d59a3 in free () from /lib/libc.so.6
| #2  0x40235dda in TACOPythonClient::freeScalar (arg=0x811d5e0) at TACOPythonClient.h:273
...
| or this:
|
| #0  0x400d520a in chunk_alloc () from /lib/libc.so.6
| #1  0x400d4f64 in malloc () from /lib/libc.so.6
| #2  0x0809bd35 in PyString_FromString ()
...
| If I free this string in a non Python module, the free works without
| any problems.  I'm absolutly clueless about the reason of that
| segmentation violations. In particular the first occurence.
| Maybe you have a hint for me.

Hint:  Py_INCREF

You need to understand what that means, include when Python's going
to do the Py_DECREF that undoes it.  I would guess that in both cases,
you free an object that has already been freed when Python decref'd
it.  If you don't free it right away, in the second example your
library code frees it, and if that doesn't cause an segmentation
violation you'll run into the damage in malloc as in the third example. 
To make this object survive longer, you need to understand the cause
of its demise, almost certainly Python reference counting.

	Donn Cave, donn at u.washington.edu