- Dillo-dev - lists.mailman3.com

Dillo in Debian

by jcid＠dillo.org

Hi Wookey, A post in dillo-dev made me aware of this thread: http://bugs.debian.org/cgi-bin/bugreport.cgi?archive=no&bug=510348 Thanks for your comment ;-) Some technical facts (all available from dillo.org) * dillo-0.8.x is unmaintained * dillo-2.x is the official stable branch * dillo-2.x uses FLTK2 not GTK2 as stated in the thread IMHO it'd be good to have dillo-0.8.x in Lenny, at least until dillo-2.x makes its way into Debian. We've been working on this branch for more than a year and it's way better than the former (details in the website). I'm aware of the problem distros have with including statically linked packages, and it looks like dillo-2.x will be left out of them until this issue is solved. Unfortunately FLTK-2.0 is stalled and an official release of it is nowhere near in the future. OTOH, an active set of developers is pushing FLTK-1.3.x very fast. This branch provides more or less the same FLTK-2.0 does. It's being actively developed, is less buggy and more stable, and will most probably be released soon (I'm yet to ask the team about dates). At some point in time we'll be migrating to FLTK-1.3.x (it has almost the same API), and hopefully then it'll be easier to include dillo in Debian. If you make progress with the certificate patch, please let us know. We're fully devoted to CSS now, and have no SSL expert in the team :( -- On a personal level, I'd love to have Dillo used in Debian as a help browser. This is, since a long time ago I've noticed applications come with almost no help (F1 button in the old days) and help drives you to an "About" window. But OTOH they have very good HTML docs (usually in usr/share/), that could provide for accurate context-sensitive help pages. The problem is they don't hook a web browser to the help button because a bloated app. that takes a long time to start, only to crawl the computer afterwards, is the last thing a developer hopes as her end user experience. There's the possibility of having a simple API to remote control the browser so the same instance is used. Dillo is fast, lean, and low on library dependencies. Any doubts, just don't hesitate to ask. -- Cheers Jorge.-

Jan. 8, 2009

one more crash

by jcid＠dillo.org

On Thu, Jan 08, 2009 at 01:37:26PM +0100, Johannes Hofmann wrote: > On Wed, Jan 07, 2009 at 07:54:51PM -0300, Jorge Arellano Cid wrote: > > On Wed, Jan 07, 2009 at 09:59:22PM +0100, Johannes Hofmann wrote: > > > Sorry, but I'm seeing one more crash with > > > current css-prototype. > > > > Thanks for the politeness. > > It's good to be testing. > > > > I've long forgotten the mess that image processing code became. > > That's why I've taken the time to try to push code cleanups... > > > > > > > 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 > > > > The layout belongs to the bw, so it shouldn't dissappear with > > repush. It looks like Image is already freed. > > > > Let's see: > > > > jcid@d620:~/C/Dillo/d2/dillo-css-wc2/src$ srch a_Image_ref > > image.cc:void a_Image_ref(DilloImage *Image) > > image.hh:void a_Image_ref(DilloImage *Image); > > gif.c: a_Image_ref(web->Image); > > jpeg.c: a_Image_ref(web->Image); > > png.c: a_Image_ref(web->Image); > > jcid@d620:~/C/Dillo/d2/dillo-css-wc2/src$ srch a_Image_unref > > html.cc: a_Image_unref(li->image); > > image.cc:void a_Image_unref(DilloImage *Image) > > image.cc: a_Image_unref(Image); > > image.hh:void a_Image_unref(DilloImage *Image); > > web.cc: a_Image_unref(web->Image); > > > > this looks like unbalanced ref/unref for the Image. > > Gif/Jpeg/Png match with image.cc > > The initial Ref=1 matches web.cc > > html.cc matches ?? > > > > Please test with one or two extra a_Image_ref() > > at dicache.c:269, or at your choice, on the proper place! :-) > > That didn't help. Backing out abdae95b1c9e however helps so far. OK, let's back it out and see if it becomes stable again. -- Cheers Jorge.-

