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

Segmentation fault on startup

by corvid＠lavabit.com

James wrote: > Changing all fonts to lucida gets rid of the warnings but it still segfaults. If you compile fltk with -g, does the backtrace reveal anything interesting? I don't immediately know that it would matter in this case since I didn't notice any relevant hardcoding in fltk, but just in case...do you know whether fontconfig is set up properly so that "sans" points to a font that you have? > Sent from my iPod Is there a way to disable that advertisement?

Sept. 13, 2010

[bug]: ignored CSS attributes on html element

by onepoint＠starurchin.org

Penny Arcade is illegible in Dillo[1]. The problem is that its CSS sets the text attribute on the html element and Dillo ignores this, so we get black text on blue instead of white text on blue. Here is a demo: <html> <head> <style type="text/css">html{text:#F00;}</style> </head> <body> Blah, blah, blah </body> </html> The text is plain black, but if you change html to body in the CSS then the text is red as it should be. Thoughts on how to fix this? It's not obvious to me whether this is a one-liner patch or something more radical is needed. Regards, Jeremy Henty [1] see http://www.penny-arcade.com/2010/9/10/

Sept. 12, 2010

Segmentation fault on startup

by jameslovejoy＠tiscali.co.uk

Changing all fonts to lucida gets rid of the warnings but it still segfaults. Sent from my iPod On 12 Sep 2010, at 17:17, "corvid" <corvid(a)lavabit.com> wrote: > James wrote: >> I managed to get a backtrace from GDB: >> >> #0 0x080ba0f4 in fltk::setfont(fltk::font*, float) () >> #1 0x080f0e9a in fltk::Widget::measure_label(int&, int&) const () >> #2 0x08051126 in UI::make_filemenu_button (this=0x813de58) at ui.cc:531 >> #3 0x08052691 in UI::make_panel (this=0x813de58, ww=780) at ui.cc:626 >> #4 0x08052e48 in UI (this=0x813de58, x=0, y=0, ww=780, wh=580, >> label=0x81110c4 "Dillo", cur_ui=0x0) at ui.cc:724 >> #5 0x08054fbb in a_UIcmd_browser_window_new (ww=780, wh=580, xid=0, >> vbw=0x0) >> at uicmd.cc:433 >> #6 0x0804f753 in main (argc=1, argv=0xbffffd34) at dillo.cc:334 > > If you edit dillorc to specify fonts that you have, does it work? > > > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Sept. 12, 2010

[patch]: do not require Html_process_word()s argument to be null-terminated

by jcid＠dillo.org

On Sun, Sep 12, 2010 at 01:14:11PM +0100, Jeremy Henty wrote: > > This is almost a trivial cleanup, but I'd be more comfortable if > someone else checked I have not missed anything. (I have been using > it locally for a week or two with no problems so far.) > > Html_process_word() requires its argument to be null-terminated. This > forces Html_write_raw() (the only caller of Html_process_word()) to > write a null character before calling Html_process_word() and restore > the original character afterwards. > > It turns out to be easy to change Html_process_word() to not need the > null-terminator. This eliminates the hack in Html_write_raw() and > lets us make several function arguments "const char *" instead of > "char *". > > It's a little tricky to see that the patch is correct. It works > because none of the functions that Html_process_word() calls require a > null-terminator, and the return value of a_Html_parse_entities() *is* > null-terminated. > > Have I missed anything? If not, I'll push it. A few years ago, parts of the parser were coded not to need null-terminators (for speed's sake). It got really hard to maintain and every time a change was necessary, the whole function-call stack needed a review. Simple semantically good loking patches introduced bugs because library functions couldn't be used there too. One day I decided to use standard null-terminated strings and everything got easier. Not to mention there was no noticeable speed penalty. IOW, I learnt this the hard way! ;) FWIW, profiling has surprised me a few times: once I wrote a minimal perfect hash for matching HTML elements and the added complexity didn't payoff against a simple binary search. -1 -- Cheers Jorge.-

Sept. 12, 2010

Segmentation fault on startup

by jcid＠dillo.org

On Sun, Sep 12, 2010 at 02:39:17PM +0100, James Lovejoy wrote: > Hi, > > I managed to get a backtrace from GDB: > > #0 0x080ba0f4 in fltk::setfont(fltk::font*, float) () > #1 0x080f0e9a in fltk::Widget::measure_label(int&, int&) const () > #2 0x08051126 in UI::make_filemenu_button (this=0x813de58) at ui.cc:531 > #3 0x08052691 in UI::make_panel (this=0x813de58, ww=780) at ui.cc:626 > #4 0x08052e48 in UI (this=0x813de58, x=0, y=0, ww=780, wh=580, > label=0x81110c4 "Dillo", cur_ui=0x0) at ui.cc:724 > #5 0x08054fbb in a_UIcmd_browser_window_new (ww=780, wh=580, > xid=0, vbw=0x0) > at uicmd.cc:433 > #6 0x0804f753 in main (argc=1, argv=0xbffffd34) at dillo.cc:334 It shows the problem is in FLTK's font handling, as in the suggested thread. Please take a look in dillorc, fonts section, to find some hints on how to diagnose. My guess is the target system doesn't have the requested fonts installed, FLTK panics -> segfault. -- Cheers Jorge.-

