- Dillo-dev - lists.mailman3.com

dillo-3.0 is on site for testing!

by corvid＠lavabit.com

In doc/README, we overlooked "For user help, see http://www.dillo.org/dillo2-help.html"

Sept. 7, 2011

dillo-3.0 is on site for testing!

by abe＠deuxchevaux.org

Hi, On Tue, Sep 06, 2011 at 11:36:17PM +0200, Johannes Hofmann wrote: > On Tue, Sep 06, 2011 at 06:26:15PM -0300, Jorge Arellano Cid wrote: > > This should be our last release candidate, unless something major > > appears. Please download, build, test and report how it goes. > > Compiles and runs fine on DragonFly 2.11-DEVELOPMENT Builds and works fine on Debian Sid, too. I uploaded it to Debian Experimental as 3.0~rc3-1. Will upload it to Debian Unstable as soon as it's declared as stable release. :) Kind regards, Axel -- /~\ Plain Text Ribbon Campaign | Axel Beckert \ / Say No to HTML in E-Mail and News | abe at deuxchevaux.org (Mail) X See http://www.asciiribbon.org/ | abe at noone.org (Mail+Jabber) / \ I love long mails: http://email.is-not-s.ms/ | http://noone.org/abe/ (Web)

Sept. 7, 2011

dillo_port1.3 only opens so many tabs, then stops opening more tabs

by rogerx.oss＠gmail.com

> We're using hg "dillo" not "dillo_port1.3" since some time. > > Please check the just uploaded tarball. Eh. I was hoping to see dillo_port1.3 removed and getting an error when trying to fetch here, before re-editing my get/make scripting. (lazy me.) -- Roger http://rogerx.freeshell.org/

Sept. 7, 2011

dillo-3.0 is on site for testing!

by Johannes.Hofmann＠gmx.de

