M-x eww performance

M-x eww performance

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 957 bytes --]

Hi all,

I have noticed that eww opens web pages fine in emacs -Q.

But when using my emacs config, my emacs gets bogged down when I try to
open certain web pages in eww. A recent example is
http://www.braveclojure.com/basic-emacs/.

By "bogged down", I mean that once I do M-x eww and yank that link, whole
emacs would freeze and I would need to repeatedly hit C-g to abort whatever
was going on in the background. A few times, I had to resort to kill -9
from the terminal. This issue does not happen in emacs -Q. And also this
issue is not something recent.. I have seen this to happen on/off only for
certain web pages, ever since I started using eww (which is awesome!).

Before I start to gradually comment out my emacs init to debug this, I was
curious if anyone else saw this too and found any of the common minor mode
packages to be the culprit.

I am using the latest emacs from trunk.

​Thank you.
​

--
Kaushal Modi

[-- Attachment #2: Type: text/html, Size: 2630 bytes --]

Re: M-x eww performance

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 1312 bytes --]

Well .. I got even emacs -Q to freeze with that particular website.

- emacs -Q
- M-x eww http://www.braveclojure.com/basic-emacs

If someone else can confirm this too, I will file a bug report.


--
Kaushal Modi

On Thu, Oct 22, 2015 at 3:47 PM, Kaushal Modi <kaushal.modi@gmail.com>
wrote:

> Hi all,
>
> I have noticed that eww opens web pages fine in emacs -Q.
>
> But when using my emacs config, my emacs gets bogged down when I try to
> open certain web pages in eww. A recent example is
> http://www.braveclojure.com/basic-emacs/.
>
> By "bogged down", I mean that once I do M-x eww and yank that link, whole
> emacs would freeze and I would need to repeatedly hit C-g to abort whatever
> was going on in the background. A few times, I had to resort to kill -9
> from the terminal. This issue does not happen in emacs -Q. And also this
> issue is not something recent.. I have seen this to happen on/off only for
> certain web pages, ever since I started using eww (which is awesome!).
>
> Before I start to gradually comment out my emacs init to debug this, I was
> curious if anyone else saw this too and found any of the common minor mode
> packages to be the culprit.
>
> I am using the latest emacs from trunk.
>
> ​Thank you.
> ​
>
> --
> Kaushal Modi
>

[-- Attachment #2: Type: text/html, Size: 4038 bytes --]

Re: M-x eww performance

[Eli Zaretskii]

> From: Kaushal Modi <kaushal.modi@gmail.com>
> Date: Thu, 22 Oct 2015 15:54:41 -0400
> 
> Well .. I got even emacs -Q to freeze with that particular website.
> 
> - emacs -Q
> - M-x eww http://www.braveclojure.com/basic-emacs 
> 
> If someone else can confirm this too, I will file a bug report.

Doesn't happen here.

If you set debug-on-quit before invoking eww, then type C-g while it
hangs, what does the backtrace show?

Re: M-x eww performance

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 495 bytes --]

> If you set debug-on-quit before invoking eww, then type C-g while it
> hangs, what does the backtrace show?

My emacs -Q session freezes as soon as I do M-x eww SITE RET
C-g does not help. I do see that the webpage started to load and I see
"Contacting host: www.braveclojure.com:80" in the echo area.

I will trying "C-g"ing every few minutes this time before resorting to
killing it from the terminal. But I doubt it will recover.

May be it's time to finally give a try to debug via gdb...

[-- Attachment #2: Type: text/html, Size: 1047 bytes --]

Re: M-x eww performance

[Michael Heerdegen]

Kaushal Modi <kaushal.modi@gmail.com> writes:

> Well .. I got even emacs -Q to freeze with that particular website.
>
> - emacs -Q
> - M-x eww http://www.braveclojure.com/basic-emacs 

Works well for me.

Michael.

Re: M-x eww performance

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 297 bytes --]

