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

dillo crash at dlib/dlib.c:173

by corvid＠lavabit.com

?? wrote: > After update, the dillo crash while opening http://www.google.com.tw > on dlib/dlib.c:173 > > The array haystack is null and unchecked cause the problem... > > Log as below > > gigijoe@user-desktop:~/dillo2$ gdb src/dillo > GNU gdb 6.8-debian > Copyright (C) 2008 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show copying" > and "show warranty" for details. > This GDB was configured as "i486-linux-gnu"... > (gdb) r > Starting program: /home/gigijoe/dillo2/src/dillo > [Thread debugging using libthread_db enabled] > paths: Cannot open file '/home/gigijoe/.dillo/keysrc' > paths: Cannot open file '/usr/local/etc/dillo/keysrc' > paths: Using internal defaults... > dillo_dns_init: Here we go! (threaded) > Disabling cookies. > Nav_open_url: new url='http://www.google.com.tw' > [New Thread 0xb795b8e0 (LWP 11430)] > [New Thread 0xb782bb90 (LWP 11433)] > Dns_server [0]: www.google.com.tw is 74.125.19.105 74.125.19.106 74.125.19.99 74.125.19.104 74.125.19.103 74.125.19.147 > [Thread 0xb782bb90 (LWP 11433) exited] > Connecting to 74.125.19.105 > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 0xb795b8e0 (LWP 11430)] > 0x0807ee7c in dStristr (haystack=0x0, needle=0x810c13f "javascript") at dlib.c:173 > 173 for (i = 0, j = 0; haystack[i] && needle[j]; ++i) > Current language: auto; currently c > (gdb) q > The program is running. Exit anyway? (y or n) y I believe it's breaking in your javascript patch. We usually write if (attrbuf) { .. } But regardless, dStristr() should have checks for NULL. I'll add them in a moment.

July 28, 2009

dillo crash at dlib/dlib.c:173

by stevegigijoe＠yahoo.com.tw

Hello all After update, the dillo crash while opening http://www.google.com.tw on dlib/dlib.c:173 The array haystack is null and unchecked cause the problem... Log as below gigijoe@user-desktop:~/dillo2$ gdb src/dillo GNU gdb 6.8-debian Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i486-linux-gnu"... (gdb) r Starting program: /home/gigijoe/dillo2/src/dillo [Thread debugging using libthread_db enabled] paths: Cannot open file '/home/gigijoe/.dillo/keysrc' paths: Cannot open file '/usr/local/etc/dillo/keysrc' paths: Using internal defaults... dillo_dns_init: Here we go! (threaded) Disabling cookies. Nav_open_url: new url='http://www.google.com.tw' [New Thread 0xb795b8e0 (LWP 11430)] [New Thread 0xb782bb90 (LWP 11433)] Dns_server [0]: www.google.com.tw is 74.125.19.105 74.125.19.106 74.125.19.99 74.125.19.104 74.125.19.103 74.125.19.147 [Thread 0xb782bb90 (LWP 11433) exited] Connecting to 74.125.19.105 Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb795b8e0 (LWP 11430)] 0x0807ee7c in dStristr (haystack=0x0, needle=0x810c13f "javascript") at dlib.c:173 173 for (i = 0, j = 0; haystack[i] && needle[j]; ++i) Current language: auto; currently c (gdb) q The program is running. Exit anyway? (y or n) y Steve ______________________________________________________________________________________________________ ¥I¶O€~®e¶qµL€W¡HYahoo!©_Œ¯¹q€l«Hœc2.0§K¶Oµ¹§A¡A«H¥ó¥Ã»·€£¥²§R¡I http://tw.mg0.mail.yahoo.com/dc/landing

July 28, 2009

dIsspace

by jcid＠dillo.org

On Mon, Jul 27, 2009 at 02:16:53PM +0000, corvid wrote: > Jorge wrote: > > When porting dillo to minix3 I had this problem. > > So it works? I don't see it in Compatibility.html Minix3 doesn't have Unix sockets nor pthreads yet, so all the DPI framework is not of the party. The main program (dillo itself) works very well on rendering and UI (flawless in my local testing). I don't have a network card supported by minix so they're testing how it works on the real Web. Once I get an official OK, it surely deserves a mention in Compatibility.html. -- Cheers Jorge.-

July 27, 2009

Planning

by corvid＠lavabit.com

Jorge wrote: > On Sun, Jul 26, 2009 at 05:21:07PM +0000, corvid wrote: > > Jorge wrote: > > > * Jump to #anchor doesn't work correctly. > > > It looks like a timing issue, but the idle-call API needs a > > > review as a whole. > > > > Speaking of idle, is there a reasonable way to make it so that > > the importance goes > > 1) network->cache > > 2) UI responsive > > 3) cache->textblock > > Given the way the code and network engine are designed, > there're much simpler ways to achieve UI responsiveness. > > For instance: AFAIR, currently the redraw requests are queued > and idled. When the idle queue is finally processed all the > pending redraws are issued one after another. Considering that > rendering is a resource-heavy operation, if the drawing code > could cancel the previous requests and only issue the really > needed ones this alone could reduce CPU usage by a significative > factor, and make the whole browser feel much faster. Ohh... I thought it was doing this already.

July 27, 2009

dIsspace

