Jorge wrote:
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!
If you give the a_UIcmd_set_page_prog() Cache_data(entry)->len, does the problem go away?