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 -- Cheers Jorge.-
On Sun, May 01, 2016 at 12:36:39PM -0300, Jorge Arellano Cid wrote:
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'm not getting a dialog here. What is the page pulling in that dillo is complaining about? I allowed linux.slashdot.org www.gstatic.com linux.slashdot.org analytics.slashdotmedia.com linux.slashdot.org a.fsdn.com linux.slashdot.org s3-us-west-2.amazonaws.com in domainrc, but it doesn't look like any of those are over https.
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. Sebastian
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.-
On Tue, 17 May 2016 21:45:27 -0400 Jorge Arellano Cid <jcid at dillo.org> wrote:
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. ;-)
It is quiet amazing sometimes how a simple typo/mind mistake can take ages to track down. Well down Jorge! 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"
On Wed, 18 May 2016 19:00:44 +0100 Nick Warne <nick at linicks.net> wrote:
On Tue, 17 May 2016 21:45:27 -0400 Jorge Arellano Cid <jcid at dillo.org> wrote:
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. ;-)
It is quiet amazing sometimes how a simple typo/mind mistake can take ages to track down.
Well down Jorge!
Duh! Proves the point. Well done Jorge! 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"
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! It also seems to fix the problems with netzpolitik.org and nachdenkseiten.de. (Others please check this, too.) I've one case in my list, which is already analyzed. More on this later.
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. ;-)
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. Sebastian
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.-
On Mi, Mai 18, 2016, Jorge Arellano Cid wrote:
On Wed, May 18, 2016 at 11:08:03PM +0200, Sebastian Geerken wrote:
It also seems to fix the problems with netzpolitik.org and nachdenkseiten.de. (Others please check this, too.)
Both sites render blazingly fast here.
The (occasional) problem with the text under the float seems to have gone. Sebastian
On Thu, May 19, 2016 at 06:06:32AM +0200, Sebastian Geerken wrote:
On Mi, Mai 18, 2016, Jorge Arellano Cid wrote:
On Wed, May 18, 2016 at 11:08:03PM +0200, Sebastian Geerken wrote:
It also seems to fix the problems with netzpolitik.org and nachdenkseiten.de. (Others please check this, too.)
Both sites render blazingly fast here.
The (occasional) problem with the text under the float seems to have gone.
Oh, I see. nachdenkseiten.de showed the bug 4 of 4 times without the patch and none with patched version. netzpolitik.org doesn't show the bug here. Neither from net, nor locally. -- Cheers Jorge.-
participants (4)
-
eocene＠gmx.com -
jcid＠dillo.org -
nick＠linicks.net -
sgeerken＠dillo.org