- Dillo-dev - lists.mailman3.com

Re: dillo question
by matthew.t.craig＠gmail.com May 15, 2010

May 15, 2010

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?)

4 3

Re: dillo question
by Johannes.Hofmann＠gmx.de May 14, 2010

May 14, 2010

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.

1 0

Re: dillo question
by Johannes.Hofmann＠gmx.de May 14, 2010

May 14, 2010

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.

1 0

Re: dillo question
by jcid＠dillo.org May 14, 2010

May 14, 2010

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

1 0

Re: dillo question
by jcid＠dillo.org May 14, 2010

May 14, 2010

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? -- Cheers Jorge.-

2 1

Re: dillo question
by jcid＠dillo.org May 14, 2010

May 14, 2010

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

1 0

Re: dillo question
by jcid＠dillo.org May 11, 2010

May 11, 2010

Hi Matthew, Please follow this thread in dillo-dev. There's no better place to get good feedback. On Mon, May 10, 2010 at 08:00:39PM -0400, Matthew Craig wrote: > Hello Jorge, > I have been using dillo quite a bit on my Lemote Longsoon laptop, with > some success. But, there are often fatal crashes. Do you think this > is based on the MIPS architecture, or just Dillo not handling many web > pages well? Here is the output of the most recent crash. Dillo is very stable on several platforms. I don't believe it has to do with MIPS, but with memory usage. The crash output points to a memory allocating function. When there's no more memory, dillo just exits. Please let us know how much memory you have on the Lemote, and watch it with top or a memory profiler, to know how much is available after X is running. I'd expect the page not to crash if Dillo is the first and only application running and if it is the first page you open (i.e. with more memory available). > > Connecting to 216.250.116.45 > Dns_server [0]: feeds2.feedburner.com is 74.125.93.118 > Dns_server [1]: www.w3.org is 128.30.52.166 128.30.52.168 > 128.30.52.170 128.30.52.38 128.30.52.51 128.30.52.53 128.30.52.54 > Nav_open_url: new > url='http://francisshanahan.com/index.php/2005/primer-movie-scene-by-scene-expla…' > Connecting to 216.250.116.45 > Dns_server [0]: images.amazon.com is 207.123.55.126 209.84.20.126 > 204.160.127.126 > Dns_server [1]: www.gravatar.com is 72.233.61.123 72.233.61.125 > 72.233.69.4 72.233.69.5 72.233.44.59 72.233.44.61 > a_UIcmd_close_bw > 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 > -- Cheers Jorge.-

1 0

Re: Bug in Dillo Text Entry
by Johannes.Hofmann＠gmx.de May 11, 2010

May 11, 2010

Hi, On Fri, May 07, 2010 at 11:45:02PM -0800, rogerx(a)sdf.org wrote: > I posted to the mailing list sometime ago concerning a bug with Dillo > text entry form. After some time, the text entry box in google search > box (or on other websites) would only allow certain keys to be typed > (ie. s and g, most other keys simply ignored when typed in text entry > boxes). I can reproduce this now, however as you say, I think it just looses focus, so here no keys work at all until I refocus the text input. > > I've finally resolved this, or hacked around it to live with it better. Did you fix some code, or do you just refocus manually? > > The bug occurs when a user of the DWM desktop moves Dillo from one > virtual window to another virtual window using "Meta key + right mouse > click" and the "right mouse click + virtual window number" to move a > window to another virtual desktop within DWM. > > Once moved to the other window, the text entry box will exhibit the > above keyboard entry anomly. Basically, I think it's just loosing > focus. The user can get back regular keyboard entry by using "Meta Key > + Tab" to toggle focus from the previous desktop and then again to > regain focus of the virtual desktop containing Dillo, and should then be > able to type normally again. All keys should work. > > Again, I think Dillo is just losing focus of the text entry box.. or > something similar. As other fltk2 apps don't show this behaviour we should be able to fix that in dillo, but I don't yet understand fully what is going on. Cheers, Johannes PS: Good to see that there is other dwm + dillo users out there :-)

4 8

setting image buffer and queueing resize
by corvid＠lavabit.com May 9, 2010

May 9, 2010

I had just fixed the dw simple image test that hadn't requested a resize when setting the imgbuf. And now I just found that one of the scaled2 test's images needs it as well. Perhaps we should make the resize argument to setBuffer() mandatory. But, better yet, how about if Image::setBuffer() just does a queueResize() if either of its dimensions are LENGTH_AUTO?

3 2

Re: commit 3e01d83fd6d1 draws too large background box
by Johannes.Hofmann＠gmx.de May 9, 2010

May 9, 2010

Hi, sorry for the delay... On Tue, Apr 27, 2010 at 11:40:11PM +0200, Johannes Hofmann wrote: > On Tue, Apr 27, 2010 at 09:04:49PM +0000, corvid wrote: > > > commit 3e01d83fd6d1 (draw background for all Words, not just text) > > > draws a too large background box e.g. in this example: > > > > > > <html><body> > > > foo <div style="background-color: blue; margin-top: 100px">bar</div> > > > </body></html> > > > > > > The margin should not be blue. > > > What is the reason for this change anyway? Shouldn't each widget be > > > responsible for it's drawing (including the background)? > > > > This is when I was looking at the rectangles of color on the fltk.org > > page around, e.g., "FLTK Apps", "FLTK Library"... > > > > The rectangle of color (which came from the style of the A element, iirc) > > is "supposed" to be taller than the little rounded-corner images, judging > > by what firefox does. > > Ah, I think I see the problem now. Textblock has to draw the > background for the <A> element - even at places where it is covered > by child widgets, as they might be transparent. > On the other hand margins are always transparent (see > http://www.w3.org/TR/CSS2/box.html) so there is a problem in the > current implementation. > I guess I need some time to think about this. > > > > > So if the margin is part of the child, then... > > how should this be disentangled? > > Does it come down to being one of those things that have to wait until > > we have more of a real box model? > > > > We already have a proper box model for block boxes, what we are missing > is proper handling of inline boxes (e.g. drawing borders around > <a>-elements). Ok, the general problem is that a single Textblock widget can handle multiple HTML elements. E.g. in this case: <a href=foo style="background-color: red">foo <b>bar</b></a> there is just a single Textblock drawing the whole thing. The style of the word "bar" would normally not have a background color set, but the red of the <a> element would shine through, but as the textblock simply draws one word after the other, we do not draw the whole <a> element and then draw the <b> element on top. To make the background color work nevertheless, I had introduced the inheritBackgroundColor hack, which will pass the red background to the style of the child element (<b> in this case). However, this hack does not work properly if the child element has a margin: <a href=foo style="background-color: red">foo <img src=foo.png alt=bar style="margin:1em"></a> So I think we should remove the whole inheritBackgroundColor() hack and replace it with some code in textblock.cc, that draws the proper background color for all words as necessary. We need to be careful though to not draw word backgrounds if they are the same color as the whole textblock to avoid excessive drawing. This would still not allow things like: <b style="border: 1px solid black">foo</b> but I currently don't see a simple way to make that work. Cheers, Johannes

1 0