On Tue, Sep 06, 2011 at 06:26:15PM -0300, Jorge Arellano Cid wrote: > Hi there, > > After a long list of fixes and features: > > [ok] moveToWidget(). Jorge has code for this. > [ok] downloads dpi string escaping. > [ok] alt text wrapping (which looks like a nice feature). > [ok] remove large panel. > [ok] https dialog storm (BUG#868). > [ok] The findbar input doesn't know about Ctrl+{a,e,d,k}. > [ok] something other than "ctab%d" for initial tab label. > [ok] single close tab button with tooltip. > [ok] valgrind logs: close window > [ok] valgrind logs: cancel expected url > [ok] segfault with Ctrl-s (web search) > [ok] UI_TEMPORARILY_SHOW_PANELS > [ok] leave link into a native FLTK widget > [ok] remove pointeronlink(), panelmode_cb_i() > [ok] the panel problems when resizing from very small. > [ok] resize problems when tabs overflow > [ok] URL_ILLEGAL_CHARS > [ok] Fixed CustLightButton "light" color deactivation. > [ok] hoverTooltip glitch (tooltip linger when going into a child DIV). > [ok] tab overflow (code a handler) > [ok] valgrind error for first tab close, then resize(). > [ok] update the Changelog > [ok] update links in splash page > [ok] default search engine > [ok] new-tab and window title > [ok] CSS adjacent sibling selectors > [ok] margin-bottom + some margin collapse > [ok] fix doctree leak > [ok] first click on a link missed after middle-click on a scrollbar > [ok] Fix redraw loops and reenable limit_text_width dillorc option > > > dillo-3.0 is available from: > > http://www.dillo.org/download/ > > > This should be our last release candidate, unless something major > appears. Please download, build, test and report how it goes. Compiles and runs fine on DragonFly 2.11-DEVELOPMENT

Sept. 6, 2011

dillo_port1.3 only opens so many tabs, then stops opening more tabs

by jcid＠dillo.org

On Tue, Sep 06, 2011 at 12:25:14PM -0800, Roger wrote: > > On Tue, Sep 06, 2011 at 12:21:18PM -0800, Roger wrote: > >I just noticed, pulling a git/svn/cvs copy yesterday, I can only open so many > >tabs (screen/display width?) and then Dill will stop opening new tabs after a > >link is clicked to open in a new tab. > > > >The only thing printed within the startx stdout is > >"Nav_open_url:(include_clicked_url_here) and no other activity such as > >"a_Nav_expect_done: repush!" or "[cookies dpi]:" etc... > > Well, looks like in the above paragraph, I insinuated Dillo as not loading > pages at all, but looks like it was loading from cache instead. > > Right now, I do see the other tabs after closing some of the tabs. Seems the > tabs are falling off the edge of the display and there's no way of knowing > there's additional tabs as Dillo/FLTK doesn't resize the tab buttons? We're using hg "dillo" not "dillo_port1.3" since some time. Please check the just uploaded tarball. A full tabs handler (with GUI scroller etc) is scheduled for 3.0.1. At the moment you can reach those tabs with the keyboard and notice their existence by looking at the edge tab (incomplete rendering). HTH. -- Cheers Jorge.-

Sept. 6, 2011

dillo-3.0 is on site for testing!

by jcid＠dillo.org

Hi there, After a long list of fixes and features: [ok] moveToWidget(). Jorge has code for this. [ok] downloads dpi string escaping. [ok] alt text wrapping (which looks like a nice feature). [ok] remove large panel. [ok] https dialog storm (BUG#868). [ok] The findbar input doesn't know about Ctrl+{a,e,d,k}. [ok] something other than "ctab%d" for initial tab label. [ok] single close tab button with tooltip. [ok] valgrind logs: close window [ok] valgrind logs: cancel expected url [ok] segfault with Ctrl-s (web search) [ok] UI_TEMPORARILY_SHOW_PANELS [ok] leave link into a native FLTK widget [ok] remove pointeronlink(), panelmode_cb_i() [ok] the panel problems when resizing from very small. [ok] resize problems when tabs overflow [ok] URL_ILLEGAL_CHARS [ok] Fixed CustLightButton "light" color deactivation. [ok] hoverTooltip glitch (tooltip linger when going into a child DIV). [ok] tab overflow (code a handler) [ok] valgrind error for first tab close, then resize(). [ok] update the Changelog [ok] update links in splash page [ok] default search engine [ok] new-tab and window title [ok] CSS adjacent sibling selectors [ok] margin-bottom + some margin collapse [ok] fix doctree leak [ok] first click on a link missed after middle-click on a scrollbar [ok] Fix redraw loops and reenable limit_text_width dillorc option dillo-3.0 is available from: http://www.dillo.org/download/ This should be our last release candidate, unless something major appears. Please download, build, test and report how it goes. If there's no show stopper in a couple of days, the announcement to the outside world will be made. ;) -- Cheers Jorge.-

Sept. 6, 2011

dillo_port1.3 only opens so many tabs, then stops opening more tabs

by rogerx.oss＠gmail.com

> On Tue, Sep 06, 2011 at 12:21:18PM -0800, Roger wrote: >I just noticed, pulling a git/svn/cvs copy yesterday, I can only open so many >tabs (screen/display width?) and then Dill will stop opening new tabs after a >link is clicked to open in a new tab. > >The only thing printed within the startx stdout is >"Nav_open_url:(include_clicked_url_here) and no other activity such as >"a_Nav_expect_done: repush!" or "[cookies dpi]:" etc... Well, looks like in the above paragraph, I insinuated Dillo as not loading pages at all, but looks like it was loading from cache instead. Right now, I do see the other tabs after closing some of the tabs. Seems the tabs are falling off the edge of the display and there's no way of knowing there's additional tabs as Dillo/FLTK doesn't resize the tab buttons? -- Roger http://rogerx.freeshell.org/

Sept. 6, 2011

dillo_port1.3 only opens so many tabs, then stops opening more tabs

by rogerx.oss＠gmail.com

I just noticed, pulling a git/svn/cvs copy yesterday, I can only open so many tabs (screen/display width?) and then Dill will stop opening new tabs after a link is clicked to open in a new tab. The only thing printed within the startx stdout is "Nav_open_url:(include_clicked_url_here) and no other activity such as "a_Nav_expect_done: repush!" or "[cookies dpi]:" etc... -- Roger http://rogerx.freeshell.org/

Sept. 6, 2011

page that redraws endlessly

by Johannes.Hofmann＠gmx.de

On Tue, Sep 06, 2011 at 10:20:38AM -0300, Jorge Arellano Cid wrote: > On Mon, Sep 05, 2011 at 09:39:57PM +0200, Johannes Hofmann wrote: > > On Mon, Sep 05, 2011 at 12:41:55PM -0300, Jorge Arellano Cid wrote: > > > On Mon, Sep 05, 2011 at 12:11:24AM +0200, Johannes Hofmann wrote: > > > > > [...] > > > I don't know this part of the code well enough to say whether it > > > is safe to commit before the release or not. > > > > Actually I would suggest to commit attached patch. > > I have to admit that I'm not 100% sure about the ui.cc change, but > > it seems better than just always passing true or false. > > AFAIS, it looks more correct. > > > The form.cc part makes sense, as limitTextWidth in > > textblock.cc seems to matter only if layout->getUsesViewport () > > returns true, which is not the case for FltkFlatView in the > > FltkComplexButton case. > > > > corvid, Jorge, what do you think? > > It works in the testcases (even outside forms), so I'd commit > an release with it. > > > > > > > FWIW, WRT complexity, if you resize the window with the patch, > > > over the testcase, it is quite clear that the last phrase is not > > > measured right. > > > > Yes, there is an issue, but I don't think it's related to the > > ComplexButton stuff. > > Sure, it's related to whitespace handling in the textblock, > which needs a full review. > > > > <table> > > <tr> > > <td> > > <hr/> > > <div> > > words words words words words words words words words words words > > words words words words words words words words words words words > > words words words words words words words words words words words > > words words words words words words words words words words words > > <span style="white-space:nowrap">And words in a span</span> > > </div> > > </td> > > </table> > > > > looks similarily weird here, or am I missing something? > > I'm using an even simpler testcase: > > <table> > <tr> > <td> > words words words words words words words words words words words > words words words words words words words words words words words > <span style="white-space:nowrap">And words in a span</span> > <button></button> > </td> > </table> > > > BTW, with regard to the patch, I'd keep the comment in the code, > something like: > > > + /* BUG: should be "Textblock (prefs.limit_text_width);", > > - * It caused 100% CPU usage with <button> or <input type="image"> > > + * long ago and needs a review before re-enabling it. */ > > - page = new Textblock (prefs.limit_text_width); > > + page = new Textblock (false); > > page->setStyle (html->styleEngine->backgroundStyle ()); > > Committed with slightly different wording in the comment, as I don't think using prefs.limit_text_width is correct in this case. Cheers, Johannes

Sept. 6, 2011

Query dpid or running dillos

by Johannes.Hofmann＠gmx.de

On Tue, Sep 06, 2011 at 12:55:57PM -0400, Dennis Nezic wrote: > Is there a way to query dillo (or dpid?) for the links it currently > has open? (dpidc/dillo don't seem to have such an option :p) Not quite sure what you mean. Are you interested in all URLs a dillo process is currently displaying in all it's windows or tabs? > > "dillo --xid XID" is able to access a specific window... but I guess > there is no way to currently read that "property" (link). Hm, the --xid option is used to embed a dillo window into another one. This needs a program that knows how to do that. We implemented it for use with the claws mail program and I also tested it with tabbed (http://tools.suckless.org/tabbed) In which context are you using the --xid option? > > (Oh, speaking of which, the "--xid XID" feature is buggy here ... it > loads the link, but renders with a wide (200pixel-ish?) margin on the > left, which doesn't match the actual clickable button/link-areas on the > page. Dillo version 2.2.1, fltk-1.3.0.) Again, in which context are you using the --xid option? Cheers, Johannes

Sept. 6, 2011

Query dpid or running dillos

by dennisn＠dennisn.dyndns.org

Is there a way to query dillo (or dpid?) for the links it currently has open? (dpidc/dillo don't seem to have such an option :p) "dillo --xid XID" is able to access a specific window... but I guess there is no way to currently read that "property" (link). (Oh, speaking of which, the "--xid XID" feature is buggy here ... it loads the link, but renders with a wide (200pixel-ish?) margin on the left, which doesn't match the actual clickable button/link-areas on the page. Dillo version 2.2.1, fltk-1.3.0.)

Sept. 6, 2011

page that redraws endlessly

by jcid＠dillo.org

On Mon, Sep 05, 2011 at 09:39:57PM +0200, Johannes Hofmann wrote: > On Mon, Sep 05, 2011 at 12:41:55PM -0300, Jorge Arellano Cid wrote: > > On Mon, Sep 05, 2011 at 12:11:24AM +0200, Johannes Hofmann wrote: > > [...] > > I don't know this part of the code well enough to say whether it > > is safe to commit before the release or not. > > Actually I would suggest to commit attached patch. > I have to admit that I'm not 100% sure about the ui.cc change, but > it seems better than just always passing true or false. AFAIS, it looks more correct. > The form.cc part makes sense, as limitTextWidth in > textblock.cc seems to matter only if layout->getUsesViewport () > returns true, which is not the case for FltkFlatView in the > FltkComplexButton case. > > corvid, Jorge, what do you think? It works in the testcases (even outside forms), so I'd commit an release with it. > > > > FWIW, WRT complexity, if you resize the window with the patch, > > over the testcase, it is quite clear that the last phrase is not > > measured right. > > Yes, there is an issue, but I don't think it's related to the > ComplexButton stuff. Sure, it's related to whitespace handling in the textblock, which needs a full review. > <table> > <tr> > <td> > <hr/> > <div> > words words words words words words words words words words words > words words words words words words words words words words words > words words words words words words words words words words words > words words words words words words words words words words words > <span style="white-space:nowrap">And words in a span</span> > </div> > </td> > </table> > > looks similarily weird here, or am I missing something? I'm using an even simpler testcase: <table> <tr> <td> words words words words words words words words words words words words words words words words words words words words words words <span style="white-space:nowrap">And words in a span</span> <button></button> </td> </table> BTW, with regard to the patch, I'd keep the comment in the code, something like: > + /* BUG: should be "Textblock (prefs.limit_text_width);", > - * It caused 100% CPU usage with <button> or <input type="image"> > + * long ago and needs a review before re-enabling it. */ > - page = new Textblock (prefs.limit_text_width); > + page = new Textblock (false); > page->setStyle (html->styleEngine->backgroundStyle ()); > -- Cheers Jorge.-

Sept. 6, 2011

page that redraws endlessly

by Johannes.Hofmann＠gmx.de

On Mon, Sep 05, 2011 at 12:41:55PM -0300, Jorge Arellano Cid wrote: > On Mon, Sep 05, 2011 at 12:11:24AM +0200, Johannes Hofmann wrote: > > On Sun, Sep 04, 2011 at 10:51:10PM +0200, Johannes Hofmann wrote: > > > On Sun, Sep 04, 2011 at 10:05:22PM +0200, Johannes Hofmann wrote: > > > > On Sun, Sep 04, 2011 at 07:15:09PM +0000, corvid wrote: > > > > > Johannes wrote: > > > > > > Thanks for the cleaned up test case. It's still remarkably complex. > > > > > > I see the issue also with dillo-2.1.1. Nevertheless we should > > > > > > definately try to fix it. I will play with it a bit... > > > > > > > > > > I wonder whether it is just the limit_text_width button problem dressed > > > > > up in more complex clothing. > > > > > > > > As funny as it sounds, hg bisect says it's rev 6a892184d498 where it > > > > starts the redraw loop! > > > > And indeed, if I do > > > > > > > > --- a/src/prefsparser.cc Sat Sep 03 01:15:33 2011 +0000 > > > > +++ b/src/prefsparser.cc Sun Sep 04 22:04:18 2011 +0200 > > > > @@ -219,10 +219,11 @@ > > > > setlocale(LC_NUMERIC, oldLocale); > > > > dFree(oldLocale); > > > > > > > > - > > > > +#if 0 > > > > if (prefs.limit_text_width) { > > > > /* BUG: causes 100% CPU usage with <button> or <input type="image"> */ > > > > MSG_WARN("Disabling limit_text_width preference (currently broken).\n"); > > > > prefs.limit_text_width = FALSE; > > > > } > > > > +#endif > > > > } > > > > > > > > it loops with limit_text_width=NO and doesn't with limit_text_width=YES. > > > > > > Ah wait! With limit_text_width=YES it's just not flickering. CPU is > > > still at 100%. > > > > > > The following test patch seems to stop it: > > > > --- a/dw/ui.cc Sat Sep 03 01:15:33 2011 +0000 > > +++ b/dw/ui.cc Mon Sep 05 00:09:33 2011 +0200 > > @@ -268,7 +268,7 @@ > > /** > > * \todo The argument to queueResize is not always true. (But this works.) > > */ > > - resource->queueResize (true); > > + resource->queueResize (false); > > } > > > > Maybe the comment isn't always right? > > Good shot! > > It also serves for another testcase I found. > > I don't know this part of the code well enough to say whether it > is safe to commit before the release or not. Actually I would suggest to commit attached patch. I have to admit that I'm not 100% sure about the ui.cc change, but it seems better than just always passing true or false. The form.cc part makes sense, as limitTextWidth in textblock.cc seems to matter only if layout->getUsesViewport () returns true, which is not the case for FltkFlatView in the FltkComplexButton case. corvid, Jorge, what do you think? > > FWIW, WRT complexity, if you resize the window with the patch, > over the testcase, it is quite clear that the last phrase is not > measured right. Yes, there is an issue, but I don't think it's related to the ComplexButton stuff. <table> <tr> <td> <hr/> <div> words words words words words words words words words words words words words words words words words words words words words words words words words words words words words words words words words words words words words words words words words words words words <span style="white-space:nowrap">And words in a span</span> </div> </td> </table> looks similarily weird here, or am I missing something? Cheers, Johannes

Sept. 5, 2011

page that redraws endlessly

by jcid＠dillo.org

On Mon, Sep 05, 2011 at 12:11:24AM +0200, Johannes Hofmann wrote: > On Sun, Sep 04, 2011 at 10:51:10PM +0200, Johannes Hofmann wrote: > > On Sun, Sep 04, 2011 at 10:05:22PM +0200, Johannes Hofmann wrote: > > > On Sun, Sep 04, 2011 at 07:15:09PM +0000, corvid wrote: > > > > Johannes wrote: > > > > > Thanks for the cleaned up test case. It's still remarkably complex. > > > > > I see the issue also with dillo-2.1.1. Nevertheless we should > > > > > definately try to fix it. I will play with it a bit... > > > > > > > > I wonder whether it is just the limit_text_width button problem dressed > > > > up in more complex clothing. > > > > > > As funny as it sounds, hg bisect says it's rev 6a892184d498 where it > > > starts the redraw loop! > > > And indeed, if I do > > > > > > --- a/src/prefsparser.cc Sat Sep 03 01:15:33 2011 +0000 > > > +++ b/src/prefsparser.cc Sun Sep 04 22:04:18 2011 +0200 > > > @@ -219,10 +219,11 @@ > > > setlocale(LC_NUMERIC, oldLocale); > > > dFree(oldLocale); > > > > > > - > > > +#if 0 > > > if (prefs.limit_text_width) { > > > /* BUG: causes 100% CPU usage with <button> or <input type="image"> */ > > > MSG_WARN("Disabling limit_text_width preference (currently broken).\n"); > > > prefs.limit_text_width = FALSE; > > > } > > > +#endif > > > } > > > > > > it loops with limit_text_width=NO and doesn't with limit_text_width=YES. > > > > Ah wait! With limit_text_width=YES it's just not flickering. CPU is > > still at 100%. > > > The following test patch seems to stop it: > > --- a/dw/ui.cc Sat Sep 03 01:15:33 2011 +0000 > +++ b/dw/ui.cc Mon Sep 05 00:09:33 2011 +0200 > @@ -268,7 +268,7 @@ > /** > * \todo The argument to queueResize is not always true. (But this works.) > */ > - resource->queueResize (true); > + resource->queueResize (false); > } > > Maybe the comment isn't always right? Good shot! It also serves for another testcase I found. I don't know this part of the code well enough to say whether it is safe to commit before the release or not. FWIW, WRT complexity, if you resize the window with the patch, over the testcase, it is quite clear that the last phrase is not measured right. -- Cheers Jorge.-

Sept. 5, 2011

page that redraws endlessly

by jcid＠dillo.org

On Sun, Sep 04, 2011 at 09:00:27PM +0200, Johannes Hofmann wrote: > Thanks for the cleaned up test case. It's still remarkably complex. > I see the issue also with dillo-2.1.1. Nevertheless we should > definately try to fix it. I will play with it a bit... After a short review, it looks non-trivial to me. It involves white space handling, which has a design review pending, and also there's this comment in textblock.cc: /* NOTE: Most code relies on that all values of nowrap are equal for all * words within one line. */ And effectively, the 'nowrap' value is taken from the first word of the line: ws = words->getRef(line->firstWord)->style->whiteSpace; nowrap = ws == core::style::WHITE_SPACE_PRE || ws == core::style::WHITE_SPACE_NOWRAP; Given this is a design issue from long ago (dillo-2.2.1 also has it), and all the testing/debugging such a change requires, I'm for leaving this task for the next release. -- Cheers Jorge.-

Sept. 5, 2011

page that redraws endlessly

by Johannes.Hofmann＠gmx.de

On Sun, Sep 04, 2011 at 10:51:10PM +0200, Johannes Hofmann wrote: > On Sun, Sep 04, 2011 at 10:05:22PM +0200, Johannes Hofmann wrote: > > On Sun, Sep 04, 2011 at 07:15:09PM +0000, corvid wrote: > > > Johannes wrote: > > > > Thanks for the cleaned up test case. It's still remarkably complex. > > > > I see the issue also with dillo-2.1.1. Nevertheless we should > > > > definately try to fix it. I will play with it a bit... > > > > > > I wonder whether it is just the limit_text_width button problem dressed > > > up in more complex clothing. > > > > As funny as it sounds, hg bisect says it's rev 6a892184d498 where it > > starts the redraw loop! > > And indeed, if I do > > > > --- a/src/prefsparser.cc Sat Sep 03 01:15:33 2011 +0000 > > +++ b/src/prefsparser.cc Sun Sep 04 22:04:18 2011 +0200 > > @@ -219,10 +219,11 @@ > > setlocale(LC_NUMERIC, oldLocale); > > dFree(oldLocale); > > > > - > > +#if 0 > > if (prefs.limit_text_width) { > > /* BUG: causes 100% CPU usage with <button> or <input type="image"> */ > > MSG_WARN("Disabling limit_text_width preference (currently broken).\n"); > > prefs.limit_text_width = FALSE; > > } > > +#endif > > } > > > > it loops with limit_text_width=NO and doesn't with limit_text_width=YES. > > Ah wait! With limit_text_width=YES it's just not flickering. CPU is > still at 100%. The following test patch seems to stop it: --- a/dw/ui.cc Sat Sep 03 01:15:33 2011 +0000 +++ b/dw/ui.cc Mon Sep 05 00:09:33 2011 +0200 @@ -268,7 +268,7 @@ /** * \todo The argument to queueResize is not always true. (But this works.) */ - resource->queueResize (true); + resource->queueResize (false); } Maybe the comment isn't always right? Cheers, Johannes

Sept. 5, 2011

page that redraws endlessly

by Johannes.Hofmann＠gmx.de

On Sun, Sep 04, 2011 at 10:05:22PM +0200, Johannes Hofmann wrote: > On Sun, Sep 04, 2011 at 07:15:09PM +0000, corvid wrote: > > Johannes wrote: > > > Thanks for the cleaned up test case. It's still remarkably complex. > > > I see the issue also with dillo-2.1.1. Nevertheless we should > > > definately try to fix it. I will play with it a bit... > > > > I wonder whether it is just the limit_text_width button problem dressed > > up in more complex clothing. > > As funny as it sounds, hg bisect says it's rev 6a892184d498 where it > starts the redraw loop! > And indeed, if I do > > --- a/src/prefsparser.cc Sat Sep 03 01:15:33 2011 +0000 > +++ b/src/prefsparser.cc Sun Sep 04 22:04:18 2011 +0200 > @@ -219,10 +219,11 @@ > setlocale(LC_NUMERIC, oldLocale); > dFree(oldLocale); > > - > +#if 0 > if (prefs.limit_text_width) { > /* BUG: causes 100% CPU usage with <button> or <input type="image"> */ > MSG_WARN("Disabling limit_text_width preference (currently broken).\n"); > prefs.limit_text_width = FALSE; > } > +#endif > } > > it loops with limit_text_width=NO and doesn't with limit_text_width=YES. Ah wait! With limit_text_width=YES it's just not flickering. CPU is still at 100%.

Sept. 4, 2011

page that redraws endlessly

by Johannes.Hofmann＠gmx.de

On Sun, Sep 04, 2011 at 07:15:09PM +0000, corvid wrote: > Johannes wrote: > > Thanks for the cleaned up test case. It's still remarkably complex. > > I see the issue also with dillo-2.1.1. Nevertheless we should > > definately try to fix it. I will play with it a bit... > > I wonder whether it is just the limit_text_width button problem dressed > up in more complex clothing. As funny as it sounds, hg bisect says it's rev 6a892184d498 where it starts the redraw loop! And indeed, if I do --- a/src/prefsparser.cc Sat Sep 03 01:15:33 2011 +0000 +++ b/src/prefsparser.cc Sun Sep 04 22:04:18 2011 +0200 @@ -219,10 +219,11 @@ setlocale(LC_NUMERIC, oldLocale); dFree(oldLocale); - +#if 0 if (prefs.limit_text_width) { /* BUG: causes 100% CPU usage with <button> or <input type="image"> */ MSG_WARN("Disabling limit_text_width preference (currently broken).\n"); prefs.limit_text_width = FALSE; } +#endif } it loops with limit_text_width=NO and doesn't with limit_text_width=YES. Cheers, Johannes

Sept. 4, 2011

page that redraws endlessly

by corvid＠lavabit.com

Johannes wrote: > Thanks for the cleaned up test case. It's still remarkably complex. > I see the issue also with dillo-2.1.1. Nevertheless we should > definately try to fix it. I will play with it a bit... I wonder whether it is just the limit_text_width button problem dressed up in more complex clothing.

Sept. 4, 2011

page that redraws endlessly

by Johannes.Hofmann＠gmx.de

Thanks for the cleaned up test case. It's still remarkably complex. I see the issue also with dillo-2.1.1. Nevertheless we should definately try to fix it. I will play with it a bit... Cheers, Johannes On Sat, Sep 03, 2011 at 05:00:10PM +0000, corvid wrote: > > The following suffices to trigger it for me: > > <table> > <tr> > <td> > <div> > <button></button> > </div> > <div> > words words words words words words words words words words words > words words words words words words words words words words words > words words words words words words words words words words words > words words words words words words words words words words words > <span style="white-space:nowrap">And words in a span</span> > <button></button> > </div> > </td> > </table> > > > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Sept. 4, 2011

page that redraws endlessly

by corvid＠lavabit.com

The following suffices to trigger it for me: <table> <tr> <td> <div> <button></button> </div> <div> words words words words words words words words words words words words words words words words words words words words words words words words words words words words words words words words words words words words words words words words words words words words <span style="white-space:nowrap">And words in a span</span> <button></button> </div> </td> </table>

Sept. 3, 2011

page that redraws endlessly

by corvid＠lavabit.com

I wrote: > > http://www.dillo.org/test/redraws.html > > For me, it still breaks with default dillorc options, and also with a > dillo from April 2010. I put up a new version where I trimmed the body down to something comprehensible. The <style> in <head> is still a big mess.

Sept. 3, 2011

page that redraws endlessly

by corvid＠lavabit.com

http://www.dillo.org/test/redraws.html For me, it still breaks with default dillorc options, and also with a dillo from April 2010.

Sept. 3, 2011

prefs.show_url

by corvid＠lavabit.com

I just found that turning off prefs.show_url messes up the appearance of the UI.

Sept. 3, 2011

valgrind still unhappy despite expect changes

by jcid＠dillo.org

On Fri, Sep 02, 2011 at 01:48:29PM -0300, Jorge Arellano Cid wrote: > On Fri, Sep 02, 2011 at 03:59:17PM +0000, corvid wrote: > > Jorge wrote: > > > On Thu, Sep 01, 2011 at 07:47:48PM +0000, corvid wrote: > > > > Jorge wrote: > > > > > On Thu, Sep 01, 2011 at 10:56:19AM -0300, Jorge Arellano Cid wrote: > > > > > > [...] > > > > > Any help is appreciatted. > > > > > > > > My guess is that it could be something like > > > > first, one bw asks for a page, and that becomes conn->bw, > > > > and then another bw starts also asking for the page, and > > > > the first bw closes, invalidating the conn->bw, and then > > > > the second bw closes and the cancel expect code tries to > > > > use the old bw. > > > > > > "bw" is a bit a misleading name, bacause each tab is a bw. > > > > > > OTOH, each tab has its own control panel and thus becomes > > > a browser window object. > > > > > > In the case you propose there'd be two different bw. > > > > Right. Why do you feel that they can't be two bws that were > > both closed from the keyboard? > > I have no problems with that. > > What I don't see is two bws with the same memory address being > closed from the keyboard. > > But now I see what you mean: which is a lingering bw in conn, > (which is compatible with my analysis), as there's no need for it > to exist in the UI when the event arrives. > > So we'de have two close events handled OK by two perfectly sane > bws, but one call made on an already defunct bw (i.e. not present > in the UI). > > And you hit it on the nail, because now I can reproduce it!!! Patch committed. FWIW, the testcase I used produced: ==17336== ERROR SUMMARY: 115 errors from 76 contexts (suppressed: 13 from 10) without the patch, and ==17468== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 13 from 10) with it. :-) -- Cheers Jorge.-

Sept. 2, 2011

valgrind still unhappy despite expect changes

by jcid＠dillo.org

On Fri, Sep 02, 2011 at 03:59:17PM +0000, corvid wrote: > Jorge wrote: > > On Thu, Sep 01, 2011 at 07:47:48PM +0000, corvid wrote: > > > Jorge wrote: > > > > On Thu, Sep 01, 2011 at 10:56:19AM -0300, Jorge Arellano Cid wrote: > > > > [...] > > > > Any help is appreciatted. > > > > > > My guess is that it could be something like > > > first, one bw asks for a page, and that becomes conn->bw, > > > and then another bw starts also asking for the page, and > > > the first bw closes, invalidating the conn->bw, and then > > > the second bw closes and the cancel expect code tries to > > > use the old bw. > > > > "bw" is a bit a misleading name, bacause each tab is a bw. > > > > OTOH, each tab has its own control panel and thus becomes > > a browser window object. > > > > In the case you propose there'd be two different bw. > > Right. Why do you feel that they can't be two bws that were > both closed from the keyboard? I have no problems with that. What I don't see is two bws with the same memory address being closed from the keyboard. But now I see what you mean: which is a lingering bw in conn, (which is compatible with my analysis), as there's no need for it to exist in the UI when the event arrives. So we'de have two close events handled OK by two perfectly sane bws, but one call made on an already defunct bw (i.e. not present in the UI). And you hit it on the nail, because now I can reproduce it!!! -- Cheers Jorge.-

Sept. 2, 2011

valgrind still unhappy despite expect changes

by corvid＠lavabit.com

Jorge wrote: > On Thu, Sep 01, 2011 at 07:47:48PM +0000, corvid wrote: > > Jorge wrote: > > > On Thu, Sep 01, 2011 at 10:56:19AM -0300, Jorge Arellano Cid wrote: > > > > On Thu, Sep 01, 2011 at 03:38:58PM +0200, Johannes Hofmann wrote: > > > > > On Thu, Sep 01, 2011 at 09:57:39AM -0300, Jorge Arellano Cid wrote: > > > > > > On Wed, Aug 31, 2011 at 09:42:21PM +0000, corvid wrote: > > > > > > > Jorge wrote: > > > > > > > > > > [...] > > > > > > > In this one > > > > > > > http://starurchin.org/dillo/valgrind/7ea9fc809376ddf7dde2908e2ecf999aea2741… > > > > > > > at least, it looks pretty clear that the bw is gone. > > > > > > > > > > > > [...] > > > > > > Does the invalid read apply to 'bw' or 'bw->nav_expect_url'? > > > > > > (I don't know valgrind's semantics on it) > > > > > > > > > > I'd guess bw is no longer pointing to valid memory (i.e. has been > > > > > free'd) and therefore reading the 4 byte nav_expect_url pointer > > > > > causes the valgrind message. > > > > > > > > OK, this line gave light in that direction: > > > > > > > > ==28991== Address 0x6961a34 is 44 bytes inside a block of size 68 free'd > > > > > > > > ... and I observe that bw has 17 items, 17*4 = 68, > > > > and the expect URL is the 12th item, (12-1)*4 = 44. > > > > > > > > So it's an already freed 'bw' and not its expected URL. > > > > > > > > This starts to make sense... ;-) > > > > > > BTW, why there are two different stack traces? > > > What does the second one mean with respect to the first? > > > > The top one shows the invalid read, and the bottom shows how the > > memory was freed that the top tried to read. > > Thanks. > > Well, in that case we have a weird situation: > > Both stacks have: > > ==28991== by 0x8053F49: CustTabs::handle(int) (uicmd.cc:204) > > Which translates into a bw (window or tab) that's closed twice > by using the keyboard. > > > Strange as it seems, let's analyze it a bit: > For __both_ cases: > > 1.- fltk is sending the SHORTCUT event for KEYS_CLOSE_TAB > 2.- dillo receives it in CustTabs::handle() and gets the bw with: > > UI *ui = (UI*)wizard()->value(); > BrowserWindow *bw = a_UIcmd_get_bw_by_widget(ui); > > (which means the ui is the current one and that the bw is in > our valid bw list.) > > 3.- dillo calls a_UIcmd_close_bw() which: > > a) stops the clients > b) tabs->remove_tab(ui) // This switches to another bw > and removes the ui from wizard > > * Here the question is how can dillo find the ui and same > bw, in the wizard as current, and in the valid bw list > (after 3c), for a second time at 2.- ? > > c) a_Bw_free(bw) // the bw is removed from our valid > list and freed. > > > > The only answer I can find for the above question is: > The memory space for bw is reused with a new ui. This is: > > * create a bw (e.g. address 0x888). > * close the bw, free the bw (0x888 is available again) > * create a bw (malloc reuses address 0x888). > * close the bw // Here we have the situation! > * free the bw (0x888 is available again) > > > which is compatible with: > > "Valgrind Bug254420 - memory pool tracking broken" > http://bugs.kde.org/show_bug.cgi?id=254420 > > > but, of course, I may be wrong... > > > > > > [...] > > > OTOH, analyzing the code: > > > > > > AFAIS: > > > > > > * The only place where a bw is freed is in a_UIcmd_close_bw [3]: > > > (the only call to a_Bw_free() in the codebase). > > > * bw is valid at [1] > > > * The problematic a_Nav_cancel_expect_if_eq() is called from > > > inside the call chain at [2]. > > > * No other a_UIcmd_close_bw() appears in the log, so how came > > > bw to be invalid then? > > > > > > > > > void a_UIcmd_close_bw(void *vbw) > > > { > > > BrowserWindow *bw = (BrowserWindow *)vbw; > > > UI *ui = BW2UI(bw); > > > CustTabs *tabs = ui->tabs(); > > > 1 Layout *layout = (Layout*)bw->render_layout; > > > > > > MSG("a_UIcmd_close_bw bw=%p\n", bw); > > > 2 a_Bw_stop_clients(bw, BW_Root + BW_Img + BW_Force); > > > delete(layout); > > > if (tabs) { > > > tabs->remove_tab(ui); > > > if (tabs->num_tabs() == 0) > > > delete tabs->window(); > > > } > > > 3 a_Bw_free(bw); > > > MSG("a_UIcmd_close_bw freed(bw=%p)\n", bw); > > > } > > > > > > > > > Any help is appreciatted. > > > > My guess is that it could be something like > > first, one bw asks for a page, and that becomes conn->bw, > > and then another bw starts also asking for the page, and > > the first bw closes, invalidating the conn->bw, and then > > the second bw closes and the cancel expect code tries to > > use the old bw. > > "bw" is a bit a misleading name, bacause each tab is a bw. > > OTOH, each tab has its own control panel and thus becomes > a browser window object. > > In the case you propose there'd be two different bw. Right. Why do you feel that they can't be two bws that were both closed from the keyboard? > Bottom line: > > This bug is currently holding the dillo-3.0 release. > > Given the analysis, that nobody knows how to reproduce it, > that even if real, it doesn't do much harm, the situation is: > if there's no news in a couple of days, the release will be made. No objections here.

Sept. 2, 2011

valgrind still unhappy despite expect changes

by jcid＠dillo.org

On Thu, Sep 01, 2011 at 07:47:48PM +0000, corvid wrote: > Jorge wrote: > > On Thu, Sep 01, 2011 at 10:56:19AM -0300, Jorge Arellano Cid wrote: > > > On Thu, Sep 01, 2011 at 03:38:58PM +0200, Johannes Hofmann wrote: > > > > On Thu, Sep 01, 2011 at 09:57:39AM -0300, Jorge Arellano Cid wrote: > > > > > On Wed, Aug 31, 2011 at 09:42:21PM +0000, corvid wrote: > > > > > > Jorge wrote: > > > > > > > > [...] > > > > > > In this one > > > > > > http://starurchin.org/dillo/valgrind/7ea9fc809376ddf7dde2908e2ecf999aea2741… > > > > > > at least, it looks pretty clear that the bw is gone. > > > > > > > > > [...] > > > > > Does the invalid read apply to 'bw' or 'bw->nav_expect_url'? > > > > > (I don't know valgrind's semantics on it) > > > > > > > > I'd guess bw is no longer pointing to valid memory (i.e. has been > > > > free'd) and therefore reading the 4 byte nav_expect_url pointer > > > > causes the valgrind message. > > > > > > OK, this line gave light in that direction: > > > > > > ==28991== Address 0x6961a34 is 44 bytes inside a block of size 68 free'd > > > > > > ... and I observe that bw has 17 items, 17*4 = 68, > > > and the expect URL is the 12th item, (12-1)*4 = 44. > > > > > > So it's an already freed 'bw' and not its expected URL. > > > > > > This starts to make sense... ;-) > > > > BTW, why there are two different stack traces? > > What does the second one mean with respect to the first? > > The top one shows the invalid read, and the bottom shows how the > memory was freed that the top tried to read. Thanks. Well, in that case we have a weird situation: Both stacks have: ==28991== by 0x8053F49: CustTabs::handle(int) (uicmd.cc:204) Which translates into a bw (window or tab) that's closed twice by using the keyboard. Strange as it seems, let's analyze it a bit: For __both_ cases: 1.- fltk is sending the SHORTCUT event for KEYS_CLOSE_TAB 2.- dillo receives it in CustTabs::handle() and gets the bw with: UI *ui = (UI*)wizard()->value(); BrowserWindow *bw = a_UIcmd_get_bw_by_widget(ui); (which means the ui is the current one and that the bw is in our valid bw list.) 3.- dillo calls a_UIcmd_close_bw() which: a) stops the clients b) tabs->remove_tab(ui) // This switches to another bw and removes the ui from wizard * Here the question is how can dillo find the ui and same bw, in the wizard as current, and in the valid bw list (after 3c), for a second time at 2.- ? c) a_Bw_free(bw) // the bw is removed from our valid list and freed. The only answer I can find for the above question is: The memory space for bw is reused with a new ui. This is: * create a bw (e.g. address 0x888). * close the bw, free the bw (0x888 is available again) * create a bw (malloc reuses address 0x888). * close the bw // Here we have the situation! * free the bw (0x888 is available again) which is compatible with: "Valgrind Bug254420 - memory pool tracking broken" http://bugs.kde.org/show_bug.cgi?id=254420 but, of course, I may be wrong... > > [...] > > OTOH, analyzing the code: > > > > AFAIS: > > > > * The only place where a bw is freed is in a_UIcmd_close_bw [3]: > > (the only call to a_Bw_free() in the codebase). > > * bw is valid at [1] > > * The problematic a_Nav_cancel_expect_if_eq() is called from > > inside the call chain at [2]. > > * No other a_UIcmd_close_bw() appears in the log, so how came > > bw to be invalid then? > > > > > > void a_UIcmd_close_bw(void *vbw) > > { > > BrowserWindow *bw = (BrowserWindow *)vbw; > > UI *ui = BW2UI(bw); > > CustTabs *tabs = ui->tabs(); > > 1 Layout *layout = (Layout*)bw->render_layout; > > > > MSG("a_UIcmd_close_bw bw=%p\n", bw); > > 2 a_Bw_stop_clients(bw, BW_Root + BW_Img + BW_Force); > > delete(layout); > > if (tabs) { > > tabs->remove_tab(ui); > > if (tabs->num_tabs() == 0) > > delete tabs->window(); > > } > > 3 a_Bw_free(bw); > > MSG("a_UIcmd_close_bw freed(bw=%p)\n", bw); > > } > > > > > > Any help is appreciatted. > > My guess is that it could be something like > first, one bw asks for a page, and that becomes conn->bw, > and then another bw starts also asking for the page, and > the first bw closes, invalidating the conn->bw, and then > the second bw closes and the cancel expect code tries to > use the old bw. "bw" is a bit a misleading name, bacause each tab is a bw. OTOH, each tab has its own control panel and thus becomes a browser window object. In the case you propose there'd be two different bw. >>>>>>>>>>> Bottom line: This bug is currently holding the dillo-3.0 release. Given the analysis, that nobody knows how to reproduce it, that even if real, it doesn't do much harm, the situation is: if there's no news in a couple of days, the release will be made. -- Cheers Jorge.-

Sept. 2, 2011

valgrind still unhappy despite expect changes

by corvid＠lavabit.com

Jorge wrote: > On Thu, Sep 01, 2011 at 10:56:19AM -0300, Jorge Arellano Cid wrote: > > On Thu, Sep 01, 2011 at 03:38:58PM +0200, Johannes Hofmann wrote: > > > On Thu, Sep 01, 2011 at 09:57:39AM -0300, Jorge Arellano Cid wrote: > > > > On Wed, Aug 31, 2011 at 09:42:21PM +0000, corvid wrote: > > > > > Jorge wrote: > > > > > > [...] > > > > > In this one > > > > > http://starurchin.org/dillo/valgrind/7ea9fc809376ddf7dde2908e2ecf999aea2741… > > > > > at least, it looks pretty clear that the bw is gone. > > > > > > [...] > > > > Does the invalid read apply to 'bw' or 'bw->nav_expect_url'? > > > > (I don't know valgrind's semantics on it) > > > > > > I'd guess bw is no longer pointing to valid memory (i.e. has been > > > free'd) and therefore reading the 4 byte nav_expect_url pointer > > > causes the valgrind message. > > > > OK, this line gave light in that direction: > > > > ==28991== Address 0x6961a34 is 44 bytes inside a block of size 68 free'd > > > > ... and I observe that bw has 17 items, 17*4 = 68, > > and the expect URL is the 12th item, (12-1)*4 = 44. > > > > So it's an already freed 'bw' and not its expected URL. > > > > This starts to make sense... ;-) > > BTW, why there are two different stack traces? > What does the second one mean with respect to the first? The top one shows the invalid read, and the bottom shows how the memory was freed that the top tried to read. > If I look the first one (in reading order), it's clear that a > keyboard event closed a browser window cancelling the expect. > This is, for instance, middle-click a link, hit Ctrl-W before the > data stream starts to arrive (while dillo displays the > "contacting host" message). > > In my machine this happens in the expected order with no > problems. Can anybody reproduce the valgrind log using this > procedure? > > OTOH, analyzing the code: > > AFAIS: > > * The only place where a bw is freed is in a_UIcmd_close_bw [3]: > (the only call to a_Bw_free() in the codebase). > * bw is valid at [1] > * The problematic a_Nav_cancel_expect_if_eq() is called from > inside the call chain at [2]. > * No other a_UIcmd_close_bw() appears in the log, so how came > bw to be invalid then? > > > void a_UIcmd_close_bw(void *vbw) > { > BrowserWindow *bw = (BrowserWindow *)vbw; > UI *ui = BW2UI(bw); > CustTabs *tabs = ui->tabs(); > 1 Layout *layout = (Layout*)bw->render_layout; > > MSG("a_UIcmd_close_bw bw=%p\n", bw); > 2 a_Bw_stop_clients(bw, BW_Root + BW_Img + BW_Force); > delete(layout); > if (tabs) { > tabs->remove_tab(ui); > if (tabs->num_tabs() == 0) > delete tabs->window(); > } > 3 a_Bw_free(bw); > MSG("a_UIcmd_close_bw freed(bw=%p)\n", bw); > } > > > Any help is appreciatted. My guess is that it could be something like first, one bw asks for a page, and that becomes conn->bw, and then another bw starts also asking for the page, and the first bw closes, invalidating the conn->bw, and then the second bw closes and the cancel expect code tries to use the old bw. I'm sure it won't turn out to be exactly that, but when I saw that there was a conn->bw, it seemed that there have to be ways for a conn to outlast a bw.

Sept. 1, 2011

valgrind still unhappy despite expect changes

by jcid＠dillo.org

On Thu, Sep 01, 2011 at 02:58:09PM -0300, Jorge Arellano Cid wrote: > On Thu, Sep 01, 2011 at 10:56:19AM -0300, Jorge Arellano Cid wrote: > > On Thu, Sep 01, 2011 at 03:38:58PM +0200, Johannes Hofmann wrote: > > > On Thu, Sep 01, 2011 at 09:57:39AM -0300, Jorge Arellano Cid wrote: > > > > On Wed, Aug 31, 2011 at 09:42:21PM +0000, corvid wrote: > > > > > Jorge wrote: > > > > > > [...] > > > > > In this one > > > > > http://starurchin.org/dillo/valgrind/7ea9fc809376ddf7dde2908e2ecf999aea2741… > > > > > at least, it looks pretty clear that the bw is gone. > > > > > > [...] > > > > Does the invalid read apply to 'bw' or 'bw->nav_expect_url'? > > > > (I don't know valgrind's semantics on it) > > > > > > I'd guess bw is no longer pointing to valid memory (i.e. has been > > > free'd) and therefore reading the 4 byte nav_expect_url pointer > > > causes the valgrind message. > > > > OK, this line gave light in that direction: > > > > ==28991== Address 0x6961a34 is 44 bytes inside a block of size 68 free'd > > > > ... and I observe that bw has 17 items, 17*4 = 68, > > and the expect URL is the 12th item, (12-1)*4 = 44. > > > > So it's an already freed 'bw' and not its expected URL. > > > > This starts to make sense... ;-) FYI, looking into the other direction (a false positive), we have this: "Valgrind Bug254420 - memory pool tracking broken" http://bugs.kde.org/show_bug.cgi?id=254420 fixed in 3.6.1. If Jeremy or anybody can find a way to reproduce the log, we'd be very close to nailing the issue down. @Jeremy: what do you get from valgrind using the procedure described in my previous email? TIA. -- Cheers Jorge.-

Sept. 1, 2011

valgrind still unhappy despite expect changes

by jcid＠dillo.org

On Thu, Sep 01, 2011 at 10:56:19AM -0300, Jorge Arellano Cid wrote: > On Thu, Sep 01, 2011 at 03:38:58PM +0200, Johannes Hofmann wrote: > > On Thu, Sep 01, 2011 at 09:57:39AM -0300, Jorge Arellano Cid wrote: > > > On Wed, Aug 31, 2011 at 09:42:21PM +0000, corvid wrote: > > > > Jorge wrote: > > > > [...] > > > > In this one > > > > http://starurchin.org/dillo/valgrind/7ea9fc809376ddf7dde2908e2ecf999aea2741… > > > > at least, it looks pretty clear that the bw is gone. > > > [...] > > > Does the invalid read apply to 'bw' or 'bw->nav_expect_url'? > > > (I don't know valgrind's semantics on it) > > > > I'd guess bw is no longer pointing to valid memory (i.e. has been > > free'd) and therefore reading the 4 byte nav_expect_url pointer > > causes the valgrind message. > > OK, this line gave light in that direction: > > ==28991== Address 0x6961a34 is 44 bytes inside a block of size 68 free'd > > ... and I observe that bw has 17 items, 17*4 = 68, > and the expect URL is the 12th item, (12-1)*4 = 44. > > So it's an already freed 'bw' and not its expected URL. > > This starts to make sense... ;-) BTW, why there are two different stack traces? What does the second one mean with respect to the first? If I look the first one (in reading order), it's clear that a keyboard event closed a browser window cancelling the expect. This is, for instance, middle-click a link, hit Ctrl-W before the data stream starts to arrive (while dillo displays the "contacting host" message). In my machine this happens in the expected order with no problems. Can anybody reproduce the valgrind log using this procedure? OTOH, analyzing the code: AFAIS: * The only place where a bw is freed is in a_UIcmd_close_bw [3]: (the only call to a_Bw_free() in the codebase). * bw is valid at [1] * The problematic a_Nav_cancel_expect_if_eq() is called from inside the call chain at [2]. * No other a_UIcmd_close_bw() appears in the log, so how came bw to be invalid then? void a_UIcmd_close_bw(void *vbw) { BrowserWindow *bw = (BrowserWindow *)vbw; UI *ui = BW2UI(bw); CustTabs *tabs = ui->tabs(); 1 Layout *layout = (Layout*)bw->render_layout; MSG("a_UIcmd_close_bw bw=%p\n", bw); 2 a_Bw_stop_clients(bw, BW_Root + BW_Img + BW_Force); delete(layout); if (tabs) { tabs->remove_tab(ui); if (tabs->num_tabs() == 0) delete tabs->window(); } 3 a_Bw_free(bw); MSG("a_UIcmd_close_bw freed(bw=%p)\n", bw); } Any help is appreciatted. -- Cheers Jorge.-

Sept. 1, 2011

valgrind still unhappy despite expect changes

by jcid＠dillo.org

On Thu, Sep 01, 2011 at 03:38:58PM +0200, Johannes Hofmann wrote: > On Thu, Sep 01, 2011 at 09:57:39AM -0300, Jorge Arellano Cid wrote: > > On Wed, Aug 31, 2011 at 09:42:21PM +0000, corvid wrote: > > > Jorge wrote: > > > > On Tue, Aug 30, 2011 at 06:19:38PM +0100, Jeremy Henty wrote: > > > > > > > > > > Jorge Arellano Cid wrote: > > > > > > > > > > > On Tue, Aug 30, 2011 at 12:34:59AM +0100, Jeremy Henty wrote: > > > > > > > > > > > > > > I compile Dillo with 'configure "CFLAGS=-g -O0" "CXXFLAGS= -g > > > > > > > -O0"' to minimise false positives from gcc optimization. > > > > > > > > > > > > Ack. > > > > > > > > > > > > Given you got the log. Do you have a way to reproduce it, or at > > > > > > least have a memory of what you were doing? > > > > > > > > > > Unfortunately no. I automatically run dillo inside valgrind and log > > > > > the output. A cron job reads the logs and updates the reports. These > > > > > days I rarely even look at the logs unless something in the mailing > > > > > list prompts me to. > > > > > > > > > > I am wondering how to add debugging information that could help tie > > > > > valgrind reports to Dillo's actions. Perhaps the CCC could log which > > > > > of its chains is active and which URL it was serving? Then if dlib > > > > > logged its allocations and frees maybe we could identify the URL that > > > > > was responsible? > > > > > > > > Even having the URL wouldn't help much in this case because we > > > > need to know which "cancel" action triggered the last call to > > > > a_Nav_cancel_expect_if_eq(). This would require logging user > > > > actions. > > > > > > > > OTOH, trying to re-build a user action pattern from the CCC > > > > logs would be almost impossible for a human brain (if possible at > > > > all). ;) > > > > > > > > More technically: > > > > > > > > Each bw has its own nav_expect_url; a private copy of a > > > > DilloUrl. Valgrind complains about nav_expect_url, not the bw. So > > > > I wonder how can the bw be valid and not the nav_expect_url, > > > > which is either NULL or a private copy of a DilloUrl? > > > > > > In this one > > > http://starurchin.org/dillo/valgrind/7ea9fc809376ddf7dde2908e2ecf999aea2741… > > > at least, it looks pretty clear that the bw is gone. > > > > Oh, it may be my mistake then. > > > > ==28991== Invalid read of size 4 > > ==28991== at 0x805760A: a_Bw_expected_url (bw.c:336) > > > > bw.c:336 > > return bw->nav_expect_url; > > > > Does the invalid read apply to 'bw' or 'bw->nav_expect_url'? > > (I don't know valgrind's semantics on it) > > I'd guess bw is no longer pointing to valid memory (i.e. has been > free'd) and therefore reading the 4 byte nav_expect_url pointer > causes the valgrind message. OK, this line gave light in that direction: ==28991== Address 0x6961a34 is 44 bytes inside a block of size 68 free'd ... and I observe that bw has 17 items, 17*4 = 68, and the expect URL is the 12th item, (12-1)*4 = 44. So it's an already freed 'bw' and not its expected URL. This starts to make sense... ;-) -- Cheers Jorge.-

Sept. 1, 2011

valgrind still unhappy despite expect changes

by johannes.hofmann＠gmx.de

On Thu, Sep 01, 2011 at 09:57:39AM -0300, Jorge Arellano Cid wrote: > On Wed, Aug 31, 2011 at 09:42:21PM +0000, corvid wrote: > > Jorge wrote: > > > On Tue, Aug 30, 2011 at 06:19:38PM +0100, Jeremy Henty wrote: > > > > > > > > Jorge Arellano Cid wrote: > > > > > > > > > On Tue, Aug 30, 2011 at 12:34:59AM +0100, Jeremy Henty wrote: > > > > > > > > > > > > I compile Dillo with 'configure "CFLAGS=-g -O0" "CXXFLAGS= -g > > > > > > -O0"' to minimise false positives from gcc optimization. > > > > > > > > > > Ack. > > > > > > > > > > Given you got the log. Do you have a way to reproduce it, or at > > > > > least have a memory of what you were doing? > > > > > > > > Unfortunately no. I automatically run dillo inside valgrind and log > > > > the output. A cron job reads the logs and updates the reports. These > > > > days I rarely even look at the logs unless something in the mailing > > > > list prompts me to. > > > > > > > > I am wondering how to add debugging information that could help tie > > > > valgrind reports to Dillo's actions. Perhaps the CCC could log which > > > > of its chains is active and which URL it was serving? Then if dlib > > > > logged its allocations and frees maybe we could identify the URL that > > > > was responsible? > > > > > > Even having the URL wouldn't help much in this case because we > > > need to know which "cancel" action triggered the last call to > > > a_Nav_cancel_expect_if_eq(). This would require logging user > > > actions. > > > > > > OTOH, trying to re-build a user action pattern from the CCC > > > logs would be almost impossible for a human brain (if possible at > > > all). ;) > > > > > > More technically: > > > > > > Each bw has its own nav_expect_url; a private copy of a > > > DilloUrl. Valgrind complains about nav_expect_url, not the bw. So > > > I wonder how can the bw be valid and not the nav_expect_url, > > > which is either NULL or a private copy of a DilloUrl? > > > > In this one > > http://starurchin.org/dillo/valgrind/7ea9fc809376ddf7dde2908e2ecf999aea2741… > > at least, it looks pretty clear that the bw is gone. > > Oh, it may be my mistake then. > > ==28991== Invalid read of size 4 > ==28991== at 0x805760A: a_Bw_expected_url (bw.c:336) > > bw.c:336 > return bw->nav_expect_url; > > Does the invalid read apply to 'bw' or 'bw->nav_expect_url'? > (I don't know valgrind's semantics on it) I'd guess bw is no longer pointing to valid memory (i.e. has been free'd) and therefore reading the 4 byte nav_expect_url pointer causes the valgrind message.

Sept. 1, 2011

valgrind still unhappy despite expect changes

by jcid＠dillo.org

On Wed, Aug 31, 2011 at 09:42:21PM +0000, corvid wrote: > Jorge wrote: > > On Tue, Aug 30, 2011 at 06:19:38PM +0100, Jeremy Henty wrote: > > > > > > Jorge Arellano Cid wrote: > > > > > > > On Tue, Aug 30, 2011 at 12:34:59AM +0100, Jeremy Henty wrote: > > > > > > > > > > I compile Dillo with 'configure "CFLAGS=-g -O0" "CXXFLAGS= -g > > > > > -O0"' to minimise false positives from gcc optimization. > > > > > > > > Ack. > > > > > > > > Given you got the log. Do you have a way to reproduce it, or at > > > > least have a memory of what you were doing? > > > > > > Unfortunately no. I automatically run dillo inside valgrind and log > > > the output. A cron job reads the logs and updates the reports. These > > > days I rarely even look at the logs unless something in the mailing > > > list prompts me to. > > > > > > I am wondering how to add debugging information that could help tie > > > valgrind reports to Dillo's actions. Perhaps the CCC could log which > > > of its chains is active and which URL it was serving? Then if dlib > > > logged its allocations and frees maybe we could identify the URL that > > > was responsible? > > > > Even having the URL wouldn't help much in this case because we > > need to know which "cancel" action triggered the last call to > > a_Nav_cancel_expect_if_eq(). This would require logging user > > actions. > > > > OTOH, trying to re-build a user action pattern from the CCC > > logs would be almost impossible for a human brain (if possible at > > all). ;) > > > > More technically: > > > > Each bw has its own nav_expect_url; a private copy of a > > DilloUrl. Valgrind complains about nav_expect_url, not the bw. So > > I wonder how can the bw be valid and not the nav_expect_url, > > which is either NULL or a private copy of a DilloUrl? > > In this one > http://starurchin.org/dillo/valgrind/7ea9fc809376ddf7dde2908e2ecf999aea2741… > at least, it looks pretty clear that the bw is gone. Oh, it may be my mistake then. ==28991== Invalid read of size 4 ==28991== at 0x805760A: a_Bw_expected_url (bw.c:336) bw.c:336 return bw->nav_expect_url; Does the invalid read apply to 'bw' or 'bw->nav_expect_url'? (I don't know valgrind's semantics on it) -- Cheers Jorge.-

Sept. 1, 2011

valgrind still unhappy despite expect changes

by corvid＠lavabit.com

Jorge wrote: > On Tue, Aug 30, 2011 at 06:19:38PM +0100, Jeremy Henty wrote: > > > > Jorge Arellano Cid wrote: > > > > > On Tue, Aug 30, 2011 at 12:34:59AM +0100, Jeremy Henty wrote: > > > > > > > > I compile Dillo with 'configure "CFLAGS=-g -O0" "CXXFLAGS= -g > > > > -O0"' to minimise false positives from gcc optimization. > > > > > > Ack. > > > > > > Given you got the log. Do you have a way to reproduce it, or at > > > least have a memory of what you were doing? > > > > Unfortunately no. I automatically run dillo inside valgrind and log > > the output. A cron job reads the logs and updates the reports. These > > days I rarely even look at the logs unless something in the mailing > > list prompts me to. > > > > I am wondering how to add debugging information that could help tie > > valgrind reports to Dillo's actions. Perhaps the CCC could log which > > of its chains is active and which URL it was serving? Then if dlib > > logged its allocations and frees maybe we could identify the URL that > > was responsible? > > Even having the URL wouldn't help much in this case because we > need to know which "cancel" action triggered the last call to > a_Nav_cancel_expect_if_eq(). This would require logging user > actions. > > OTOH, trying to re-build a user action pattern from the CCC > logs would be almost impossible for a human brain (if possible at > all). ;) > > More technically: > > Each bw has its own nav_expect_url; a private copy of a > DilloUrl. Valgrind complains about nav_expect_url, not the bw. So > I wonder how can the bw be valid and not the nav_expect_url, > which is either NULL or a private copy of a DilloUrl? In this one http://starurchin.org/dillo/valgrind/7ea9fc809376ddf7dde2908e2ecf999aea2741… at least, it looks pretty clear that the bw is gone.

