- Dillo-dev - lists.mailman3.com

CPU hog bug with https?

by jcid＠dillo.org

Hi there, On Sun, May 01, 2016 at 09:58:53PM +0200, Sebastian Geerken wrote: > On So, Mai 01, 2016, Jorge Arellano Cid wrote: > > Hi, > > > > If I start current dillo with [1], an https dialog springs > > (untrusted certificate). Answering "continue" gets into a CPU hog, > > answering "cancel" allows reading the page with no problems. > > > > FWIW, I've done that lots of times with other sites, and this is the > > first CPU hog I get accross. > > > > > > [1] https://linux.slashdot.org/comments.pl?sid=5852295&cid=48188823 > > I can reproduce this. However, profiling shows rather problems in the > rendering code (dw::core::Widget::queueResize etc.), so the problem is > probably not related to HTTPS. > > Also, mirroring this page ("wget -pkH") and displaying it locally > shows the same symptoms. > > Looks that this belongs rather on my todo list. Good news on this one. Patch committed! I'd like to comment a bit on this bugfix for those that would like to help making patches for dillo. You can check the patch and verbose log with: "hg log -vp|less". It was hard to find, sometimes backtraces gave near 85 or more nested calls, full of different functions. There was no CPU lock because it finally solved the page (after more than two minutes in my machine). It took a few days of work, by reducing the testcase (a slashdot page) by: * removing the scripting * removing one stylesheet completely (no bug without CSS). * removing sections of the HTML code while checking the bug was still reproducible. And checking the backtrace stack from gdb from time to time. gprof may have served also, but as there where so many functions I decided to keep reducing the case. This is a trial&error iteration process. At some point I could clean the testcase enough to run tidy on it, and no, it wasn't a tag soup corner case. Back to reducing the testcase. It started to solve in less time, but still hogging my CPU for near 20 secs.. Then suddenly at some point, gdb's backtrace was still near the hundred in depth, but a few functions remained. Studying the code in the involved functions made me finally spot the hiding bug. Trivial to fix, but very hard to find. For this case, what took more than 2 minutes to render, now takes near 1/8 second. ;-) -- Cheers Jorge.-

May 18, 2016

New tab colours - suggestion

by eocene＠gmx.com

On Tue, May 17, 2016 at 06:47:20PM +0100, Nick Warne wrote: > Actually, I can't get this to work - the same bg colours do not change > - the text colour does though. Do the tab background prefs work at all for you? I remember FLTK sometimes was stubborn about colors if it felt a foreground/background pair had too little contrast. (Also check that they aren't being set again farther down in dillorc.)

May 17, 2016

New tab colours - suggestion

by nick＠linicks.net

On Tue, 17 May 2016 18:37:58 +0100 Nick Warne <nick at linicks.net> wrote: > On Tue, 17 May 2016 18:26:29 +0100 > Nick Warne <nick at linicks.net> wrote: > > > I find that when opening a new tab, the colour of it changes to a > > sort of turquoise colour - which suggests it is in the background. > > > > I do find it confusing - could it be possible to change the working > > tab to the default grey and the background tabs to the turquoise > > colour? > > > > Just a suggestion. > > > > If it doesn't seem to bother anybody else, can someone point me to > > the area of code so I can do a local patch. > > Sorry, ignore the idiot - dillorc has it. Actually, I can't get this to work - the same bg colours do not change - the text colour does though. Nick -- Gosh that takes me back... or is it forward? That's the trouble with time travel, you never can tell." -- Doctor Who "Androids of Tara"

May 17, 2016

New tab colours - suggestion

by nick＠linicks.net

On Tue, 17 May 2016 18:26:29 +0100 Nick Warne <nick at linicks.net> wrote: > I find that when opening a new tab, the colour of it changes to a sort > of turquoise colour - which suggests it is in the background. > > I do find it confusing - could it be possible to change the working > tab to the default grey and the background tabs to the turquoise > colour? > > Just a suggestion. > > If it doesn't seem to bother anybody else, can someone point me to the > area of code so I can do a local patch. Sorry, ignore the idiot - dillorc has it. Duh. Nick -- Gosh that takes me back... or is it forward? That's the trouble with time travel, you never can tell." -- Doctor Who "Androids of Tara"

