K
Kumar McMillan
I get this warning from my test suite when I introduced a segment of code:
python(18603,0xa000d000) malloc: *** Deallocation of a pointer not
malloced: 0x310caa3; This could be a double free(), or free() called
with the middle of an allocated block; Try setting environment
variable MallocHelp to see tools to help debug
Always the same warning; sometimes it even segfaults python, but
rarely. I only see it on Mac OS X (two separate machines), python
2.4.3 built from source via Darwin Ports. The same suite gives no
such warning on a 2.4.3 production machine running Free BSD.
I know what segment of code causes it but can't for the life of me
think of writing it a different way in this specific application. In
a nutshell, it's two sets of two nested try blocks (try, try, except,
except * 2) where the inner except can re-raise a new exception if a
rescue function wants to. it sounds convoluted because it is!
I
tried really hard recreating it in a test case but of course there is
something too deeply buried that I can't catch.
I turned on MallocHelp but just stared blankly at heaps and stack
options. Is there anything I can switch on that would be helpful to
anyone who might be interested in this problem? I also wanted to
put out some feelers in case it sounds like something that is fixed
elsewhere (I'm having trouble running my existing suite in 2.5 due to
setuptools not working and me not having enough time to fiddle with
it).
-Kumar
python(18603,0xa000d000) malloc: *** Deallocation of a pointer not
malloced: 0x310caa3; This could be a double free(), or free() called
with the middle of an allocated block; Try setting environment
variable MallocHelp to see tools to help debug
Always the same warning; sometimes it even segfaults python, but
rarely. I only see it on Mac OS X (two separate machines), python
2.4.3 built from source via Darwin Ports. The same suite gives no
such warning on a 2.4.3 production machine running Free BSD.
I know what segment of code causes it but can't for the life of me
think of writing it a different way in this specific application. In
a nutshell, it's two sets of two nested try blocks (try, try, except,
except * 2) where the inner except can re-raise a new exception if a
rescue function wants to. it sounds convoluted because it is!
Itried really hard recreating it in a test case but of course there is
something too deeply buried that I can't catch.
I turned on MallocHelp but just stared blankly at heaps and stack
options. Is there anything I can switch on that would be helpful to
anyone who might be interested in this problem?
I also wanted toput out some feelers in case it sounds like something that is fixed
elsewhere (I'm having trouble running my existing suite in 2.5 due to
setuptools not working and me not having enough time to fiddle with
it).
-Kumar