- Dillo-dev - lists.mailman3.com

forms related segfault

by jcid＠dillo.org

On Thu, Nov 08, 2007 at 07:01:40PM +0000, place wrote: > Johannes wrote: > > when I go to e.g. www.google.com enter a search, click submit and then > > when the result page shows up hit Enter, I always get a segfault: > > > It might not be the same problem, and I don't know whether it's > a reasonable fix, but I used to have a lot of trouble with forms crashing > until I did the following: > > > diff -pur dw2/dw/fltkui.cc dw2-cur/dw/fltkui.cc > --- dw2/dw/fltkui.cc 2007-10-06 22:03:01.000000000 +0000 > +++ dw2-cur/dw/fltkui.cc 2007-11-04 01:46:01.000000000 +0000 > @@ -40,6 +40,7 @@ > #include <fltk/Symbol.h> > #include <fltk/Item.h> > #include <fltk/ItemGroup.h> > +#include <fltk/events.h> > > namespace dw { > namespace fltk { > @@ -467,7 +468,8 @@ void FltkEntryResource::widgetCallback ( > void *data) > { > printf ("when = %d\n", widget->when ()); > - if (widget->when () & ::fltk::WHEN_ENTER_KEY_ALWAYS) > + if ((widget->when () & ::fltk::WHEN_ENTER_KEY_ALWAYS) && > + (::fltk::event_key() == ::fltk::ReturnKey)) > ((FltkEntryResource*)data)->emitActivate (); > } I didn't remember why I made it long ago for ui.cc, fortunately some testing showed the reason. Patch committed with the following comment: /* The (::fltk::event_key() == ::fltk::ReturnKey) test * is necessary because WHEN_ENTER_KEY also includes * other events we're not interested in. For instance pressing * The Back or Forward, buttons, or the first click on a rendered * page. BUG: this must be investigated and reported to FLTK2 team */ -- Cheers Jorge.-

Nov. 11, 2007

forms related segfault

by jcid＠dillo.org

On Sun, Nov 11, 2007 at 02:22:39PM +0100, Johannes Hofmann wrote: > Hi Jorge, > > On Sat, Nov 10, 2007 at 07:15:59PM -0300, Jorge Arellano Cid wrote: > > Hi, > > > > The big patch for html.cc getting rid of the linkblock and html > > structures, merging them in a single class with link-receiver inside, > > and also enabling freeing of the resources formerly stored in the > > linkblock, is commited! :-) > > > > The amazing thing is that it seems to work. ;) > > Wow, that's a huge cleanup! Yes it was! 8-P > > On Fri, Nov 09, 2007 at 09:34:33AM -0300, Jorge Arellano Cid wrote: > > > Hi, > > > > > > On Fri, Nov 09, 2007 at 09:09:26AM -0300, Jorge Arellano Cid wrote: > > > > [...] > > > > As a side effect of flickering, I noticed several times how some > > > > non existent inputs (text entries and buttons) were phantom-rendered > > > > during updates (i.e. appeared on screen for a few jiffies). > > > > > > > > [...] > > > > > > For instance, enable flickering (disable double-buffer and > > > internal buffer), then go to: > > > > > > 1. www.google.com //and then to > > > 2. chlamydia.fs.ei.tum.de/pub/DragonFly/packages/stable/DragonFly-1.10/All/ > > > > > > While loading the second URL you'll see the phantom-rendering > > > of the text input and the two buttons that google uses. > > > > > > Although now we have memory-freeing hooked, the phantom > > rendering still occurs... > > Yes, maybe it has to do with how dillo widgets must be deleted. > There was recently a discussion about this in the fltk forums. > I will try to figure out what happens. But at the moment I get > various sorts of crashes with this patch immediately when I load a > page with forms. Here it doesn't crash, but it's sure the phantom widgets are referencing freed memory (it get garbage labels). You can comment: dw->setDeleteCallback(a_Html_free, this); and test as it was before the patch (with no memory freeing). -- Cheers Jorge.-

Nov. 11, 2007

Re: is the visited_color pref somehow deprecated?

by jcid＠dillo.org

On Sun, Nov 11, 2007 at 05:04:59PM +0000, place wrote: > dillorc2 doesn't list it, but if you have force_my_colors set and you > don't know to add visited_color to the rc, you get stuck with purple, > which is not optimal on a black background... No it's not deprecated. I tried to add the working options in dillorc2 only. Patch is welcomed! :-) -- Cheers Jorge.-

Nov. 11, 2007

forms related segfault

by Johannes.Hofmann＠gmx.de

