Deallocation of a pointer not malloced, any tips?
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 both 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 outside of my application 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).
Sorry if this is all very vague, I'm just a bit stumped and wanted to see if anyone had some suggestions.
-Kumar
"Kumar McMillan" kumar.mcmillan@gmail.com wrote:
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
[snip]
Sorry if this is all very vague, I'm just a bit stumped and wanted to see if anyone had some suggestions.
You may want the python-list mailing list or the equivalent comp.lang.python newsgroup, unless this is a bug with Python itself (you may try running Python 2.4.4, which is the next bugfix of the Python 2.4 series).
Regardless, you can help those who want to help you by providing the code that you have written that causes the error. A doubly nested try/except isn't all that exciting, so I would guess many would be surprised that you are getting double free errors.
- Josiah
On 4/20/07, Josiah Carlson jcarlson@uci.edu wrote:
You may want the python-list mailing list or the equivalent comp.lang.python newsgroup, unless this is a bug with Python itself (you may try running Python 2.4.4, which is the next bugfix of the Python 2.4 series).
yes, seems like it's either a bug in python or the mac os x malloc library.
Regardless, you can help those who want to help you by providing the code that you have written that causes the error. A doubly nested try/except isn't all that exciting, so I would guess many would be surprised that you are getting double free errors.
again, sorry for being vague. i tried my best at reproducing it in a test case but couldn't. However, I finally experimented with trying to force deallocation within the block of code and got something that worked!
Here is a very small portion of it, with the fix, which was putting a ref to the exc_info vars outside the tries and specifically del'ing them in the finally block:
def load_or_rescue(self, load): etype, val, tb = None, None, None try: try: try: load() except Exception, exc: etype, val, tb = sys.exc_info() if not self.rescue_load((etype, val, tb), exc): log.critical("EXCEPTION %s while processing %s", etype, self.ext_event) raise exc, None, tb except NonFatalError, e: self.handle_non_fatal_error(e) finally: del etype, val, tb
to put this in perspective a little more, the warning/crash happens when the code is getting called more or less like this...
def load(): self.start_file(fileobj) for row in self.file_reader(fileobj): self.load_or_rescue(lambda: self.load_row(row)) self.load_or_rescue(load)
On 4/24/07, Kumar McMillan kumar.mcmillan@gmail.com wrote:
Here is a very small portion of it, with the fix, which was putting a ref to the exc_info vars outside the tries and specifically del'ing them in the finally block:
Kumar,
Can you create a completely self-contained code example that triggers the problem and post a bug to Source Forge? http://sourceforge.net/projects/python
In the bug, please note the operating system version, how long this takes to trigger, the error message you see and all the steps necessary to reproduce it. Attach the code as a file, so we can download and test our the problem.
Thanks, n
Kumar> Always the same warning; sometimes it even segfaults python, but Kumar> rarely. I only see it on Mac OS X (two separate machines), python Kumar> 2.4.3 both built from source via Darwin Ports. The same suite gives no Kumar> such warning on a 2.4.3 production machine running Free BSD.
In addition to Josiah's response I will note that the warning you get is specific to the Mac's malloc implementation (or maybe more generally to Darwin or *BSD). It's not necessarily that the problem doesn't occur on other platforms, just that the malloc implementation doesn't include that sort of check by default.
Kumar> I turned on MallocHelp but just stared blankly at heaps and stack Kumar> options.
I've used that stuff but it's been awhile. Try "man malloc" in a terminal window. If that doesn't get you going post your questions pythonmac-sig@python.org mailing list. That's were most of the Mac-head Python developers hang out.
Skip
participants (4)
-
Josiah Carlson -
Kumar McMillan -
Neal Norwitz -
skip＠pobox.com