Re: CPU hog bug with https?

On Wed, May 18, 2016 at 11:08:03PM +0200, Sebastian Geerken wrote:
> Hi Jorge,
> 
> On Di, Mai 17, 2016, Jorge Arellano Cid wrote:
> > 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!
> 
> Thanks for the good work!

  You're welcomed.

  I aim at reducing your workload so you can focus on corework.
BTW, the speed improvements introduced with GROWS2, and the way I picture
dillo's rendering once floats/absolutes work right are quite motivating. ;)


> It also seems to fix the problems with
> netzpolitik.org and nachdenkseiten.de. (Others please check this,
> too.)

  Both sites render blazingly fast here.

> > [...]
> >   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. ;-)
> 
> Yes, this is the usual way I track down bugs, too. This is much
> simpler for rendering bugs, which can be preserved while simplifying
> the page. This kind of bug is much more difficult since the effect
> (taking too much time) vanishes the more the simpler the page gets.

  Good point.

-- 
  Cheers
  Jorge.-