> Works well for me.

Thanks for confirming guys. The problem then could be my build or my build
environment (RHEL 6.1).

I am currently rebuilding without the optimization flags and will be
working through these steps ( http://emacs.stackexchange.com/a/14376/115 )
to get some useful debug info.

[-- Attachment #2: Type: text/html, Size: 730 bytes --]

Re: M-x eww performance

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 5213 bytes --]

> I am currently rebuilding without the optimization flags and will be
working through these steps ( http://emacs.stackexchange.com/a/14376/115 )
to get some useful debug info.

My first backtrace from gdb!

- I built emacs without the optimization flags
- cd src/
- gdb ./emacs
- r -Q
- M-x eww http://www.braveclojure.com/basic-emacs

As expected emacs froze after that.

Then from the terminal where I had gdb running, I hit C-z in the (gdb)
prompt and then bt.

I hope this helps debug the problem:

Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html
>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/kmodi/downloads/git/emacs/src/emacs...done.
SIGINT is used by the debugger.
Are you sure you want to change it? (y or n) [answered Y; input not from
terminal]
DISPLAY = :1
TERM = xterm-256color
Breakpoint 1 at 0x555b81: file emacs.c, line 371.
Temporary breakpoint 2 at 0x5793d6: file sysdep.c, line 905.
(gdb) r -Q
Starting program: /home/kmodi/downloads/git/emacs/src/emacs -Q
Missing separate debuginfo for /home/kmodi/usr_local/6/lib64/libgif.so.4
Try: yum --enablerepo='*-debug*' install
/usr/lib/debug/.build-id/4d/d406f2679fcf6adf281479e95a0ae8f66c7c4e.debug
[Thread debugging using libthread_db enabled]
[New Thread 0x7fffed737700 (LWP 39840)]

(emacs:39833): GLib-GIO-CRITICAL **: g_settings_schema_source_lookup:
assertion 'source != NULL' failed
[New Thread 0x7fffe5c21700 (LWP 39876)]
emacs: Memory allocation failed `No such file or directory' @
fatal/tiff.c/UnregisterTIFFImage/2077.
^Z
Program received signal SIGTSTP, Stopped (user).
0x0000003a9840eb9e in ?? () from /usr/lib64/libgomp.so.1
Missing separate debuginfos, use: debuginfo-install
GConf2-2.28.0-6.el6.x86_64 ORBit2-2.14.17-5.el6.x86_64
alsa-lib-1.0.22-3.el6.x86_64 atk-1.30.0-1.el6.x86_64
bzip2-libs-1.0.5-7.el6_0.x86_64 dbus-libs-1.2.24-7.el6_3.x86_64
expat-2.0.1-11.el6_2.x86_64 fftw-3.2.1-3.1.el6.x86_64
gdk-pixbuf2-2.24.1-5.el6.x86_64 glibc-2.12-1.149.el6_6.5.x86_64
gmp-4.3.1-7.el6_2.2.x86_64 gtk2-2.24.23-6.el6.x86_64
gtk2-engines-2.18.4-5.el6.x86_64 libICE-1.0.6-1.el6.x86_64
libSM-1.2.1-2.el6.x86_64 libX11-1.6.0-2.2.el6.x86_64
libXau-1.0.6-4.el6.x86_64 libXcomposite-0.4.3-4.el6.x86_64
libXcursor-1.1.14-2.1.el6.x86_64 libXdamage-1.1.3-4.el6.x86_64
libXext-1.3.2-2.1.el6.x86_64 libXfixes-5.0.1-2.1.el6.x86_64
libXft-2.3.1-2.el6.x86_64 libXi-1.7.2-2.2.el6.x86_64
libXinerama-1.1.3-2.1.el6.x86_64 libXpm-3.5.10-2.el6.x86_64
libXrandr-1.4.1-2.1.el6.x86_64 libXrender-0.9.8-2.1.el6.x86_64
libXt-1.1.4-6.1.el6.x86_64 libacl-2.2.49-6.el6.x86_64
libattr-2.4.44-7.el6.x86_64 libcroco-0.6.2-5.el6.x86_64
libgomp-4.4.7-11.el6.x86_64 libgsf-1.14.15-5.el6.x86_64
libjpeg-turbo-1.2.1-3.el6_5.x86_64 librsvg2-2.26.0-14.el6.x86_64
libselinux-2.0.94-5.8.el6.x86_64 libtiff-3.9.4-10.el6_5.x86_64
libuuid-2.17.2-12.18.el6.x86_64 libxcb-1.9.1-2.el6.x86_64
libxml2-2.7.6-14.el6_5.2.x86_64 ncurses-libs-5.7-3.20090208.el6.x86_64
pango-1.28.1-10.el6.x86_64 sssd-client-1.11.6-30.el6.x86_64
xz-libs-4.999.9-0.5.beta.20091007git.el6.x86_64 zlib-1.2.3-29.el6.x86_64
(gdb) bt
#0  0x0000003a9840eb9e in ?? () from /usr/lib64/libgomp.so.1
#1  0x00007ffff60875f8 in MagickCoreTerminus ()
   from /home/kmodi/usr_local/6/lib/libMagickCore-6.Q16.so.2
#2  0x00007ffff604a584 in DefaultFatalErrorHandler ()
   from /home/kmodi/usr_local/6/lib/libMagickCore-6.Q16.so.2
#3  0x00007ffff604adb2 in CatchException () from
/home/kmodi/usr_local/6/lib/libMagickCore-6.Q16.so.2
#4  0x00007ffff621f6c8 in UnregisterTIFFImage ()
   from /home/kmodi/usr_local/6/lib/libMagickCore-6.Q16.so.2
#5  0x00007ffff60f6580 in UnregisterStaticModules ()
   from /home/kmodi/usr_local/6/lib/libMagickCore-6.Q16.so.2
#6  0x00007ffff6087638 in MagickCoreTerminus ()
   from /home/kmodi/usr_local/6/lib/libMagickCore-6.Q16.so.2
#7  0x0000000000692ac9 in imagemagick_load_image (f=0x12afcb0,
img=0x1dc7f20,
    contents=0x1e72668 "\211PNG\r\n\032\n", size=134459, filename=0x0) at
image.c:8797
#8  0x0000000000692c9c in imagemagick_load (f=0x12afcb0, img=0x1dc7f20) at
image.c:8850
#9  0x0000000000688486 in lookup_image (f=0x12afcb0, spec=30372019) at
image.c:1751
#10 0x0000000000686cd7 in Fimage_metadata (spec=30372019, frame=0) at
image.c:929
#11 0x00000000005f847b in Ffuncall (nargs=2, args=0x7fffffff7358) at
eval.c:2653
#12 0x000000000063c363 in exec_byte_code (bytestr=11206404,
vector=11206437, maxdepth=14,
    args_template=0, nargs=0, args=0x0) at bytecode.c:880
#13 0x00000000005f8f7f in funcall_lambda (fun=11206341, nargs=1,
arg_vector=0xaaff25) at eval.c:2876
#14 0x00000000005f86f2 in Ffuncall (nargs=2, args=0x7fffffff7878) at
eval.c:2699
#15 0x000000000063c363 in exec_byte_code (bytestr=25447380,
vector=19937781, maxdepth=38,
    args_template=0, nargs=0, args=0x0) at bytecode.c:880
#16 0x00000000005f8f7f in funcall_lambda (fun=19934037, nargs=3,
arg_vector=0x13039f5) at eval.c:2876

[-- Attachment #2: Type: text/html, Size: 6596 bytes --]

Re: M-x eww performance

[Óscar Fuentes]

Kaushal Modi <kaushal.modi@gmail.com> writes:

>> I am currently rebuilding without the optimization flags and will be
> working through these steps ( http://emacs.stackexchange.com/a/14376/115 )
> to get some useful debug info.
>
> My first backtrace from gdb!

Please create a bug report with all this info, otherwise it can be
forgotten just because the people that can fix is busy right now.

Thanks.

(BTW, I occassionally see eww freeze while accessing certain pages,
although it is not predictable and seems related to fetching page
components throught TLS (trackers, most of the time). Pressing C-g
repeatedly seems to fix the stuck eww, although sometimes Emacs crashes
while pressing C-g.)

Re: M-x eww performance

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 173 bytes --]

> Please create a bug report with all this info

Done! https://debbugs.gnu.org/cgi/bugreport.cgi?bug=21738

Further discussion related to this issue can be continued there.

[-- Attachment #2: Type: text/html, Size: 538 bytes --]

Re: M-x eww performance

[Matthew Carter]

Kaushal Modi <kaushal.modi@gmail.com> writes:

>> Please create a bug report with all this info
>
> Done! https://debbugs.gnu.org/cgi/bugreport.cgi?bug=21738
>
> Further discussion related to this issue can be continued there.

It may not be the issue for your site, but I had issues with eww locking
up a year or so ago when hitting a site with a cookie expiration after
2038 when browsing on a 32 bit machine.

https://en.wikipedia.org/wiki/Year_2038_problem

Since at the time the cookie with a 2038+ expiration cookie was from my
own site,
I just set the cookie expiration date to be less than 2038 (and hope I
will no longer be using this 32 bit machine in 23 years from now).

I don't remember if I ever filed an official bug report for the issue.

Is your machine 32 bit?  Are the users not having an issue running 64 bit?

-- 
Matthew Carter (m@ahungry.com)
http://ahungry.com

Re: M-x eww performance

[Kaushal Modi]

Hi Matthew,

Thanks for the reply. I am on 64-bit machine. How do you set cookie
expiration date? I have no experience with web design.

--
Kaushal Modi

Re: M-x eww performance

[Matthew Carter]

Kaushal Modi <kaushal.modi@gmail.com> writes:

> Hi Matthew,
>
> Thanks for the reply. I am on 64-bit machine. How do you set cookie
> expiration date? I have no experience with web design.
>
> --
> Kaushal Modi

It's something you would control as the maintainer of the website - as a
web visitor, you wouldn't.

-- 
Matthew Carter (m@ahungry.com)
http://ahungry.com

Re: M-x eww performance

[raman]

Cookies are handled by the url library in Emacs -- it predates EWW and
was originally part of the W3 browser.

To see if it is indeed the cookies that are the issue, try setting 
 
 url-cookie-storage  and  url-cookie-secure-storage to nil before
 loading the site.
-- 

Re: M-x eww performance

[Eli Zaretskii]

> From: Matthew Carter <m@ahungry.com>
> Date: Thu, 22 Oct 2015 22:24:22 -0400
> Cc: Óscar Fuentes <ofv@wanadoo.es>,
> 	Emacs developers <emacs-devel@gnu.org>
> 
> It may not be the issue for your site, but I had issues with eww locking
> up a year or so ago when hitting a site with a cookie expiration after
> 2038 when browsing on a 32 bit machine.
> 
> https://en.wikipedia.org/wiki/Year_2038_problem

FWIW, I have no problems displaying that on a 32-bit machine with the
latest development code.

Re: M-x eww performance

[Rasmus]

Kaushal Modi <kaushal.modi@gmail.com> writes:

>> Works well for me.
>
> Thanks for confirming guys. The problem then could be my build or my build
> environment (RHEL 6.1).
>
> I am currently rebuilding without the optimization flags and will be
> working through these steps ( http://emacs.stackexchange.com/a/14376/115 )
> to get some useful debug info.

Kill -usr2 ${EMACS-PID} will sometimes also give you backtrace.

-- 
This space is left intentionally blank