by joerg.sonnenberger＠web.de

On Mon, Jul 27, 2009 at 10:02:28AM -0400, Jorge Arellano Cid wrote: > On Sun, Jul 26, 2009 at 06:53:11PM +0200, Joerg Sonnenberger wrote: > > The results for C++ are not different as far as ctype(3) are concerned. > > It looks like it's the compiler the one that decides [1]. > When porting dillo to minix3 I had this problem. Yes, what I said is that it is irrelevant whether you have C or C++ for this. The argument for ctype(3) macros must always be either EOF or 0..255. At least on NetBSD you will also get a compiler warning when using (signed) char. Joerg

July 27, 2009

dIsspace

by corvid＠lavabit.com

Jorge wrote: > When porting dillo to minix3 I had this problem. So it works? I don't see it in Compatibility.html

July 27, 2009

Planning

by jcid＠dillo.org

On Sun, Jul 26, 2009 at 05:21:07PM +0000, corvid wrote: > Jorge wrote: > > * Jump to #anchor doesn't work correctly. > > It looks like a timing issue, but the idle-call API needs a > > review as a whole. > > Speaking of idle, is there a reasonable way to make it so that > the importance goes > 1) network->cache > 2) UI responsive > 3) cache->textblock Given the way the code and network engine are designed, there're much simpler ways to achieve UI responsiveness. For instance: AFAIR, currently the redraw requests are queued and idled. When the idle queue is finally processed all the pending redraws are issued one after another. Considering that rendering is a resource-heavy operation, if the drawing code could cancel the previous requests and only issue the really needed ones this alone could reduce CPU usage by a significative factor, and make the whole browser feel much faster. > I know we have "throttle rendering" listed in the plans, but I seem to > recall that being a KB/s sort of thing. There're several ways to approach this problem... -- Cheers Jorge.-

July 27, 2009

dIsspace

by jcid＠dillo.org

On Sun, Jul 26, 2009 at 06:53:11PM +0200, Joerg Sonnenberger wrote: > On Sun, Jul 26, 2009 at 12:27:05PM -0400, Jorge Arellano Cid wrote: > > On Sat, Jul 25, 2009 at 08:02:02PM +0000, corvid wrote: > > > When are we supposed to use isspace() > > > and when are we supposed to use dIsspace()? > > > It appears that one is now used in the C++ code > > > and the other in the C code, but I don't know > > > the reason for this distinction. > > > > C and C++ have different conventions for data types. > > dIsspace() avoids problems in C code on platforms with > > a signed char default. C++ is inmune. > > The results for C++ are not different as far as ctype(3) are concerned. It looks like it's the compiler the one that decides [1]. When porting dillo to minix3 I had this problem. > > OTOH, it looks weird to have both calls in the code. I'd > > happily use dIsspace() all over if the compiler optimizes the > > extra cast away. > > The cast is a nop on every architecture that matters. That is not the > answer you might get from comp.lang.c though :) Good, then we can use dIsspace all over the place. [1] http://home.att.net/~jackklein/c/inttypes.html -- Cheers Jorge.-

July 27, 2009

Planning

by jcid＠dillo.org

On Fri, Jul 24, 2009 at 07:19:43PM +0200, Johannes Hofmann wrote: > Hi, > > On Fri, Jul 24, 2009 at 11:33:28AM -0400, Jorge Arellano Cid wrote: > > Hi, > > > > Here are some pending issues which I've partially sorted by > > priority (at least the top half). Please add the missing ones and > > let's try to finish sorting it, with a view to planify our work. > > > > > > * Make DIV-based pages render correctly. > > This is the most visible rendering fault in Dillo. The > > textblock doesn't have a way to handle it (not implemented). > > IIRC I'm willing to dig into it and Johannes will help. > > e.g. http://www.advogato.org/faq.html > > With DIV-based pages you mean floats as in > http://www.w3.org/TR/CSS21/visuren.html#floats? Exactly. > Yes, this is the most obvious rendering problem atm. It looks complex, and it will take some time to study before coming with implementation ideas. > > * Add blocker (this also has to do with privacy). > > A full RE-based one may have significant overhead (test > > required), but simple string-matching may do most of the trick. > > I've also thought for a long time that a "don't load from > > other sites" preference may help a lot. The whole topic needs > > some thought but it's not hard to implement. > > e.g. doubleclick. > > > > * Handle negative values in CSS. e.g. wikipedia. > > Actually it's dw/* that needs to be adapted to handle negative > margins. This might be related to the floats stuff. It looks like. Maybe they can be implemented separately. > * Add clipping to the fltk drawing code, so that e.g. margins of huge > boxes don't cause X11 coordinate overflows. > E.g. on http://alpen-panoramen.de/newcomments.php > I will try to fix that. > Similar issues occur with very long lines in plain.cc. At what priority? -- Cheers Jorge.-

July 26, 2009

Planning

by corvid＠lavabit.com

Jorge wrote: > * Jump to #anchor doesn't work correctly. > It looks like a timing issue, but the idle-call API needs a > review as a whole. Speaking of idle, is there a reasonable way to make it so that the importance goes 1) network->cache 2) UI responsive 3) cache->textblock I know we have "throttle rendering" listed in the plans, but I seem to recall that being a KB/s sort of thing.

July 26, 2009