May 2010 - Dillo-dev - lists.mailman3.com

Re: [dillo 2.2] CSS bug?

by jcid＠dillo.org

On Tue, May 11, 2010 at 01:36:51PM +0200, Michael Baeuerle wrote: > > Hi, > I have added a piece of demonstration code in the attached tarball. > Viewing the index.html file with dillo 2.2 shows the problem: If one of > the boxes contain code with "h2" or "p" tags, the margins associated > with the content seems to affect the layout outside the box (The margins > between the "top" and "content" boxes are defined as zero, so there > should be no space between them). IIRC dillo 2.1.1 have behaved > different. > > I have added two screenshots how dillo 2.2 and Webkit 1.1.8 (Midori) > render the test code on my machine. If I understand the CSS box model > [1] correctly, the content should never affect the area outside the > border and what dillo does is wrong. > > > Regards, > Michael Baeuerle > > [1] http://www.w3schools.com/css/css_boxmodel.asp Example: http://www.dillo.org/test/css-top-margin-bug.html Tarball: http://www.dillo.org/test/css-top-margin-bug.tar -- Cheers Jorge.-

May 22, 2010

Re: dillo question

by corvid＠lavabit.com

Johannes wrote: > and recompile fltk2 + dillo and run your test again? If we're already going for a recompilation, configuring fltk with ./configure --enable-debug and dillo with CFLAGS=-g CXXFLAGS=-g ./configure certainly would help.

May 15, 2010

Re: dillo question

by Johannes.Hofmann＠gmx.de

On Fri, May 14, 2010 at 05:09:56PM -0400, Jorge Arellano Cid wrote: > On Fri, May 14, 2010 at 04:44:30PM -0400, Matthew Craig wrote: > > Thanks for the continued diagnostic suggestions. I have joined the > > dillo-dev mailing list to make it easier for everyone else. I > > discovered interesting data-point, by chance. Normally, I run dillo > > with the command parameter "-g 999x666" to fit my screen more > > appropriately. > > > > ---Type <return> to continue, or q <return> to quit--- > > Core was generated by `dillo -g 999x666 > > http://uaddit.com/discussions/showthread.php?t=5931'. > > Program terminated with signal 6, Aborted. > > [New process 5489] > > #0 0x2af949f8 in raise () from /lib/libc.so.6 > > (gdb) bt > > #0 0x2af949f8 in raise () from /lib/libc.so.6 > > #1 0x2af9665c in abort () from /lib/libc.so.6 > > #2 0x0051facc in __gnu_cxx::__verbose_terminate_handler () > > #3 0x0051d7c4 in __cxxabiv1::__terminate () > > #4 0x0051d828 in std::terminate () > > #5 0x0051d9f8 in __cxa_throw () > > #6 0x0051de84 in operator new () > > #7 0x0051def8 in operator new[] () > > #8 0x004d14a0 in fltk::Image::make_current () > > #9 0x00499eac in ?? () > > This is interesting: it crashes within an FLTK2 function. > > I'm using fltk-2.0.x-r7513 and there we have: > > void Image::make_current() { > // TODO - make the cr point at the image_surface! > } > > No new() operator, no nothing! I think you need to check the Image::make_current() implementation in src/x11/Images.cxx. There is a buffer is allocated depending on the window size - which would explain, why the -g 999x666 is needed to trigger the bug. And there is this buffer size computation at line 1035, that I don't fully understand: n = (ld*h+3)&-4; maybe that doesn't work as expected on MIPS? Matthew, could you add a fprintf like fprintf(stderr, "====> n=%d\n", n); right after line 1035 in src/x11/Image.cxx of your fltk2 copy and recompile fltk2 + dillo and run your test again?

May 14, 2010

Re: dillo question

by jcid＠dillo.org

On Fri, May 14, 2010 at 04:44:30PM -0400, Matthew Craig wrote: > Thanks for the continued diagnostic suggestions. I have joined the > dillo-dev mailing list to make it easier for everyone else. I > discovered interesting data-point, by chance. Normally, I run dillo > with the command parameter "-g 999x666" to fit my screen more > appropriately. > ---Type <return> to continue, or q <return> to quit--- > Core was generated by `dillo -g 999x666 > http://uaddit.com/discussions/showthread.php?t=5931'. > Program terminated with signal 6, Aborted. > [New process 5489] > #0 0x2af949f8 in raise () from /lib/libc.so.6 > (gdb) bt > #0 0x2af949f8 in raise () from /lib/libc.so.6 > #1 0x2af9665c in abort () from /lib/libc.so.6 > #2 0x0051facc in __gnu_cxx::__verbose_terminate_handler () > #3 0x0051d7c4 in __cxxabiv1::__terminate () > #4 0x0051d828 in std::terminate () > #5 0x0051d9f8 in __cxa_throw () > #6 0x0051de84 in operator new () > #7 0x0051def8 in operator new[] () > #8 0x004d14a0 in fltk::Image::make_current () > #9 0x00499eac in ?? () This is interesting: it crashes within an FLTK2 function. I'm using fltk-2.0.x-r7513 and there we have: void Image::make_current() { // TODO - make the cr point at the image_surface! } No new() operator, no nothing! What fltk2 version are you using? -- Cheers Jorge.-