Sept. 12, 2010

Segmentation fault on startup

by corvid＠lavabit.com

James wrote: > I managed to get a backtrace from GDB: > > #0 0x080ba0f4 in fltk::setfont(fltk::font*, float) () > #1 0x080f0e9a in fltk::Widget::measure_label(int&, int&) const () > #2 0x08051126 in UI::make_filemenu_button (this=0x813de58) at ui.cc:531 > #3 0x08052691 in UI::make_panel (this=0x813de58, ww=780) at ui.cc:626 > #4 0x08052e48 in UI (this=0x813de58, x=0, y=0, ww=780, wh=580, > label=0x81110c4 "Dillo", cur_ui=0x0) at ui.cc:724 > #5 0x08054fbb in a_UIcmd_browser_window_new (ww=780, wh=580, xid=0, > vbw=0x0) > at uicmd.cc:433 > #6 0x0804f753 in main (argc=1, argv=0xbffffd34) at dillo.cc:334 If you edit dillorc to specify fonts that you have, does it work?

Sept. 12, 2010

Segmentation fault on startup

by jameslovejoy＠tiscali.co.uk

Hi, I managed to get a backtrace from GDB: #0 0x080ba0f4 in fltk::setfont(fltk::font*, float) () #1 0x080f0e9a in fltk::Widget::measure_label(int&, int&) const () #2 0x08051126 in UI::make_filemenu_button (this=0x813de58) at ui.cc:531 #3 0x08052691 in UI::make_panel (this=0x813de58, ww=780) at ui.cc:626 #4 0x08052e48 in UI (this=0x813de58, x=0, y=0, ww=780, wh=580, label=0x81110c4 "Dillo", cur_ui=0x0) at ui.cc:724 #5 0x08054fbb in a_UIcmd_browser_window_new (ww=780, wh=580, xid=0, vbw=0x0) at uicmd.cc:433 #6 0x0804f753 in main (argc=1, argv=0xbffffd34) at dillo.cc:334 James ----- Original Message ----- From: "Jorge Arellano Cid" <jcid(a)dillo.org> To: "Dillo mailing list" <dillo-dev(a)dillo.org> Sent: Saturday, September 11, 2010 10:21 PM Subject: Re: [Dillo-dev] Segmentation fault on startup > On Sat, Sep 11, 2010 at 09:51:32PM +0100, James Lovejoy wrote: >> Hi, >> >> Fltk was compiled already with xft support. > > OK, but are the fonts installed? > > -- > Cheers > Jorge.- > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Sept. 12, 2010

[patch]: do not require Html_process_word()s argument to be null-terminated

by onepoint＠starurchin.org

This is almost a trivial cleanup, but I'd be more comfortable if someone else checked I have not missed anything. (I have been using it locally for a week or two with no problems so far.) Html_process_word() requires its argument to be null-terminated. This forces Html_write_raw() (the only caller of Html_process_word()) to write a null character before calling Html_process_word() and restore the original character afterwards. It turns out to be easy to change Html_process_word() to not need the null-terminator. This eliminates the hack in Html_write_raw() and lets us make several function arguments "const char *" instead of "char *". It's a little tricky to see that the patch is correct. It works because none of the functions that Html_process_word() calls require a null-terminator, and the return value of a_Html_parse_entities() *is* null-terminated. Have I missed anything? If not, I'll push it. Regards, Jeremy Henty

Sept. 12, 2010

Segmentation fault on startup

by jcid＠dillo.org

On Sat, Sep 11, 2010 at 09:51:32PM +0100, James Lovejoy wrote: > Hi, > > Fltk was compiled already with xft support. OK, but are the fonts installed? -- Cheers Jorge.-

Sept. 11, 2010

Segmentation fault on startup

by jcid＠dillo.org

On Sat, Sep 11, 2010 at 08:38:16PM +0100, James Lovejoy wrote: > Hi, > > I'm creating a new distro that is supposed to be fast and light. I thought about Firefox but it all stacks up after you install gtk as well. So your slogan "fast and light" seemed sound the ticket. > > I compiled it on my ubuntu 10.04 system and it works on there. Copied it to the new distro and here is the output when I type "dillo" at the prompt: > > dillo: /lib/libjpeg.so.8: no version information available (required by dillo) > paths: Cannot open file '/root/.dillo/dillorc' > paths: Using /usr/local/etc/dillo/dillorc > paths: Cannot open file '/root/.dillo/keysrc' > paths: Using /usr/local/etc/dillo/keysrc > dillo_dns_init: Here we go! (threaded) > Disabling cookies. > ** WARNING **: preferred sans-serif font "DejaVu Sans" not found. > ** WARNING **: preferred serif font "DejaVu Serif" not found. > ** WARNING **: preferred monospace font "DejaVu mono" not found. > ** WARNING **: preferred cursive font "DejaVu Sans" not found. > ** WARNING **: preferred fantasy font "DejaVu Sans" not found. > Segmentation fault > > I can't get a backtrace from GDB because it's supposed to be a mega minimal > system. It works fine on the development system. It looks like an FLTK font handling problem. This thread may help: http://lists.auriga.wearlab.de/pipermail/dillo-dev/2010-June/007523.html -- Cheers Jorge.-

Sept. 11, 2010