May 17, 2016

New tab colours - suggestion

by nick＠linicks.net

I find that when opening a new tab, the colour of it changes to a sort of turquoise colour - which suggests it is in the background. I do find it confusing - could it be possible to change the working tab to the default grey and the background tabs to the turquoise colour? Just a suggestion. If it doesn't seem to bother anybody else, can someone point me to the area of code so I can do a local patch. Thanks, Nick -- Gosh that takes me back... or is it forward? That's the trouble with time travel, you never can tell." -- Doctor Who "Androids of Tara"

May 17, 2016

Dillo_grows merged

by nick＠linicks.net

On 16 May 2016 17:52:11 +0200 "Sebastian Geerken" <sgeerken at dillo.org> wrote: > > It *seems to fit* but I'd prefer you to check it. ;) > > I've just pushed a variant of your patch, please give it a try. > > Sebastian Great work Guys, works well :) Nick -- Gosh that takes me back... or is it forward? That's the trouble with time travel, you never can tell." -- Doctor Who "Androids of Tara"

May 16, 2016

Dillo_grows merged

by sgeerken＠dillo.org

On So, Mai 15, 2016, Jorge Arellano Cid wrote: > Hi Sebastian, > > On Sun, May 15, 2016 at 04:42:31PM -0400, Jorge Arellano Cid wrote: > > Hi there! > > > > On Sun, May 15, 2016 at 01:17:40PM +0100, Nick Warne wrote: > > > On Sat, 14 May 2016 22:48:12 +0000 > > > eocene <eocene at gmx.com> wrote: > > > > > > > > Searching the page doesn't cause any more, though. > > > > > > > > Searching backward causes segfaults with regularity. > > > > > > Messing about with this this morning, the segfault happens when using > > > 'previous' goes back past the first found 'next'. > > > > Yes. > > > > I sent this bug to Per Anderson a few weeks ago for him to debug, > > but didn't get an answer. @Per: did you get the email? > > > > Anyway, today I made a simple patch for it, but will investigate > > the issue a bit further before sending it to Sebastian for review. > > OK, the bisect shows the problem starts with commit 4241 which is > a new design for textblock iterators. > > The attached patch works OK for the text search, but I don't know > whether it fits with the overall design. > > It *seems to fit* but I'd prefer you to check it. ;) I've just pushed a variant of your patch, please give it a try. Sebastian

May 16, 2016

Dillo_grows merged

by jcid＠dillo.org

Hi Sebastian, On Sun, May 15, 2016 at 04:42:31PM -0400, Jorge Arellano Cid wrote: > Hi there! > > On Sun, May 15, 2016 at 01:17:40PM +0100, Nick Warne wrote: > > On Sat, 14 May 2016 22:48:12 +0000 > > eocene <eocene at gmx.com> wrote: > > > > > > Searching the page doesn't cause any more, though. > > > > > > Searching backward causes segfaults with regularity. > > > > Messing about with this this morning, the segfault happens when using > > 'previous' goes back past the first found 'next'. > > Yes. > > I sent this bug to Per Anderson a few weeks ago for him to debug, > but didn't get an answer. @Per: did you get the email? > > Anyway, today I made a simple patch for it, but will investigate > the issue a bit further before sending it to Sebastian for review. OK, the bisect shows the problem starts with commit 4241 which is a new design for textblock iterators. The attached patch works OK for the text search, but I don't know whether it fits with the overall design. It *seems to fit* but I'd prefer you to check it. ;) -- Cheers Jorge.-

May 16, 2016

Dillo_grows merged

by jcid＠dillo.org

Hi there! On Sun, May 15, 2016 at 01:17:40PM +0100, Nick Warne wrote: > On Sat, 14 May 2016 22:48:12 +0000 > eocene <eocene at gmx.com> wrote: > > > > Searching the page doesn't cause any more, though. > > > > Searching backward causes segfaults with regularity. > > Messing about with this this morning, the segfault happens when using > 'previous' goes back past the first found 'next'. Yes. I sent this bug to Per Anderson a few weeks ago for him to debug, but didn't get an answer. @Per: did you get the email? Anyway, today I made a simple patch for it, but will investigate the issue a bit further before sending it to Sebastian for review. -- Cheers Jorge.-