May 14, 2010

Re: dillo question

by matthew.t.craig＠gmail.com

Thanks for the continued diagnostic suggestions. I have joined the dillo-dev mailing list to make it easier for everyone else. I discovered interesting data-point, by chance. Normally, I run dillo with the command parameter "-g 999x666" to fit my screen more appropriately. The output, with 'ulimit -c unlimited' is below. (... continued) mtc@freedomincluded:/$ dillo -g 999x666 http://uaddit.com/discussions/showthread.php?t=5931 paths: Cannot open file '/home/mtc/.dillo/keysrc' paths: Using /usr/local/etc/dillo/keysrc dillo_dns_init: Here we go! (threaded) Disabling cookies. Nav_open_url: new url='http://uaddit.com/discussions/showthread.php?t=5931' Dns_server [0]: uaddit.com is 72.44.80.46 Connecting to 72.44.80.46 CssParser::parseImport(): @import clientscript/vbulletin_css/style-01a90dc0-00011.css terminate called after throwing an instance of 'std::bad_alloc' what(): std::bad_alloc Aborted (core dumped) (... continued) Now, watch the output as I run in the same environment without the "-g" parameter. No crash! mtc@freedomincluded:/$ dillo http://uaddit.com/discussions/showthread.php?t=5931 paths: Cannot open file '/home/mtc/.dillo/keysrc' paths: Using /usr/local/etc/dillo/keysrc dillo_dns_init: Here we go! (threaded) Disabling cookies. Nav_open_url: new url='http://uaddit.com/discussions/showthread.php?t=5931' Dns_server [0]: uaddit.com is 72.44.80.46 Connecting to 72.44.80.46 CssParser::parseImport(): @import clientscript/vbulletin_css/style-01a90dc0-00011.css a_UIcmd_close_bw Dillo: normal exit! I have also run the core dump (from above) through gdb as you specified in your email. The output follows: mtc@freedomincluded:~$ gdb /usr/local/bin/dillo /tmp/core 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 "mipsel-linux-gnu"... (no debugging symbols found) Reading symbols from /usr/lib/libjpeg.so.62...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libjpeg.so.62 Reading symbols from /usr/lib/libpng12.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libpng12.so.0 Reading symbols from /usr/lib/libz.so.1... (no debugging symbols found)...done. Loaded symbols for /usr/lib/libz.so.1 Reading symbols from /usr/lib/libX11.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libX11.so.6 Reading symbols from /usr/lib/libXi.so.6... (no debugging symbols found)...done. Loaded symbols for /usr/lib/libXi.so.6 Reading symbols from /usr/lib/libXinerama.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libXinerama.so.1 Reading symbols from /usr/lib/libXcursor.so.1... (no debugging symbols found)...done. Loaded symbols for /usr/lib/libXcursor.so.1 Reading symbols from /usr/lib/libXft.so.2...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libXft.so.2 Reading symbols from /lib/libpthread.so.0... (no debugging symbols found)...done. Loaded symbols for /lib/libpthread.so.0 Reading symbols from /usr/lib/libXext.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libXext.so.6 Reading symbols from /usr/lib/libstdc++.so.6... (no debugging symbols found)...done. Loaded symbols for /usr/lib/libstdc++.so.6 Reading symbols from /lib/libm.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/libm.so.6 Reading symbols from /lib/libgcc_s.so.1... (no debugging symbols found)...done. Loaded symbols for /lib/libgcc_s.so.1 Reading symbols from /lib/libc.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /lib/ld.so.1... (no debugging symbols found)...done. Loaded symbols for /lib/ld.so.1 Reading symbols from /usr/lib/libXrender.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libXrender.so.1 Reading symbols from /usr/lib/libfontconfig.so.1... (no debugging symbols found)...done. Loaded symbols for /usr/lib/libfontconfig.so.1 Reading symbols from /usr/lib/libxcb-xlib.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libxcb-xlib.so.0 Reading symbols from /usr/lib/libxcb.so.1... (no debugging symbols found)...done. Loaded symbols for /usr/lib/libxcb.so.1 Reading symbols from /lib/libdl.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /usr/lib/libXfixes.so.3... (no debugging symbols found)...done. Loaded symbols for /usr/lib/libXfixes.so.3 Reading symbols from /usr/lib/libfreetype.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libfreetype.so.6 Reading symbols from /usr/lib/libXau.so.6... (no debugging symbols found)...done. Loaded symbols for /usr/lib/libXau.so.6 Reading symbols from /usr/lib/libexpat.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libexpat.so.1 Reading symbols from /usr/lib/libXdmcp.so.6... (no debugging symbols found)...done. Loaded symbols for /usr/lib/libXdmcp.so.6 Reading symbols from /lib/libnss_files.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/libnss_files.so.2 Reading symbols from /lib/libnss_mdns4_minimal.so.2... (no debugging symbols found)...done. Loaded symbols for /lib/libnss_mdns4_minimal.so.2 Reading symbols from /lib/libnss_dns.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/libnss_dns.so.2 Reading symbols from /lib/libresolv.so.2... (no debugging symbols found)...done. Loaded symbols for /lib/libresolv.so.2 Reading symbols from /usr/lib/gconv/ISO8859-1.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib/gconv/ISO8859-1.so ---Type <return> to continue, or q <return> to quit--- Core was generated by `dillo -g 999x666 http://uaddit.com/discussions/showthread.php?t=5931'. Program terminated with signal 6, Aborted. [New process 5489] #0 0x2af949f8 in raise () from /lib/libc.so.6 (gdb) bt #0 0x2af949f8 in raise () from /lib/libc.so.6 #1 0x2af9665c in abort () from /lib/libc.so.6 #2 0x0051facc in __gnu_cxx::__verbose_terminate_handler () #3 0x0051d7c4 in __cxxabiv1::__terminate () #4 0x0051d828 in std::terminate () #5 0x0051d9f8 in __cxa_throw () #6 0x0051de84 in operator new () #7 0x0051def8 in operator new[] () #8 0x004d14a0 in fltk::Image::make_current () #9 0x00499eac in ?? () warning: GDB can't find the start of the function at 0x499eab. GDB is unable to find the start of the function at 0x499eab and thus can't determine the size of that function's stack frame. This means that GDB may be unable to access that stack frame, or the frames below it. This problem is most likely caused by an invalid program counter or stack pointer. However, if you think GDB should simply search farther back from 0x499eab for code which looks like the beginning of a function, you can increase the range of the search using the `set heuristic-fence-post' command. Backtrace stopped: previous frame inner to this frame (corrupt stack?)

