On 4/20/07, Josiah Carlson <[EMAIL PROTECTED]> 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) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com