BUG: CCC corrupts memory when the Content-Type is wrong
I am hoping that someone who understands Dillo's CCC better than I can point me in the right direction and save me some time debugging this. Dillo almost always crashes if the HTML contains the stumbleupon.com favicon link, ie.'<img src="http://www.stumbleupon.com/favicon.ico">'. (This is very annoying as it makes Dillo unusable for one of my favourite blogs.) If it doesn't crash right away then clicking Reload crashes it. Examining core dumps with gdb suggests that memory is being corrupted, and running dillo under valgrind shows that the CCC functions are reading, writing and freeing already freed memory. (Details attached.) A local HTTP server triggers the bug when it server returns a Content-Type of "text/plain; charset=iso-8859-1". If I change it to "image/x-icon" there is no corruption. Accessing the image directly via a "file:" URL does not trigger the bug. (Strangely, using a local HTTP server does not hit the bug until I open a second window on the page, although sometimes it crashes first time.) I'm attaching a summary of the invalid memory accesses that valgrind reported, and the entire valgrind log (which includes stack traces). Any suggestions for where I should start instrumenting the CCC to find out why it is prematurely freeing pointers? Jeremy Henty
Heh, I sent the valgrind logs separately but they were so large they were held for moderation. This is just the summarised version. It lists the freed blocks that were accessed and the sequence of invalid accesses. It's clear that the CCC is accessing pointers after freeing them. Jeremy Henty Freed blocks: [1]: 0x4AB7910:(IOData_t *), freed by a_IO_ccc (IO.c:385) [2]: 0x4AB78C0:(ChainLink *Info), freed by a_IO_ccc (IO.c:386) [3]: 0x4AB5768:(ChainLink *Info), freed by a_Dpi_ccc (dpi.c:696) [4]: 0x4AB5718:(ChainLink *Info), freed by a_Capi_ccc (capi.c:536) [5]: 0x4AACE10:(capi_conn_t *), freed by a_Capi_ccc (capi.c:535) [6]: 0x4AACE68:(DilloUrl *), freed by a_Capi_ccc (capi.c:535) [7]: 0x4AB57B8:(dpi_conn_t *), freed by a_Dpi_ccc (dpi.c:695) [8]: 0x4AB5818:(Dstr *), freed by a_Dpi_ccc (dpi.c:695) [9]: 0x4AB5858:(Dstr_char_t *), freed by a_Dpi_ccc (dpi.c:672) [10]: 0x4AB7960:(Dstr *ds), freed by a_IO_ccc (IO.c:385) [11]: 0x4AB79A0:(Dstr_char_t *), freed by a_IO_ccc (IO.c:385) [1] read at IO_read (IO.c:194) [2] read at a_IO_ccc (IO.c:402) (many times) [3] read at a_IO_ccc (IO.c:402) (many times) [4] read at a_Capi_ccc (capi.c:569) [5] write at a_Capi_ccc (capi.c:570) [5] read at a_Capi_ccc (capi.c:572) [6] read at a_Url_cmp (url.c:442) [5] read at a_Capi_ccc (capi.c:574) [5] read at Capi_conn_unref (capi.c:132) (twice) [4] freed by a_Capi_ccc (capi.c:579) [3] read at a_Dpi_ccc (dpi.c:672) [7] read at Dpi_conn_free (dpi.c:124) [7] read at Dpi_conn_free (dpi.c:125) [8] read at dStr_free (dlib.c:291) [8] read at dStr_free (dlib.c:292) [9] freed by a_Dpi_ccc (dpi.c:672) [8] freed by a_Dpi_ccc (dpi.c:672) [7] freed by a_Dpi_ccc (dpi.c:672) [3] freed by a_Dpi_ccc (dpi.c:673) [1] read at IO_read (IO.c:194) (many times) [10] read at dStr_free (dlib.c:291) [1] read at dStr_free (dlib.c:292) [11] freed by a_IO_ccc (IO.c:404) [10] freed by a_IO_ccc (IO.c:404) [1] freed by a_IO_ccc (IO.c:404) [2] freed by a_IO_ccc (IO.c:405)
Hi Jeremy, On Tue, Dec 04, 2007 at 02:03:07PM +0000, Jeremy Henty wrote:
I am hoping that someone who understands Dillo's CCC better than I can point me in the right direction and save me some time debugging this.
Well, ehmmmm, I know CCC, but this was a hard-to-find bug!
Dillo almost always crashes if the HTML contains the stumbleupon.com favicon link, ie.'<img src="http://www.stumbleupon.com/favicon.ico">'. (This is very annoying as it makes Dillo unusable for one of my favourite blogs.) If it doesn't crash right away then clicking Reload crashes it.
Examining core dumps with gdb suggests that memory is being corrupted, and running dillo under valgrind shows that the CCC functions are reading, writing and freeing already freed memory. (Details attached.)
A local HTTP server triggers the bug when it server returns a Content-Type of "text/plain; charset=iso-8859-1". If I change it to "image/x-icon" there is no corruption. Accessing the image directly via a "file:" URL does not trigger the bug. (Strangely, using a local HTTP server does not hit the bug until I open a second window on the page, although sometimes it crashes first time.)
I'm attaching a summary of the invalid memory accesses that valgrind reported, and the entire valgrind log (which includes stack traces).
Any suggestions for where I should start instrumenting the CCC to find out why it is prematurely freeing pointers?
The problem is reentrancy. The CCC handles parallelism and serves to propagate operations in a managed environment. This bug was produced because a CCC operation was reentering the same chain after it was aborted. I added an extra check as a workaround to avoid this situation and a comment that a more generic solution should be designed. Patch is in CVS. Please test and comment. Hopefully it will work. ;-) -- Cheers Jorge.-
On Wed, Dec 05, 2007 at 12:34:18PM -0300, Jorge Arellano Cid wrote:
The problem is reentrancy.
Aha! I did some testing and noticed that calls to a_IO_ccc were sometimes nested.
This bug was produced because a CCC operation was reentering the same chain after it was aborted. I added an extra check as a workaround to avoid this situation and a comment that a more generic solution should be designed.
Hmm, perhaps the CCC Chainlink structures could have an aborted flag and the chaining functions could call the callbacks only if the link was not aborted? Also, I noticed that a_Chain_unlink is never used. Is that intentional?
Patch is in CVS.
Problem solved. Yay! Regards, Jeremy Henty
On Wed, Dec 05, 2007 at 06:18:22PM +0000, Jeremy Henty wrote:
On Wed, Dec 05, 2007 at 12:34:18PM -0300, Jorge Arellano Cid wrote:
The problem is reentrancy.
Aha! I did some testing and noticed that calls to a_IO_ccc were sometimes nested.
This bug was produced because a CCC operation was reentering the same chain after it was aborted. I added an extra check as a workaround to avoid this situation and a comment that a more generic solution should be designed.
Hmm, perhaps the CCC Chainlink structures could have an aborted flag and the chaining functions could call the callbacks only if the link was not aborted?
Yes. I gave that idea a quick try and realized I had to decide better whether to allow some reentrancy, why/when and how, and also to check if that was already happening...
Also, I noticed that a_Chain_unlink is never used. Is that intentional?
It's just an API idea. -- Cheers Jorge.-
participants (2)
-
jcid＠dillo.org -
onepoint＠starurchin.org