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... Please help us, it's important to stabilize this branch before merging into main. -- BTW, after we merge CSS into the main branch, it seems like floating objects will be the highest priority. Dillo rendering would improve a lot by using both! -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________
Jorge wrote:
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...
Please help us, it's important to stabilize this branch before merging into main.
And it doesn't happen with main?
On Mon, Jan 05, 2009 at 07:26:12PM +0000, corvid wrote:
Jorge wrote:
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...
Please help us, it's important to stabilize this branch before merging into main.
And it doesn't happen with main?
Yes, main works OK. -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________
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. I don't really now how to fix that though... Cheers, Johannes
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 ______________________________________________________________________
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?
Jorge wrote:
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.
Now that I see 48029b8a5478, I'm curious about it: Is there an unref missing somewhere that caused UTF8Data to need to be freed in those cases?
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.
I don't really now how to fix that though...
Good news: now I have a big cleanup patch that gets rid of every valgrind complain on that page! jcid@d620:~/C/Dillo/d2/dillo-css-wc2/src$ diffstat try2.diff cache.c | 157 ++++++++++++++++++++++++++++------------------------------------ cache.h | 3 - capi.c | 5 -- capi.h | 3 - html.cc | 22 ++++++-- 5 files changed, 89 insertions(+), 101 deletions(-) Let me polish it a bit more before you review and test it. -- Cheers Jorge.-
On Wed, Jan 07, 2009 at 01:19:38PM -0300, Jorge Arellano Cid wrote:
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.
I don't really now how to fix that though...
Good news: now I have a big cleanup patch that gets rid of every valgrind complain on that page!
jcid@d620:~/C/Dillo/d2/dillo-css-wc2/src$ diffstat try2.diff cache.c | 157 ++++++++++++++++++++++++++++------------------------------------ cache.h | 3 - capi.c | 5 -- capi.h | 3 - html.cc | 22 ++++++-- 5 files changed, 89 insertions(+), 101 deletions(-)
Let me polish it a bit more before you review and test it.
Here go the patches attached. For test, review & commments. Please apply styleengine-init-values first. -- Cheers Jorge.-
The purpose of "force" was for users setting content type (or at least character encoding) through a dialog or menu or whatever.
Hi Jorge, On Wed, Jan 07, 2009 at 03:56:55PM -0300, Jorge Arellano Cid wrote:
On Wed, Jan 07, 2009 at 01:19:38PM -0300, Jorge Arellano Cid wrote:
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.
I don't really now how to fix that though...
Good news: now I have a big cleanup patch that gets rid of every valgrind complain on that page!
jcid@d620:~/C/Dillo/d2/dillo-css-wc2/src$ diffstat try2.diff cache.c | 157 ++++++++++++++++++++++++++++------------------------------------ cache.h | 3 - capi.c | 5 -- capi.h | 3 - html.cc | 22 ++++++-- 5 files changed, 89 insertions(+), 101 deletions(-)
Let me polish it a bit more before you review and test it.
Here go the patches attached. For test, review & commments. Please apply styleengine-init-values first.
This patch fixes these crashes for me. I think we should reintroduce the force parameter given corvid's comment. Thanks, Johannes
On Wed, Jan 07, 2009 at 09:07:19PM +0100, Johannes Hofmann wrote:
Hi Jorge,
On Wed, Jan 07, 2009 at 03:56:55PM -0300, Jorge Arellano Cid wrote:
On Wed, Jan 07, 2009 at 01:19:38PM -0300, Jorge Arellano Cid wrote:
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.
I don't really now how to fix that though...
Good news: now I have a big cleanup patch that gets rid of every valgrind complain on that page!
jcid@d620:~/C/Dillo/d2/dillo-css-wc2/src$ diffstat try2.diff cache.c | 157 ++++++++++++++++++++++++++++------------------------------------ cache.h | 3 - capi.c | 5 -- capi.h | 3 - html.cc | 22 ++++++-- 5 files changed, 89 insertions(+), 101 deletions(-)
Let me polish it a bit more before you review and test it.
Here go the patches attached. For test, review & commments. Please apply styleengine-init-values first.
This patch fixes these crashes for me. I think we should reintroduce the force parameter given corvid's comment.
Yes, sure. It was stripped because it wasn't used. Good to know it works! -- Cheers Jorge.-
participants (3)
-
corvid＠lavabit.com -
jcid＠dillo.org -
Johannes.Hofmann＠gmx.de