- Dillo-dev - lists.mailman3.com

[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

Segmentation fault on startup

by jameslovejoy＠tiscali.co.uk

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. Regards, James

Sept. 11, 2010

Commit bit: WAS Re: [Dillo-dev] [patch]: html.cc: re-indent Html_tag_open_q() for consistency

by onepoint＠starurchin.org

Johannes Hofmann wrote: > BTW, don't you have a commit bit (or how is it called with DVCS's)? Not at the moment. I have considered asking but it's been a long while since I have felt comfortable making a serious long-term commitment to working on dillo. I'm very happy to contribute as and when I can but I wouldn't want anyone expecting me to be active, say, in six month's time. Also, I don't feel I know what the long-term plan for dillo is, in terms of priorities and directions. My impression (perhaps wrongly) is that the discussion happens elsewhere (although it does surface on this list every now and then). So I wouldn't feel comfortable doing non-trivial stuff without the other dev's review. But maybe that's over-cautious. If everyone's time would be more effectively used if I had a commit bit then I'm happy to have one. I feel a bit one-of-a-kind in the Dillo world. Is there anyone else in the class of "not a core dev but a long-time contributor"? Regards, Jeremy Henty

Sept. 7, 2010

[patch]: html.cc: re-indent Html_tag_open_q() for consistency

by Johannes.Hofmann＠gmx.de

On Mon, Sep 06, 2010 at 09:31:22PM +0100, Jeremy Henty wrote: > > The wise say you shouldn't sweat the small stuff, but when one > function in a file is indented by 4 spaces and all the rest are > indented by 3, well... Committed! BTW, don't you have a commit bit (or how is it called with DVCS's)? Cheers, Johannes

Sept. 6, 2010