May 14, 2010

Re: dillo question

by Johannes.Hofmann＠gmx.de

On Fri, May 14, 2010 at 10:22:53AM -0400, Matthew Craig wrote: > process limits set in your environmen (ulimit -a) > > mtc@freedomincluded:~$ ulimit -a > core file size (blocks, -c) 0 > data seg size (kbytes, -d) unlimited > scheduling priority (-e) 0 > file size (blocks, -f) unlimited > pending signals (-i) 4019 > max locked memory (kbytes, -l) 64 > max memory size (kbytes, -m) unlimited > open files (-n) 1024 > pipe size (512 bytes, -p) 8 > POSIX message queues (bytes, -q) 819200 > real-time priority (-r) 0 > stack size (kbytes, -s) 8192 > cpu time (seconds, -t) unlimited > max user processes (-u) 4019 > virtual memory (kbytes, -v) unlimited > file locks (-x) unlimited Ah, core files are disabled on your system. You need to call ulimit -c unlimited in the shell from which you start dillo to actually get a core file. After dillo aborts, the core file should show up in /tmp.

May 14, 2010

Re: dillo question

by Johannes.Hofmann＠gmx.de

On Fri, May 14, 2010 at 10:22:53AM -0400, Matthew Craig wrote: > process limits set in your environmen (ulimit -a) > > mtc@freedomincluded:~$ ulimit -a > core file size (blocks, -c) 0 > data seg size (kbytes, -d) unlimited > scheduling priority (-e) 0 > file size (blocks, -f) unlimited > pending signals (-i) 4019 > max locked memory (kbytes, -l) 64 > max memory size (kbytes, -m) unlimited > open files (-n) 1024 > pipe size (512 bytes, -p) 8 > POSIX message queues (bytes, -q) 819200 > real-time priority (-r) 0 > stack size (kbytes, -s) 8192 > cpu time (seconds, -t) unlimited > max user processes (-u) 4019 > virtual memory (kbytes, -v) unlimited > file locks (-x) unlimited Ok, so that's not it... Do you get a core file when it aborts? If so please run gdb on it: gdb <path to dillo binary> <path to core file> and type "bt" at the gdb prompt. The output might give us a hint on what's failing.