Hi Jorge, On Sat, Nov 10, 2007 at 07:15:59PM -0300, Jorge Arellano Cid wrote: > Hi, > > The big patch for html.cc getting rid of the linkblock and html > structures, merging them in a single class with link-receiver inside, > and also enabling freeing of the resources formerly stored in the > linkblock, is commited! :-) > > The amazing thing is that it seems to work. ;) Wow, that's a huge cleanup! > > > On Fri, Nov 09, 2007 at 09:34:33AM -0300, Jorge Arellano Cid wrote: > > Hi, > > > > On Fri, Nov 09, 2007 at 09:09:26AM -0300, Jorge Arellano Cid wrote: > > > [...] > > > As a side effect of flickering, I noticed several times how some > > > non existent inputs (text entries and buttons) were phantom-rendered > > > during updates (i.e. appeared on screen for a few jiffies). > > > > > > [...] > > > > For instance, enable flickering (disable double-buffer and > > internal buffer), then go to: > > > > 1. www.google.com //and then to > > 2. chlamydia.fs.ei.tum.de/pub/DragonFly/packages/stable/DragonFly-1.10/All/ > > > > While loading the second URL you'll see the phantom-rendering > > of the text input and the two buttons that google uses. > > > Although now we have memory-freeing hooked, the phantom > rendering still occurs... Yes, maybe it has to do with how dillo widgets must be deleted. There was recently a discussion about this in the fltk forums. I will try to figure out what happens. But at the moment I get various sorts of crashes with this patch immediately when I load a page with forms. Here are two stacks, but I don't think they are very useful. Program received signal SIGBUS, Bus error. 0x08097a03 in split ( str=0x28807f70 '?' <repeats 144 times> <Error reading address 0x28808000: Bad address>, W=95, flags=262656, getwidth=0x80a39a6 <fltk::getwidth(char const*, int)>) at drawtext.cxx:493 493 if (!*p || *p == '\n') { (gdb) bt #0 0x08097a03 in split ( str=0x28807f70 '?' <repeats 144 times> <Error reading address 0x28808000: Bad address>, W=95, flags=262656, getwidth=0x80a39a6 <fltk::getwidth(char const*, int)>) at drawtext.cxx:493 #1 0x08097c74 in fltk::drawtext ( textfunction=0x80a3756 <fltk::drawtext_transformed(char const*, int, float, float)>, getwidth=0x80a39a6 <fltk::getwidth(char const*, int)>, str=0x28807f70 '?' <repeats 144 times> <Error reading address 0x28808000: Bad address>, r=@0xbfbff288, flags=262656) at drawtext.cxx:571 #2 0x08098296 in fltk::drawtext ( str=0x28807f70 '?' <repeats 144 times> <Error reading address 0x28808000: Bad address>, r1=@0xbfbff348, flags=262656) at drawtext.cxx:544 #3 0x080e38af in fltk::LabelType::draw (this=0x8127b14, label=0x28807f70 '?' <repeats 144 times> <Error reading address 0x28808000: Bad address>, r=@0xbfbff348, flags=262656) at Widget_draw.cxx:58 #4 0x080e3575 in fltk::Widget::draw_label (this=0x2878ecc0, ir=@0xbfbff40c, flags=262656) at Widget_draw.cxx:234 #5 0x08094089 in fltk::Button::draw (this=0x2878ecc0, glyph_width=0) at Button.cxx:237 #6 0x080940df in fltk::Button::draw (this=0x2878ecc0) at Button.cxx:247 #7 0x080a4441 in fltk::Group::draw_child (this=0x284efc04, w=@0x2878ecc0) at Group.cxx:750 #8 0x080a4634 in fltk::Group::draw (this=0x284efc04) at Group.cxx:682 #9 0x0807ebad in dw::fltk::FltkViewBase::draw (this=0x284efc00) at fltkviewbase.cc:53 #10 0x0807c560 in dw::fltk::FltkViewport::draw_area (data=0x284efc00, cr=@0xbfbff5a0) at fltkviewport.cc:164 #11 0x0807c67f in dw::fltk::FltkViewport::draw (this=0x284efc00) at fltkviewport.cc:189 #12 0x080a4319 in fltk::Group::update_child (this=0x284f1c00, w=@0x284efc04) at Group.cxx:769 #13 0x080a46d6 in fltk::Group::draw (this=0x284f1c00) at Group.cxx:697 #14 0x080e4d14 in fltk::Window::draw (this=0x284f1c00) at Window.cxx:80 #15 0x080c228e in fltk::Window::flush (this=0x284f1c00) at run.cxx:2611 #16 0x080c1366 in fl_window_flush (window=0x284f1c00) at run.cxx:651 #17 0x080c13e6 in fltk::flush () at run.cxx:685 #18 0x080c7708 in fltk::wait (time_to_wait=1.00000002e+20) at run.cxx:480 #19 0x080c7758 in fltk::run () at run.cxx:393 #20 0x0804e6d4 in main (argc=Error accessing memory address 0x40200: Bad address. ) at dillo.cc:107 dillo-fltk in realloc(): error: junk pointer, too high to make sense Program received signal SIGABRT, Aborted. 0x2838863c in kill () from /usr/lib/libc.so.6 (gdb) bt #0 0x2838863c in kill () from /usr/lib/libc.so.6 #1 0x283d6bc9 in abort () from /usr/lib/libc.so.6 #2 0x283a49a2 in reallocf () from /usr/lib/libc.so.6 #3 0x283a49d9 in reallocf () from /usr/lib/libc.so.6 #4 0x283a6420 in realloc () from /usr/lib/libc.so.6 #5 0x08068ad9 in dRealloc (mem=0xd0d0d0d0, size=676212922) at dlib.c:44 #6 0x08068d6d in dStr_resize (ds=0x284e3400, n_sz=676212922, keep=Variable "keep" is not available. ) at dlib.c:189 #7 0x08068db7 in dStr_vsprintfa (ds=0x284e3400, format=0x80f8d8c "the required DOCTYPE declaration is missing (or invalid)\n", argp=0xbfbfd348 "??????\005\bB\205\002") at dlib.c:361 #8 0x0805a5cc in Html_msg (html=0x28535b00, format=0x80f8d8c "the required DOCTYPE declaration is missing (or invalid)\n") at html.cc:176 #9 0x0805f8f2 in Html_write_raw (html=0x28535b00, buf=0x28519000 "<html><head><meta http-equiv=\"content-type\" content=\"text/html; charset=ISO-8859-1\"><title>Google</title><style>body,td,a,p,.h{font-family:arial,sans-serif}.h{font-size:20px}.h{color:#3366cc}.q{color:"..., bufsize=1122, Eof=0) at html.cc:4645 #10 0x0805fac5 in DilloHtml::write (this=0x28535b00, Buf=0x28519000 "<html><head><meta http-equiv=\"content-type\" content=\"text/html; charset=ISO-8859-1\"><title>Google</title><style>body,td,a,p,.h{font-family:arial,sans-serif}.h{font-size:20px}.h{color:#3366cc}.q{color:"..., BufSize=1122, Eof=0) at html.cc:649 #11 0x0805fb3e in Html_callback (Op=0, Client=0x28548900) at html.cc:4971 #12 0x08057032 in Cache_process_queue (entry=0x2853bda0) at cache.c:802 #13 0x08055732 in a_Chain_fcb (Op=2, Info=0x2850cec0, Data1=0x28542d40, Data2=0x80f824e) at chain.c:86 #14 0x0806b1aa in a_Dpi_ccc (Op=2, Branch=2, Dir=1, Info=0x2850cec0, Data1=0x28542ea0, Data2=0x0) at dpi.c:224 #15 0x08055732 in a_Chain_fcb (Op=2, Info=0x2850c040, Data1=0x28542ea0, Data2=0x0) at chain.c:86 #16 0x0806b925 in a_IO_ccc (Op=2, Branch=2, Dir=1, Info=0x2850c040, Data1=0x285487a0, Data2=0x0) at IO.c:398 #17 0x0806bb26 in IO_callback (fd=Variable "fd" is not available. ) at IO.c:190 #18 0x0806bbf3 in IO_fd_read_cb (fd=6, data=0x4) at IO.c:269 #19 0x080c75a6 in fl_wait (time_to_wait=1.00000002e+20) at run.cxx:456 #20 0x080c7641 in fltk::wait (time_to_wait=1.00000002e+20) at run.cxx:457 #21 0x080c7758 in fltk::run () at run.cxx:393 I will try to run in with valgrind when I have access to a Linux machine. Cheers, Johannes