Jan. 8, 2009

dillo about to be dropped from debian

by r00t＠constancy.org

FYI: http://bugs.debian.org/cgi-bin/bugreport.cgi?archive=no&bug=510348 it seems that dillo is about to be dropped from debian, because * ssl lacks proper certificate verification * it still uses gtk1.2 (personally, the first never bothered me, and i consider the second a _feature_) Greetings, Thorben Thuermer

Jan. 8, 2009

one more crash

by Johannes.Hofmann＠gmx.de

On Wed, Jan 07, 2009 at 07:54:51PM -0300, Jorge Arellano Cid wrote: > On Wed, Jan 07, 2009 at 09:59:22PM +0100, Johannes Hofmann wrote: > > Sorry, but I'm seeing one more crash with > > current css-prototype. > > Thanks for the politeness. > It's good to be testing. > > I've long forgotten the mess that image processing code became. > That's why I've taken the time to try to push code cleanups... > > > > 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 > > The layout belongs to the bw, so it shouldn't dissappear with > repush. It looks like Image is already freed. > > Let's see: > > jcid@d620:~/C/Dillo/d2/dillo-css-wc2/src$ srch a_Image_ref > image.cc:void a_Image_ref(DilloImage *Image) > image.hh:void a_Image_ref(DilloImage *Image); > gif.c: a_Image_ref(web->Image); > jpeg.c: a_Image_ref(web->Image); > png.c: a_Image_ref(web->Image); > jcid@d620:~/C/Dillo/d2/dillo-css-wc2/src$ srch a_Image_unref > html.cc: a_Image_unref(li->image); > image.cc:void a_Image_unref(DilloImage *Image) > image.cc: a_Image_unref(Image); > image.hh:void a_Image_unref(DilloImage *Image); > web.cc: a_Image_unref(web->Image); > > this looks like unbalanced ref/unref for the Image. > Gif/Jpeg/Png match with image.cc > The initial Ref=1 matches web.cc > html.cc matches ?? > > Please test with one or two extra a_Image_ref() > at dicache.c:269, or at your choice, on the proper place! :-) That didn't help. Backing out abdae95b1c9e however helps so far. Cheers, Johannes

Jan. 8, 2009

one more crash

by jcid＠dillo.org

On Wed, Jan 07, 2009 at 09:59:22PM +0100, Johannes Hofmann wrote: > Sorry, but I'm seeing one more crash with > current css-prototype. Thanks for the politeness. It's good to be testing. I've long forgotten the mess that image processing code became. That's why I've taken the time to try to push code cleanups... > 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 The layout belongs to the bw, so it shouldn't dissappear with repush. It looks like Image is already freed. Let's see: jcid@d620:~/C/Dillo/d2/dillo-css-wc2/src$ srch a_Image_ref image.cc:void a_Image_ref(DilloImage *Image) image.hh:void a_Image_ref(DilloImage *Image); gif.c: a_Image_ref(web->Image); jpeg.c: a_Image_ref(web->Image); png.c: a_Image_ref(web->Image); jcid@d620:~/C/Dillo/d2/dillo-css-wc2/src$ srch a_Image_unref html.cc: a_Image_unref(li->image); image.cc:void a_Image_unref(DilloImage *Image) image.cc: a_Image_unref(Image); image.hh:void a_Image_unref(DilloImage *Image); web.cc: a_Image_unref(web->Image); this looks like unbalanced ref/unref for the Image. Gif/Jpeg/Png match with image.cc The initial Ref=1 matches web.cc html.cc matches ?? Please test with one or two extra a_Image_ref() at dicache.c:269, or at your choice, on the proper place! :-) -- Cheers Jorge.-

Jan. 7, 2009

one more crash

by jcid＠dillo.org

On Wed, Jan 07, 2009 at 09:59:22PM +0100, Johannes Hofmann wrote: > 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. Hmm, I haven't been able to reproduce it yet... Do you mean it never crashes without abdae95b1c9e? -- Cheers Jorge.-

Jan. 7, 2009

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