I am logging the creation and destruction of DilloImage structures (patches attached) and I have confirmed that sometimes the image callbacks run after the Image is freed. Here's a typical example: $ grep '^Image: 0x4687db8: ' ../../Log/log_2009-04-25_21-48-48.txt Image: 0x4687db8: new Image: 0x4687db8: ref: a_Jpeg_callback Image: 0x4687db8: free Image: 0x4687db8: ref: a_Jpeg_callback Image: 0x4687db8: ref: a_Jpeg_callback So how can I track down this race condition? Regards, Jeremy Henty PS: I am still running corvid's img-ref patch (also attached for reference).
On Sun, Apr 26, 2009 at 08:56:15AM +0100, Jeremy Henty wrote:
I am logging the creation and destruction of DilloImage structures (patches attached) and I have confirmed that sometimes the image callbacks run after the Image is freed. Here's a typical example:
$ grep '^Image: 0x4687db8: ' ../../Log/log_2009-04-25_21-48-48.txt Image: 0x4687db8: new Image: 0x4687db8: ref: a_Jpeg_callback Image: 0x4687db8: free Image: 0x4687db8: ref: a_Jpeg_callback Image: 0x4687db8: ref: a_Jpeg_callback
This might make sense: DilloJpeg sometimes outlives the corresponding DilloImage. If the a_Jpeg_callback is called and it accesses the pointer to DilloImage we get the invalid reads, and if there is no callback anymore we have the leak. Cheers, Johannes
On Sun, Apr 26, 2009 at 11:23:07AM +0200, Hofmann Johannes wrote:
On Sun, Apr 26, 2009 at 08:56:15AM +0100, Jeremy Henty wrote:
I am logging the creation and destruction of DilloImage structures (patches attached) and I have confirmed that sometimes the image callbacks run after the Image is freed.
This might make sense:
DilloJpeg sometimes outlives the corresponding DilloImage. If the a_Jpeg_callback is called and it accesses the pointer to DilloImage we get the invalid reads, and if there is no callback anymore we have the leak.
OK, I'll try tracing the Dillo{Png,Jpeg,Gif} structures too. Regards, Jeremy Henty
participants (2)
-
Johannes.Hofmann＠gmx.de -
onepoint＠starurchin.org