On Tue, Jan 06, 2009 at 01:37:10PM +0100, Johannes Hofmann wrote:
On Mon, Jan 05, 2009 at 02:51:03PM -0300, Jorge Arellano Cid wrote:
Hi there,
With Johannes, we're trying to find out why valgrind complains on the newest CSS branch with a certain URL:
$ valgrind --tool=memcheck --leak-check=yes \ ./dillo http://selenic.com/pipermail/mercurial/ &>out
$ less out
There're several "Invalid read of size 1".
It doesn't complain with a local file, nor after repush. It seems the timing is important, and maybe the decoder...
The problem seems to be that at cache.c:1149 data is assigned entry->UTF8Data, then during Html_callback() a_Cache_set_content_type() get's called which since revision 48029b8a5478 frees entry->UTF8Data. That also explains why the earlier read of start went ok.
Good catch! I made those changes (48029b8a5478) not knowing exactly how the whole process goes. What I don't understand now is: * The Hg CSS repo from freehg (tip: f9099e82be08) has the problem, but it doesn't have the "Free UTF8Data" patch (48029b8a5478). Anyway, it seems the bug is related to setting the new decoder. As a matter of fact, the main branch of dillo doesn't show the same problem, but it *has* a problem: Nav_open_url: new url='http://selenic.com/pipermail/mercurial/' Dns_server [0]: selenic.com is 66.93.16.53 Connecting to 66.93.16.53 ==29247== Invalid read of size 4 ==29247== at 0x8061926: Cache_process_queue (cache.c:1151) ==29247== by 0x8061232: a_Cache_process_dbuf (cache.c:900) ==29247== by 0x80645C8: a_Capi_ccc (capi.c:597) ==29247== by 0x805D30B: a_Chain_fcb (chain.c:112) ==29247== by 0x8081760: Dpi_parse_token (dpi.c:219) ==29247== by 0x80819E8: Dpi_process_dbuf (dpi.c:278) ==29247== by 0x808290A: a_Dpi_ccc (dpi.c:668) ==29247== by 0x805D30B: a_Chain_fcb (chain.c:112) ==29247== by 0x8083668: a_IO_ccc (IO.c:414) ==29247== by 0x8083041: IO_read (IO.c:201) ==29247== by 0x808319D: IO_callback (IO.c:266) ==29247== by 0x808321E: IO_fd_read_cb (IO.c:287) ==29247== Address 0x480644c is 4 bytes inside a block of size 12 free'd ==29247== at 0x4024B4A: free (vg_replace_malloc.c:323) ==29247== by 0x807E466: dFree (dlib.c:60) ==29247== by 0x807EAA4: dStr_free (dlib.c:293) ==29247== by 0x8060381: a_Cache_set_content_type (cache.c:513) ==29247== by 0x8063F13: a_Capi_set_content_type (capi.c:427) ==29247== by 0x806DF45: _ZL18Html_tag_open_metaP9DilloHtmlPKci (html.cc:3020) ==29247== by 0x806D2E6: _ZL16Html_process_tagP9DilloHtmlPci (html.cc:3538) ==29247== by 0x806D970: _ZL14Html_write_rawP9DilloHtmlPcii (html.cc:3876) ==29247== by 0x806DAEC: DilloHtml::write(char*, int, int) (html.cc:667) ==29247== by 0x806DB7F: _ZL13Html_callbackiP12_CacheClient (html.cc:3767) ==29247== by 0x8061915: Cache_process_queue (cache.c:1149) ==29247== by 0x8061232: a_Cache_process_dbuf (cache.c:900) Nav_open_url: new url='http://selenic.com/pipermail/mercurial/' a_Nav_expect_done: repush! Well, so far I managed to get rid of the complain in my local CSS tree, by changing the way the decoder is engaged, but I want to understand it better before sharing it. There's also a segfault I have to chase...
I don't really now how to fix that though...
I assume backing out 48029b8a5478 doesn't make it... -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________