Aug. 31, 2011

valgrind still unhappy despite expect changes

by jcid＠dillo.org

On Tue, Aug 30, 2011 at 06:19:38PM +0100, Jeremy Henty wrote: > > Jorge Arellano Cid wrote: > > > On Tue, Aug 30, 2011 at 12:34:59AM +0100, Jeremy Henty wrote: > > > > > > I compile Dillo with 'configure "CFLAGS=-g -O0" "CXXFLAGS= -g > > > -O0"' to minimise false positives from gcc optimization. > > > > Ack. > > > > Given you got the log. Do you have a way to reproduce it, or at > > least have a memory of what you were doing? > > Unfortunately no. I automatically run dillo inside valgrind and log > the output. A cron job reads the logs and updates the reports. These > days I rarely even look at the logs unless something in the mailing > list prompts me to. > > I am wondering how to add debugging information that could help tie > valgrind reports to Dillo's actions. Perhaps the CCC could log which > of its chains is active and which URL it was serving? Then if dlib > logged its allocations and frees maybe we could identify the URL that > was responsible? Even having the URL wouldn't help much in this case because we need to know which "cancel" action triggered the last call to a_Nav_cancel_expect_if_eq(). This would require logging user actions. OTOH, trying to re-build a user action pattern from the CCC logs would be almost impossible for a human brain (if possible at all). ;) More technically: Each bw has its own nav_expect_url; a private copy of a DilloUrl. Valgrind complains about nav_expect_url, not the bw. So I wonder how can the bw be valid and not the nav_expect_url, which is either NULL or a private copy of a DilloUrl? -- Cheers Jorge.-

