Hi,

I also wonder about the performance cost of a recursive lock.

I am still unable to reproduce the bug in a simple script. Looking
closely to the gdb stack, there is that frame:
Frame 0x13be190, for file /usr/lib/python2.6/multiprocessing/heap.py, line 173
I understand that python reuses only the beginning of a memory block,
so it frees the remaining of the block.
I use both Value(c_int) and Value(c_double), which have different
sizes. That may explain that behaviour.

in heap.py, in the malloc function:
    167         self._lock.acquire()
    168         try:
    169             size = self._roundup(max(size,1), self._alignment)
    170             (arena, start, stop) = self._malloc(size)
    171             new_stop = start + size
    172             if new_stop < stop:
    173                 self._free((arena, new_stop, stop))

Thanks for your help

2011/6/21 Charles-François Natali <report@bugs.python.org>:
>
> Charles-François Natali <neologix@free.fr> added the comment:
>
>> The obvious solution is to use a recursive lock instead.
>
> Note that it's not really a solution, just a workaround to avoid
> deadlocks, become this might lead to a corruption if free is called
> while the heap is in an inconsistent state. I have to think some more
> about a final solution, but I'd like to check first that this is
> really what's happening here.
>
> ----------
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue12352>
> _______________________________________
>