May 15, 2016

Dillo_grows merged

by nick＠linicks.net

On Sat, 14 May 2016 22:48:12 +0000 eocene <eocene at gmx.com> wrote: > > Searching the page doesn't cause any more, though. > > Searching backward causes segfaults with regularity. Messing about with this this morning, the segfault happens when using 'previous' goes back past the first found 'next'. i.e. start Dillo with the default home page and search text for 'the'. find the next 'the' a few times, and then use 'previous'. It will work OK until it gets back to the beginning when the next (and final) 'previous' will crash Dillo. Looks like the index is going off the bottom of the search list. I looked at the code a bit, but C++ is all greek to me. Strangely, gdb always reports: Program received signal SIGSEGV, Segmentation fault. 0x080b4638 in dw::oof::OOFAwareWidget::OOFAwareWidgetIterator::getPart ( this=0x836ec60, sectionIndex=5, index=8, content=0x836ec64) at oofawarewidget_iterator.cc:102 102 widget->outOfFlowMgr[sectionIndex - 1]->getWidget (index); this -> sectionIndex=5, index=8 and a backtrace: #0 0x080b4638 in dw::oof::OOFAwareWidget::OOFAwareWidgetIterator::getPart ( this=0x836ec60, sectionIndex=5, index=8, content=0x836ec64) at oofawarewidget_iterator.cc:102 #1 0x080b4822 in dw::oof::OOFAwareWidget::OOFAwareWidgetIterator::prev ( this=0x836ec60) at oofawarewidget_iterator.cc:216 #2 0x080c3d5c in dw::core::DeepIterator::prev (this=this at entry=0x83712b0) at iterator.cc:708 #3 0x080c4058 in dw::core::CharIterator::prev (this=0x8360298) at iterator.cc:825 #4 0x080c2877 in dw::core::FindtextState::search (this=0x82c6244, key=key at entry=0x836e9d8 "the", caseSens=false, backwards=backwards at entry=true) at findtext.cc:135 #5 0x08058e43 in search (backwards=1, caseSens=false, str=0x836e9d8 "the", this=<optimized out>) at ../dw/layout.hh:431 #6 a_UIcmd_findtext_search (bw=0x82c5768, key=0x836e9d8 "the", case_sens=0, backward=1) at uicmd.cc:1484 #7 0x08089964 in Findbar::searchBackwards_cb (vfb=0x826d4c8) at findbar.cc:100 #8 0xb7ef2677 in Fl_Widget::do_callback(Fl_Widget*, void*) () from /usr/lib/libfltk.so.1.3 #9 0xb7e99d13 in Fl_Button::handle(int) () from /usr/lib/libfltk.so.1.3 #10 0xb7e91098 in ?? () from /usr/lib/libfltk.so.1.3 #11 0xb7e92ffd in Fl::handle_(int, Fl_Window*) () from /usr/lib/libfltk.so.1.3 #12 0xb7e9340c in Fl::handle(int, Fl_Window*) () from /usr/lib/libfltk.so.1.3 #13 0xb7efa0a8 in fl_handle(_XEvent const&) () from /usr/lib/libfltk.so.1.3 ---Type <return> to continue, or q <return> to quit--- #14 0xb7efb400 in ?? () from /usr/lib/libfltk.so.1.3 #15 0xb7efb5f2 in ?? () from /usr/lib/libfltk.so.1.3 #16 0xb7e929c7 in Fl::wait(double) () from /usr/lib/libfltk.so.1.3 #17 0xb7e92ace in Fl::run() () from /usr/lib/libfltk.so.1.3 #18 0x080514e0 in main (argc=1, argv=0xbffff0d4) at dillo.cc:578 Hope that helps. Nick -- Gosh that takes me back... or is it forward? That's the trouble with time travel, you never can tell." -- Doctor Who "Androids of Tara"

May 15, 2016