Aug. 31, 2011

dillo-3.0-rc2 is out

by corvid＠lavabit.com

higuita wrote: > Compiles on slackware64 without problem, but... > > > [ok] resize problems when tabs overflow > > open new tabs takes longer and there is a longer pause > until i can open one more... also, close a tab is also slower. Interesting. Do you know how to use gprof?

Aug. 30, 2011

dillo-3.0-rc2 is out

by higuita7＠yahoo.co.uk

Hi Compiles on slackware64 without problem, but... > [ok] resize problems when tabs overflow open new tabs takes longer and there is a longer pause until i can open one more... also, close a tab is also slower. I also found that slashdot was removed from the default page... any special reason? i use it alot :) thanks higuita -- Naturally the common people don't want war... but after all it is the leaders of a country who determine the policy, and it is always a simple matter to drag the people along, whether it is a democracy, or a fascist dictatorship, or a parliament, or a communist dictatorship. Voice or no voice, the people can always be brought to the bidding of the leaders. That is easy. All you have to do is tell them they are being attacked, and denounce the pacifists for lack of patriotism and exposing the country to danger. It works the same in every country. -- Hermann Goering, Nazi and war criminal, 1883-1946

Aug. 30, 2011

dillo-3.0-rc2 is out

by jcid＠dillo.org

