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
