- Dillo-dev - lists.mailman3.com

one more crash

by Johannes.Hofmann＠gmx.de

Sorry, but I'm seeing one more crash with current css-prototype. I think it has to do with abdae95b1c9e. I get it often - but not always e.g. on www.spiegel.de. Somehow layout is not set properly in the Image widget. Below is the stack. Cheers, Johannes Program terminated with signal 11, Segmentation fault. #0 0x08073f8e in dw::core::Layout::createImgbuf (this=0x3, type=dw::core::Imgbuf::RGB, width=140, height=80) at ../dw/layout.hh:241 241 return platform->createImgbuf (type, width, height); (gdb) bt #0 0x08073f8e in dw::core::Layout::createImgbuf (this=0x3, type=dw::core::Imgbuf::RGB, width=140, height=80) at ../dw/layout.hh:241 #1 0x0805f016 in a_Dicache_set_parms (url=0x28fa2a00, version=1, Image=0x2952d040, width=140, height=80, type=DILLO_IMG_TYPE_RGB) at dicache.c:268 #2 0x08072f2e in Jpeg_write (jpeg=0x28f85000, Buf=0x28f97000, BufSize=8000) at jpeg.c:299 #3 0x08072df4 in Jpeg_callback (Op=0, Client=0x297b4e20) at jpeg.c:246 #4 0x0805f407 in a_Dicache_callback (Op=0, Client=0x297b4e20) at dicache.c:396 #5 0x0805de7a in Cache_process_queue (entry=0x2952d080) at cache.c:1134 #6 0x0805d624 in a_Cache_process_dbuf (Op=0, buf=0x2955d000 "Z121\034\002\n", buf_size=7930, Url=0x2952d200) at cache.c:856 #7 0x08060af9 in a_Capi_ccc (Op=2, Branch=2, Dir=1, Info=0x294d6b40, Data1=0x286bb5b0, Data2=0x80fb16c) at capi.c:596 #8 0x08059f38 in a_Chain_fcb (Op=2, Info=0x294d6740, Data1=0x286bb5b0, Data2=0x80fb16c) at chain.c:112 #9 0x080794d2 in Dpi_parse_token (conn=0x2952d240) at dpi.c:219 #10 0x080797b2 in Dpi_process_dbuf (Op=0, Data1=0x286bbca0, conn=0x2952d240) at dpi.c:278 #11 0x0807a545 in a_Dpi_ccc (Op=2, Branch=2, Dir=1, Info=0x294d6740, Data1=0x286bbca0, Data2=0x0) at dpi.c:668 #12 0x08059f38 in a_Chain_fcb (Op=2, Info=0x294d6fa0, Data1=0x286bbca0, Data2=0x0) at chain.c:112 #13 0x0807b197 in a_IO_ccc (Op=2, Branch=2, Dir=1, Info=0x294d6fa0, Data1=0x294d6560, Data2=0x0) at IO.c:414 #14 0x0807abdd in IO_read (io=0x294d6560) at IO.c:201 #15 0x0807acf7 in IO_callback (io=0x294d6560) at IO.c:266 #16 0x0807ad80 in IO_fd_read_cb (fd=64, data=0x8e) at IO.c:287 #17 0x080c8c99 in fltk::wait () #18 0x080c8e49 in fltk::run () #19 0x0804f19c in main (argc=1, argv=Cannot access memory at address 0x3c ) at dillo.cc:334 (gdb)

Jan. 7, 2009

Strange valgrind complain

by jcid＠dillo.org

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.-

Jan. 7, 2009

Strange valgrind complain

by Johannes.Hofmann＠gmx.de

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

Jan. 7, 2009

Strange valgrind complain

by corvid＠lavabit.com

The purpose of "force" was for users setting content type (or at least character encoding) through a dialog or menu or whatever.

Jan. 7, 2009

Strange valgrind complain

by jcid＠dillo.org

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.-

Jan. 7, 2009

Strange valgrind complain

by jcid＠dillo.org

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.-

Jan. 7, 2009

default search engine

by corvid＠lavabit.com

I was thinking about the news that was going around last month about yahoo making its data retention period shorter (with exceptions to let them get away with whatever they want, but that's par for the course). e.g. http://www.theregister.co.uk/2008/12/17/yahoo_anonymization_explained/ It seems like a good idea to set the search_url default to whoever is the...let's say "least bad" in terms of privacy at a given time.

Jan. 7, 2009

Strange valgrind complain

by corvid＠lavabit.com

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?

Jan. 6, 2009

Re: Added a right-click menu to the form submit button (allows to show hiddens)

by Johannes.Hofmann＠gmx.de

this is cool! Johannes

Jan. 6, 2009

Strange valgrind complain

by corvid＠lavabit.com

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?

Jan. 6, 2009