On Tue, Aug 30, 2011 at 05:47:36PM +0000, corvid wrote: > > We'll need to make a point of mentioning -- at least in the release > announcement, and maybe in README -- how specifying fonts is a little > trickier now with fltk-1.3. OK. Please go ahead and write some directions. It looks like dillorc and the README file are the best places for it. > I wouldn't be surprised if we end up having to try to get fltk to > add another interface of some sort so that those of us who care about > fonts and have a lot of them (i.e., not me) can have font-family work > more consistently. Ack. -- Cheers Jorge.-

Aug. 30, 2011

dillo-3.0-rc2 is out

by corvid＠lavabit.com

We'll need to make a point of mentioning -- at least in the release announcement, and maybe in README -- how specifying fonts is a little trickier now with fltk-1.3. I wouldn't be surprised if we end up having to try to get fltk to add another interface of some sort so that those of us who care about fonts and have a lot of them (i.e., not me) can have font-family work more consistently.

Aug. 30, 2011

valgrind still unhappy despite expect changes

by onepoint＠starurchin.org

Jorge Arellano Cid wrote: > On Tue, Aug 30, 2011 at 12:34:59AM +0100, Jeremy Henty wrote: > > > > I compile Dillo with 'configure "CFLAGS=-g -O0" "CXXFLAGS= -g > > -O0"' to minimise false positives from gcc optimization. > > Ack. > > Given you got the log. Do you have a way to reproduce it, or at > least have a memory of what you were doing? Unfortunately no. I automatically run dillo inside valgrind and log the output. A cron job reads the logs and updates the reports. These days I rarely even look at the logs unless something in the mailing list prompts me to. I am wondering how to add debugging information that could help tie valgrind reports to Dillo's actions. Perhaps the CCC could log which of its chains is active and which URL it was serving? Then if dlib logged its allocations and frees maybe we could identify the URL that was responsible? Regards, Jeremy Henty