May 14, 2010

Re: dillo question

by jcid＠dillo.org

On Fri, May 14, 2010 at 09:40:09AM -0400, Matthew Craig wrote: > Here is the output with all CSS options turned off: > > Nav_open_url: new url='http://uaddit.com/discussions/showthread.php?t=5931' > Dns_server [0]: uaddit.com is 72.44.80.46 > Connecting to 72.44.80.46 > terminate called after throwing an instance of 'std::bad_alloc' > what(): std::bad_alloc > Aborted OK, let's test without CSS as it is not the problem. From previous output it looks like the problem is related to an event and not the suspected function. I'd say: gdb ./dillo r http://uaddit.com/discussions/showthread.php?t=5931 at some point it'll crash, then: bt (and send us the backtrace). There's a lot more you can do with gdb, this is just to start. PS: Forget my previous email, I pressed "send" instead of "postpone" and that's why it got cut in the middle of a sentence :-) -- Cheers Jorge.-

May 14, 2010

Re: dillo question

by Johannes.Hofmann＠gmx.de

On Fri, May 14, 2010 at 08:51:33AM -0400, Jorge Arellano Cid wrote: > On Wed, May 12, 2010 at 03:44:50PM -0400, Matthew Craig wrote: > > Thanks for your response. Sorry that I am reluctant to join any mailing lists. > > The Lemote laptop has alot of memory: 1GB and 2.7GB swap. I am > > running GNOME without memory problems, and usage rarely rises over 50% > > ... I am reluctant to presume Dillo is using all the memory up, but I > > have been watching it today. > > > > Browsing to that website when Dillo is started fresh does indeed cause > > an immediate crash. > > OK, that eliminates the memory shortage thesis... > > > mtc@freedomincluded:~$ dillo -g 999x666 > > http://uaddit.com/discussions/showthread.php?t=5931 > > paths: Cannot open file '/home/mtc/.dillo/keysrc' > > paths: Using /usr/local/etc/dillo/keysrc > > dillo_dns_init: Here we go! (threaded) > > Disabling cookies. > > Nav_open_url: new url='http://uaddit.com/discussions/showthread.php?t=5931' > > Dns_server [0]: uaddit.com is 72.44.80.46 > > Connecting to 72.44.80.46 > > CssParser::parseImport(): @import > > clientscript/vbulletin_css/style-01a90dc0-00011.css > > terminate called after throwing an instance of 'std::bad_alloc' > > what(): std::bad_alloc > > Aborted > > > > Please start dillo, disable css (tools button) and load the page. > If it doesn't crash after the page loads, enable css again and see what > happens (this is to check in what part of dillo the allocation > problem is and to discard a race condition between css and html > rendering). > > This bug is very interesting (probably there's something > uninitialized in dillo or outside of it). I'll check with > valgrind. > > Can someone else reproduce this bug? Works fine for me. Are there any process limits set in your environmen (ulimit -a)? Cheers, Johannes

May 14, 2010

Re: dillo question

by jcid＠dillo.org

On Wed, May 12, 2010 at 03:44:50PM -0400, Matthew Craig wrote: > Thanks for your response. Sorry that I am reluctant to join any mailing lists. > The Lemote laptop has alot of memory: 1GB and 2.7GB swap. I am > running GNOME without memory problems, and usage rarely rises over 50% > ... I am reluctant to presume Dillo is using all the memory up, but I > have been watching it today. > > Browsing to that website when Dillo is started fresh does indeed cause > an immediate crash. > > mtc@freedomincluded:~$ dillo -g 999x666 > http://uaddit.com/discussions/showthread.php?t=5931 > paths: Cannot open file '/home/mtc/.dillo/keysrc' > paths: Using /usr/local/etc/dillo/keysrc > dillo_dns_init: Here we go! (threaded) > Disabling cookies. > Nav_open_url: new url='http://uaddit.com/discussions/showthread.php?t=5931' > Dns_server [0]: uaddit.com is 72.44.80.46 > Connecting to 72.44.80.46 > CssParser::parseImport(): @import > clientscript/vbulletin_css/style-01a90dc0-00011.css > terminate called after throwing an instance of 'std::bad_alloc' > what(): std::bad_alloc > Aborted I can't reproduce it with valgrind... :-P ...but, from the above output, the last debug message comes from cssparser.cc:1428 and it calls a_Html_load_stylesheet() which should print "NumPendingStyleSheets=1" (html.cc:2985). So, the problem is in this tiny spot. Please run gdb, set a break point in a_Html_load_stylesheet() and follow it carefully step by step until it crashes to know in what line the problem is triggered. -- Cheers Jorge.-

May 14, 2010