Nov. 11, 2007

Re: patch: save filename/dir

by jcid＠dillo.org

On Sat, Nov 10, 2007 at 11:09:26PM +0000, place wrote: > When I went to save a file, the suggested filename still had the > anchor suffix. Saw from my old tree that URL_PATH() was what I wanted. > Changed that. > > Since I was right there already and there was a comment about a > save dir pref, I added one to prefs.*. > Committed! -- Cheers Jorge.-

Nov. 11, 2007

[patch] fix bug in new scrolling code

by jcid＠dillo.org

On Sat, Nov 10, 2007 at 10:51:29AM +0100, Johannes Hofmann wrote: > Hi, > > when scrolling using the down arrow key I saw occasionally > screen corruptions. The patch below fixes this for me. Committed. > BTW. the following little program helped me debugging this and might be > useful for others with too fast machines. It hogs the > CPU, so dillo redraws are much slower and easier to follow: > > int main(int argc, char **argv) { for (;;); } "Unfortunately" my CFS-patched scheduler does a good job with this... :) -- Cheers Jorge.-

Nov. 10, 2007

forms related segfault

by jcid＠dillo.org

Hi, The big patch for html.cc getting rid of the linkblock and html structures, merging them in a single class with link-receiver inside, and also enabling freeing of the resources formerly stored in the linkblock, is commited! :-) The amazing thing is that it seems to work. ;) On Fri, Nov 09, 2007 at 09:34:33AM -0300, Jorge Arellano Cid wrote: > Hi, > > On Fri, Nov 09, 2007 at 09:09:26AM -0300, Jorge Arellano Cid wrote: > > [...] > > As a side effect of flickering, I noticed several times how some > > non existent inputs (text entries and buttons) were phantom-rendered > > during updates (i.e. appeared on screen for a few jiffies). > > > > [...] > > For instance, enable flickering (disable double-buffer and > internal buffer), then go to: > > 1. www.google.com //and then to > 2. chlamydia.fs.ei.tum.de/pub/DragonFly/packages/stable/DragonFly-1.10/All/ > > While loading the second URL you'll see the phantom-rendering > of the text input and the two buttons that google uses. Although now we have memory-freeing hooked, the phantom rendering still occurs... > > Now, I thought this was to be deleted from the call in web.cc > (as a children of the top widget or something), but there's > another way to do it that looks like the original idea. Actually, it doesn't look like a good idea. What seems proper is that Dw internally deletes its widget tree, and DilloHtml deletes its non-dw state (as now). > In html parsing we have a structure called the linkblock. This > contains all the data that is needed after the page is parsed and > rendered (mainly forms data), and also dw widgets! > > In html.hh you'll find DilloHtmlLB. Within DilloHtmlLB there's > a vector of DilloHtmlForm, which has a vector of DilloHtmlInput > which holds widgets. > > The linkblock is designed to be freed when the displayed dw is > deleted, but this hook is not currently operative! (this is the > warning you get at html.cc compile time about Html_lb_free not > being called). Well, now there's no linkblock, and everything is inside the DilloHtml class (much cleaner). Memory handling is hooked and it works. > Anyway, when the linkblock-free callback is hooked, those > widgets can be destroyed from Html_lb_free(). Which is mainly > implemented but not yet tested. My mistake: this part is for freeing non-dw data. What _seems_ to happen is that the "Embed" widgets are not being deleted (not yet confirmed though). Feel free to investigate! :-) -- Cheers Jorge.-