Aug. 30, 2011

dillo-3.0-rc2 is out

by jcid＠dillo.org

On Tue, Aug 30, 2011 at 12:01:41AM +0200, Axel Beckert wrote: > Hi, > > On Mon, Aug 29, 2011 at 05:07:39PM -0300, Jorge Arellano Cid wrote: > > Today the rc2 was packaged. Please get it here: > > > > http://dillo.org/download/dillo-3.0-pre.tar.bz2 // tarball > > Hrm, the tar ball doesn't contain the autogen.sh script I used for the > Debian packaging. (I build the last two package against the hg > checkout. Not sure if was in earlier dillo packages, i.e. 0.8.6 or so) > Is that file not included on purpose? Yes, autogen.sh uses auto* tools to rebuild the configure script, but the configure script is included in the tarball. It is not in the repository because different auto*tools in different platforms generate slightly different configure scripts leading to almost one configure update per commit... > At least in the README, the instructions still say: > > tar jxvf dillo-3.0.tar.bz2 > cd dillo-3.0 > ./autogen.sh; ./configure; make > sudo make install-strip > > OTOH the INSTALL document skips that step, but AFAICS it never has > been changed since the import into the Mercurial repository while the > README has changed a lot in the "Minor changes for dillo-3.0-rc2" > commit. > > Looks inconsistent to me. Not sure which variant is the intended one. Right. Fixed in the repo to read: tar jxvf dillo-3.0.tar.bz2 cd dillo-3.0 ./configure; make sudo make install-strip -- Cheers Jorge.-

