January 2009 - Dillo-dev - lists.mailman3.com

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

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

Jan. 6, 2009

Strange valgrind complain

by Johannes.Hofmann＠gmx.de

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

Jan. 6, 2009

Strange valgrind complain

by jcid＠dillo.org

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 ______________________________________________________________________

Jan. 5, 2009

Strange valgrind complain

by corvid＠lavabit.com

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?

Jan. 5, 2009

Strange valgrind complain

by jcid＠dillo.org

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 ______________________________________________________________________

Jan. 5, 2009

Re: We have competition!

by sandshrew＠gmail.com

> http://www.freesoftwaremagazine.com/columns/h3v_web_browser_it_dillo_killer > > What a headline! I was testing hv3 for quite awhile when the project was still active and would like to point out some stupid mistakes made in the article: 1) it's NOT h3v or h3w - it's hv3 (Html Viewer 3)! 2) it's written primarily in TCL, not in C; 3) both dillo and hv3 do support SSL (hv3 requires TLS for that and TLS is incorporated in the startkits, provided in the official website) 4) in both articles it is said "developerS". Actually 99% of the code (some parts were borrowed from another TCL browser called "BrowseX"(http://wiki.tcl.tk/2136)) was written by one genius named Daniel Kennedy. 5) Dillo actually launches a lot faster than hv3, but hv3 renders pages really fast too. And few comments from my side... Hv3 has a lot better bookmark manager when compared to dillo. Furthermore, in addition to bookmark, setting and cookie saving it can save history and has autocompletion. It has highly advanced css support - it even passes ACID2 test (something what microsoft with their internet exploiter was trying achieve for quite awhile...). As it's primarily written in TCL, it's platform independent, doesn't require any external dependencies, can run straight from USB flash memory (it can also save its db there too). Unlike dillo, hv3 also supports frames. Finally, even it's considered to be alpha state software, at least when javascript support is disabled, it is pretty stable. If you'd like to know something more about hv3, I think, you should still be able to contact Daniel - danielk1977 AT gmail DOT com. BTW, I don't know the current status of SEE project, I just know that the last time I checked (half a year ago or so) it had really many problems. SEE: http://www.adaptive-enterprises.com.au/~d/software/see/ -- Brain: an apparatus with which we think we think. - A. Bierce

Jan. 4, 2009

Re: We have competition!

by onepoint＠starurchin.org

On Sat, Jan 03, 2009 at 07:05:39PM -0300, Jorge Arellano Cid wrote: > http://www.freesoftwaremagazine.com/columns/h3v_web_browser_it_dillo_killer > > What a headline! Yes, it's flattering that Dillo is considered to be the one to beat! > but the comments there give a different idea... Indeed, it looks as thought H3w and SEE are dead projects. That's a shame. Jeremy Henty

Jan. 4, 2009

Re: We have competition!

by jcid＠dillo.org

On Sat, Jan 03, 2009 at 09:14:05PM +0000, Jeremy Henty wrote: > On Sat, Jan 03, 2009 at 01:48:42PM +0200, Tomas R wrote: > > > Sorry to disappoint you, but hv3 is officially unmaintained already > > for almost a year and SEE has LOTS of problems... > > That *is* disappointing. It would be good to have a simple, > maintained JavaScript engine to study. It's odd the article didn't > mention any of this; it made it sound as though both projects were > active. > > Thanks for the update, Sometime ago I read this: http://www.freesoftwaremagazine.com/columns/h3v_web_browser_it_dillo_killer What a headline! but the comments there give a different idea... -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________

Jan. 3, 2009

Re: We have competition!

by onepoint＠starurchin.org

On Sat, Jan 03, 2009 at 01:48:42PM +0200, Tomas R wrote: > Sorry to disappoint you, but hv3 is officially unmaintained already > for almost a year and SEE has LOTS of problems... That *is* disappointing. It would be good to have a simple, maintained JavaScript engine to study. It's odd the article didn't mention any of this; it made it sound as though both projects were active. Thanks for the update, Jeremy Henty

Jan. 3, 2009