Nov. 10, 2007

[patch] fix bug in new scrolling code

by Johannes.Hofmann＠gmx.de

Hi, when scrolling using the down arrow key I saw occasionally screen corruptions. The patch below fixes this for me. BTW. the following little program helped me debugging this and might be useful for others with too fast machines. It hogs the CPU, so dillo redraws are much slower and easier to follow: int main(int argc, char **argv) { for (;;); } Cheers, Johannes diff --git a/dw/fltkviewport.cc b/dw/fltkviewport.cc --- a/dw/fltkviewport.cc +++ b/dw/fltkviewport.cc @@ -311,8 +311,11 @@ void FltkViewport::scroll (int dx, int d { int hdiff = vscrollbar->visible () ? SCROLLBAR_THICKNESS : 0; int vdiff = hscrollbar->visible () ? SCROLLBAR_THICKNESS : 0; - int oldScrollX = scrollX; - int oldScrollY = scrollY; + /* multiple calls to scroll can happen before a redraw occurs. + * scrollDX / scrollDY can therefore be non-zero here. + */ + int oldScrollX = scrollX - scrollDX; + int oldScrollY = scrollY - scrollDY; if (dx == 0 && dy == 0) { return;

Nov. 10, 2007

[patch] make partial redraw requests work

by jcid＠dillo.org

On Fri, Nov 09, 2007 at 10:51:11PM +0100, Johannes Hofmann wrote: > Argh, forget about my last patch please. It was much too complicated. > fltk does all that for us! > The following looks much simpler, doesn't it :-) Yes! > Sorry for the confusion, It looked quite nice! ;-) Reverted and applied in CVS. -- Cheers Jorge.-

Nov. 10, 2007

[patch] make partial redraw requests work

by jcid＠dillo.org

On Fri, Nov 09, 2007 at 08:22:41PM +0100, Johannes Hofmann wrote: > Hi, > > this patch adds set(), isEmpty(), and merge() methods to > core::Rectangle. > These methods are then used to maintain a rectangle that contains > all screen areas for which a redraw was requested. > When fltk really draws to the screen, the drawing is limited to this > area. > The most obvious improvement is visible on pages with very large > images that take some time to load. While the image is loaded the > rest of the page is no longer flickering - at least if there is no > other stuff that requests complete redraws. Committed! -- Cheers Jorge.-

Nov. 10, 2007