Aug. 30, 2011

valgrind still unhappy despite expect changes

by jcid＠dillo.org

Hi Jeremy, Good to see you in this thread! On Tue, Aug 30, 2011 at 12:34:59AM +0100, Jeremy Henty wrote: > Jorge Arellano Cid wrote: > > > OTOH, valgrind produces some false positives (its docs say it) and > > gcc optimization can also play a role... > > I compile Dillo with 'configure "CFLAGS=-g -O0" "CXXFLAGS= -g -O0"' to > minimise false positives from gcc optimization. Ack. Given you got the log. Do you have a way to reproduce it, or at least have a memory of what you were doing? -- Cheers Jorge.-

Aug. 30, 2011

valgrind still unhappy despite expect changes

by onepoint＠starurchin.org

Jorge Arellano Cid wrote: > OTOH, valgrind produces some false positives (its docs say it) and > gcc optimization can also play a role... I compile Dillo with 'configure "CFLAGS=-g -O0" "CXXFLAGS= -g -O0"' to minimise false positives from gcc optimization. Regards, Jeremy Henty

Aug. 30, 2011

dillo-3.0-rc2 is out

by abe＠deuxchevaux.org

Hi, On Mon, Aug 29, 2011 at 05:07:39PM -0300, Jorge Arellano Cid wrote: > Today the rc2 was packaged. Please get it here: > > http://dillo.org/download/dillo-3.0-pre.tar.bz2 // tarball Hrm, the tar ball doesn't contain the autogen.sh script I used for the Debian packaging. (I build the last two package against the hg checkout. Not sure if was in earlier dillo packages, i.e. 0.8.6 or so) Is that file not included on purpose? At least in the README, the instructions still say: tar jxvf dillo-3.0.tar.bz2 cd dillo-3.0 ./autogen.sh; ./configure; make sudo make install-strip OTOH the INSTALL document skips that step, but AFAICS it never has been changed since the import into the Mercurial repository while the README has changed a lot in the "Minor changes for dillo-3.0-rc2" commit. Looks inconsistent to me. Not sure which variant is the intended one. Kind regards, Axel -- /~\ Plain Text Ribbon Campaign | Axel Beckert \ / Say No to HTML in E-Mail and News | abe(a)deuxchevaux.org (Mail) X See http://www.asciiribbon.org/ | abe(a)noone.org (Mail+Jabber) / \ I love long mails: http://email.is-not-s.ms/ | http://noone.org/abe/ (Web)

