November 2007 - Dillo-dev - lists.mailman3.com

forms related segfault

by Johannes.Hofmann＠gmx.de

Hi Jorge, On Sun, Nov 11, 2007 at 03:58:43PM -0300, Jorge Arellano Cid wrote: > 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). just a short update on this issue. There seems to be something more fundamentally wrong on my system. #include "../dlib.h" int main (char **argv, int argc) { Dstr *ds = dStr_new(""); dStr_sprintfa(ds, "Hello %s", "foo"); dStr_sprintfa(ds, "World %d", 42); } crashes here, but it runs fine on Linux and even valgrind does not complain on Linux. Johannes > > -- > Cheers > Jorge.- > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Nov. 12, 2007

Re: image loading from menus

by jcid＠dillo.org

On Sun, Nov 11, 2007 at 10:26:57PM +0000, place wrote: > > On Sun, Nov 11, 2007 at 01:05:30AM +0000, place wrote: > > > > > The right-click menus. I am giving them the linkblock ptr via > > > > > a_UIcmd_*_popup so that they can call Html_load_images > > > > > (well, a_Html_load_images now, by way of a_UIcmd_load_images -- > > > > > if that's the right way to route it.) > > > > > > > > After some study and a reimplentation of plain.cc with classes > > > > (getting rid of its linkblock and hooking a callback for memory > > > > handling), it looks simpler and better. It looks like the same > > > > may be done with html.cc. > > > > > > Has the new html.cc made my problem go away? So far as I can tell, > > > things will be the same: a_UIcmd_page_popup() will need a DilloHtml*, > > > so uicmd.hh will include html.hh. When IO/http.c includes uicmd.hh, > > > it will see #include "dw/core.hh" and #include "lout/misc.hh" in html.hh, > > > and it will not compile. > > > > You can use a void* inside the bw structure (as with render_layout). > > > > It may end being a list in the future. For instance, if we ever implement > > frames, this list could contain the DilloHtml objects for each component > > URL, of a framed page. > > > > The design is not clear yet, but this is one way to implement it. > > I misremembered what you wrote and instead, like the void *vbw going into > a_UIcmd_*_popup(), gave it a void *vpage. Seems to be working and loading > images. Do you think there'd be a good reason to put the html pointer inside > the bw anyway? Yes. It may be useful for handling frames (having access to the DilloHtml object of each URL), or for hooking a menu into a plain image URL (e.g. zoom). > PS The fact that page url != base_url means that various items on the page > menu do not work if a base url is specified. I'll deal with that separately... Ok. -- Cheers Jorge.-

Nov. 12, 2007

Re: image loading from menus

by place＠gobigwest.com

> On Sun, Nov 11, 2007 at 01:05:30AM +0000, place wrote: > > > > The right-click menus. I am giving them the linkblock ptr via > > > > a_UIcmd_*_popup so that they can call Html_load_images > > > > (well, a_Html_load_images now, by way of a_UIcmd_load_images -- > > > > if that's the right way to route it.) > > > > > > After some study and a reimplentation of plain.cc with classes > > > (getting rid of its linkblock and hooking a callback for memory > > > handling), it looks simpler and better. It looks like the same > > > may be done with html.cc. > > > > Has the new html.cc made my problem go away? So far as I can tell, > > things will be the same: a_UIcmd_page_popup() will need a DilloHtml*, > > so uicmd.hh will include html.hh. When IO/http.c includes uicmd.hh, > > it will see #include "dw/core.hh" and #include "lout/misc.hh" in html.hh, > > and it will not compile. > > You can use a void* inside the bw structure (as with render_layout). > > It may end being a list in the future. For instance, if we ever implement > frames, this list could contain the DilloHtml objects for each component > URL, of a framed page. > > The design is not clear yet, but this is one way to implement it. I misremembered what you wrote and instead, like the void *vbw going into a_UIcmd_*_popup(), gave it a void *vpage. Seems to be working and loading images. Do you think there'd be a good reason to put the html pointer inside the bw anyway? PS The fact that page url != base_url means that various items on the page menu do not work if a base url is specified. I'll deal with that separately...

Nov. 11, 2007

Re: image loading from menus

by jcid＠dillo.org

On Sun, Nov 11, 2007 at 01:05:30AM +0000, place wrote: > > > The right-click menus. I am giving them the linkblock ptr via > > > a_UIcmd_*_popup so that they can call Html_load_images > > > (well, a_Html_load_images now, by way of a_UIcmd_load_images -- > > > if that's the right way to route it.) > > > > After some study and a reimplentation of plain.cc with classes > > (getting rid of its linkblock and hooking a callback for memory > > handling), it looks simpler and better. It looks like the same > > may be done with html.cc. > > Has the new html.cc made my problem go away? So far as I can tell, > things will be the same: a_UIcmd_page_popup() will need a DilloHtml*, > so uicmd.hh will include html.hh. When IO/http.c includes uicmd.hh, > it will see #include "dw/core.hh" and #include "lout/misc.hh" in html.hh, > and it will not compile. You can use a void* inside the bw structure (as with render_layout). It may end being a list in the future. For instance, if we ever implement frames, this list could contain the DilloHtml objects for each component URL, of a framed page. The design is not clear yet, but this is one way to implement it. -- Cheers Jorge.-

Nov. 11, 2007

Re: is the visited_color pref somehow deprecated?

by place＠gobigwest.com

Jorge 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! :-) I've had it set for weeks now, and it seems to work fine for me. Oh, speaking of colors, what do you consider to be the proper behavior for buttons? My text color is set to white, so buttons have white text on a nearly-white background. Should the button not use the text color, or should the button background color be some sort of modification of the page background color, or...?

Nov. 11, 2007

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