Aug. 30, 2011

dillo-3.0-rc2 is out

by jcid＠dillo.org

Hi there, After: [ok] moveToWidget(). Jorge has code for this. [ok] downloads dpi string escaping. [ok] alt text wrapping (which looks like a nice feature). [ok] remove large panel. [ok] https dialog storm (BUG#868). [ok] The findbar input doesn't know about Ctrl+{a,e,d,k}. [ok] something other than "ctab%d" for initial tab label. [ok] single close tab button with tooltip. [ok] valgrind logs: close window [ok] valgrind logs: cancel expected url [ok] segfault with Ctrl-s (web search) [ok] UI_TEMPORARILY_SHOW_PANELS [ok] leave link into a native FLTK widget [ok] remove pointeronlink(), panelmode_cb_i() [ok] the panel problems when resizing from very small. [ok] resize problems when tabs overflow [ok] URL_ILLEGAL_CHARS [ok] Fixed CustLightButton "light" color deactivation. [ok] hoverTooltip glitch (tooltip linger when going into a child DIV). [ok] tab overflow (code a handler) [ok] valgrind error for first tab close, then resize(). [ok] update the Changelog [ok] default search engine [ok] new-tab and window title [ok] CSS adjacent sibling selectors [ok] margin-bottom + some margin collapse [ok] fix doctree leak Today the rc2 was packaged. Please get it here: http://dillo.org/download/dillo-3.0-pre.tar.bz2 // tarball http://dillo.org/download/dillo-3.0-pre.tar.bz2.asc // signature The idea is to test the package in different OS/HW-Platforms and to report how the build process went, and how it works. Hopefully it'll become dillo-3.0. Afterall, it has been for a long enough time in testing phase. TIA for your feedback. -- Last but not the least: [ok] valgrind logs: cancel expected url I can't reproduce this anymore (after the committed fix). If somebody can still reproduce it, please report it. Details are in this thread: http://lists.auriga.wearlab.de/pipermail/dillo-dev/2011-August/008810.html (the "expected url" is the one you've asked for but whose data bytes haven't started to arrive. If during this period of time you stop the request --e.g. by pressing Stop or clicking another URL, it's cancelled--). -- Cheers Jorge.-

Aug. 29, 2011

valgrind still unhappy despite expect changes

by corvid＠lavabit.com

Jorge wrote: > On Sun, Aug 28, 2011 at 06:53:54PM +0000, corvid wrote: > > > I can't reproduce this with valgrind-3.6.1 on wheezy. > > > > > > No valgrind error report before or after these debug messages: > > > > > > a_Nav_cancel_expect_if_eq:: calling a_Nav_cancel_expect > > > Dillo: normal exit! > > > > > > I tested by pushing a remote URL on CLI and closing the window > > > before the page data starts flowing (i.e. to cancel the > > > "expect"), and also with the cancelled download code path. > > > Neither one produced an error. > > > > I saw that there was another log entry the other day > > http://starurchin.org/dillo/valgrind/7ea9fc809376ddf7dde2908e2ecf999aea2741… > > > > Do you think something sneaky could be going on, or does it seem > > like it must come down to configuration differences somehow? > > AFAIS, either one is possible... > > Me not being able to reproduce it says it's most probably be OK > for the codepaths I tested (FWIW, the ones I can see). If there's > an untested codepath, well... > > OTOH, valgrind produces some false positives (its docs say it) > and gcc optimization can also play a role... > > So, I'd try to find a simple test case that produces the log. > Then, test this problematic codepath here, and see what comes out > of the exercise. > > Can you reproduce the bug? Do you have a simple test case? No. I haven't really scrutinized the code at all. I've tried a little "I wonder whether this could do it" just from looking at the traces supplied by valgrind, but without hitting upon the trick.

Aug. 29, 2011

valgrind still unhappy despite expect changes

by jcid＠dillo.org

On Sun, Aug 28, 2011 at 06:53:54PM +0000, corvid wrote: > > I can't reproduce this with valgrind-3.6.1 on wheezy. > > > > No valgrind error report before or after these debug messages: > > > > a_Nav_cancel_expect_if_eq:: calling a_Nav_cancel_expect > > Dillo: normal exit! > > > > I tested by pushing a remote URL on CLI and closing the window > > before the page data starts flowing (i.e. to cancel the > > "expect"), and also with the cancelled download code path. > > Neither one produced an error. > > I saw that there was another log entry the other day > http://starurchin.org/dillo/valgrind/7ea9fc809376ddf7dde2908e2ecf999aea2741… > > Do you think something sneaky could be going on, or does it seem > like it must come down to configuration differences somehow? AFAIS, either one is possible... Me not being able to reproduce it says it's most probably be OK for the codepaths I tested (FWIW, the ones I can see). If there's an untested codepath, well... OTOH, valgrind produces some false positives (its docs say it) and gcc optimization can also play a role... So, I'd try to find a simple test case that produces the log. Then, test this problematic codepath here, and see what comes out of the exercise. Can you reproduce the bug? Do you have a simple test case? -- Cheers Jorge.-

Aug. 29, 2011

valgrind doctree leak

by Johannes.Hofmann＠gmx.de

On Sun, Aug 28, 2011 at 02:02:18AM +0000, corvid wrote: > > (from Jeremy's logs) > > ==2186== 928 (32 direct, 896 indirect) bytes in 1 blocks are definitely lost in loss record 815 of 958 > ==2186== at 0x40275CC: operator new(unsigned int) (vg_replace_malloc.c:255) > ==2186== by 0x806E258: Doctree::push() (doctree.hh:67) > ==2186== by 0x806C1FC: StyleEngine::startElement(int) (styleengine.cc:93) > ==2186== by 0x8076DB8: Html_process_tag(DilloHtml*, char*, int) (html.cc:3507) > ==2186== by 0x8077A33: Html_write_raw(DilloHtml*, char*, int, int) (html.cc:3822) > ==2186== by 0x8070543: DilloHtml::write(char*, int, int) (html.cc:552) > ==2186== by 0x80775BD: Html_callback(int, _CacheClient*) (html.cc:3725) > ==2186== by 0x80627AD: Cache_process_queue (cache.c:1195) > ==2186== by 0x80629A2: Cache_delayed_process_queue_callback (cache.c:1260) > ==2186== by 0x40C0876: Fl::wait(double) (in /usr/lib/libfltk.so.1.3) > ==2186== by 0x40C0A30: Fl::run() (in /usr/lib/libfltk.so.1.3) > ==2186== by 0x804F08A: main (dillo.cc:436) These valgrind log's are really helpful! Should be fixed now.

Aug. 28, 2011

problems with very long alt text

by jcid＠dillo.org

On Fri, Aug 26, 2011 at 03:08:06PM -0300, Jorge Arellano Cid wrote: > On Fri, Aug 26, 2011 at 07:29:21PM +0200, hiro wrote: > > With tinycorelinux and Xorg-7.5 i915 on 1024x768 I get a completely > > garbled screen and unresponsive system, CPU ran hot and I had to > > reboot. > > I can reboot into VESA if you want. > > > [later hiro wrote:] > > Ok I don't get the bug with Xvesa, tinycorelinux' default Xserver. > > Excellent! > > This proves the point (AFAICS). > > Thank you very much. FWIW, later I also managed to run dillo nested in Xephyr (on top of the i915 xserver that crashes my notebok), and it renders without problems. -- Cheers Jorge.-

Aug. 28, 2011