bug#21738: 25.0.50; eww freezes/crashes at times

bug#21738: 25.0.50; eww freezes/crashes at times

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 9108 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 built emacs from the latest commit on trunk without the optimization
flags and followed the below steps.

- cd src/
- gdb ./emacs
- r -Q
- M-x eww http://www.braveclojure.com/basic-emacs

The emacs frame froze after that. I couldn't click anywhere in the frame
and none of the bindings (including repeated C-g) worked.

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

Below is backtrace from gdb.

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


Below follows the auto generated data by M-x report-emacs-bug

=================================================

In GNU Emacs 25.0.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.24.23)
 of 2015-10-22
Repository revision: d4352f813a0703cc7f7a873525131b272ef0c105
Windowing system distributor 'The X.Org Foundation', version 11.0.60900000
System Description: Red Hat Enterprise Linux Workstation release 6.6
(Santiago)

Configured using:
 'configure --prefix=/home/kmodi/usr_local/apps/6/emacs/master_debug
 'CPPFLAGS=-fgnu89-inline -I/home/kmodi/usr_local/6/include
 -I/usr/include/freetype2 -I/usr/include' 'CFLAGS=-ggdb3 -O0'
 'CXXFLAGS=-ggdb3 -O0' 'LDFLAGS=-L/home/kmodi/usr_local/6/lib
 -L/home/kmodi/usr_local/6/lib64 -ggdb3''

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GCONF GSETTINGS
NOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK2 X11

Important settings:
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=none
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Making completion list...

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr emacsbug message dired format-spec
rfc822 mml mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util help-fns help-mode easymenu cl-loaddefs pcase cl-lib mail-prsvr
mail-utils time-date mule-util tooltip eldoc electric uniquify
ediff-hook vc-hooks lisp-float-type mwheel x-win term/common-win x-dnd
tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment
elisp-mode lisp-mode prog-mode register page menu-bar rfn-eshadow timer
select scroll-bar mouse jit-lock font-lock syntax facemenu font-core
frame cl-generic cham georgian utf-8-lang misc-lang vietnamese tibetan
thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian
slovak czech european ethiopic indian cyrillic chinese charscript
case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer
cl-preloaded nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote dbusbind inotify
dynamic-setting system-font-setting font-render-setting move-toolbar gtk
x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 81455 6460)
 (symbols 48 19396 0)
 (miscs 40 43 111)
 (strings 32 12860 4655)
 (string-bytes 1 377992)
 (vectors 16 11419)
 (vector-slots 8 426882 4822)
 (floats 8 136 46)
 (intervals 56 220 0)
 (buffers 976 12)
 (heap 1024 13206 767))


--
Kaushal Modi

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

bug#21738: 25.0.50; eww freezes/crashes at times

[Wolfgang Jenkner]

On Thu, Oct 22 2015, Kaushal Modi wrote:

> I have noticed that eww opens web pages fine in emacs -Q.
[...]
> - cd src/
> - gdb ./emacs
> - r -Q
-------^
> - M-x eww http://www.braveclojure.com/basic-emacs
>
> The emacs frame froze after that. I couldn't click anywhere in the frame
> and none of the bindings (including repeated C-g) worked.

Isn't this slightly contradictory?

bug#21738: 25.0.50; eww freezes/crashes at times

[Kaushal Modi]

> Isn't this slightly contradictory?

I didn't understand what's contradictory ..

I am simply verifying that it is not my emacs init that's causing this problem.

I used gdb for the very first time based on this guide (
http://emacs.stackexchange.com/a/14376/115 ).
There the solution poster says:
> Type r to start Emacs. You can pass extra arguments on the same line, e.g. r --debug-init.

So just as I would do "emacs -Q" in a non-gdb launch, in gdb I did
"gdb ./emacs" followed by "r -Q".


--
Kaushal Modi


On Thu, Oct 22, 2015 at 6:30 PM, Wolfgang Jenkner <wjenkner@inode.at> wrote:
> On Thu, Oct 22 2015, Kaushal Modi wrote:
>
>> I have noticed that eww opens web pages fine in emacs -Q.
> [...]
>> - cd src/
>> - gdb ./emacs
>> - r -Q
> -------^
>> - M-x eww http://www.braveclojure.com/basic-emacs
>>
>> The emacs frame froze after that. I couldn't click anywhere in the frame
>> and none of the bindings (including repeated C-g) worked.
>
> Isn't this slightly contradictory?

bug#21738: 25.0.50; eww freezes/crashes at times

[Kaushal Modi]

Ah, sorry, now I got it.

That was a copy-paste from an earlier discussion from emacs-devel
where in the first post I say that I do not see the issue in emacs -Q
sessions.
But by chance the URL example (braveclojure.com) I gave in that thread
consistently froze my emacs with or without -Q :)

bug#21738: 25.0.50; eww freezes/crashes at times

[Eli Zaretskii]

> From: Kaushal Modi <kaushal.modi@gmail.com>
> Date: Thu, 22 Oct 2015 18:12:01 -0400
> Cc: Eli Zaretskii <eliz@gnu.org>, Óscar Fuentes <ofv@wanadoo.es>
> 
> - cd src/
> - gdb ./emacs
> - r -Q
> - M-x eww http://www.braveclojure.com/basic-emacs
> 
> The emacs frame froze after that. I couldn't click anywhere in the frame and
> none of the bindings (including repeated C-g) worked.
> 
> Then from the terminal where I had gdb running, I hit C-z in the (gdb) prompt
> and then bt.
> 
> Below is backtrace from gdb.
> 
> #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

This indicates that Emacs hangs inside Imagemagick code, trying to
display one of the images on that page.  Can you build Emacs without
Imagemagick support, and see if that fixes the problem?

Also, you originally said that "emacs -Q" doesn't exhibit this
problem, but now you've succeeded in reproducing it in "emacs -Q" as
well.  What did you need to do in order to succeed reproducing this in
"emacs -Q"?

bug#21738: 25.0.50; eww freezes/crashes at times

[Kaushal Modi]

Thanks Eli.

> This indicates that Emacs hangs inside Imagemagick code, trying to
> display one of the images on that page.  Can you build Emacs without
> Imagemagick support, and see if that fixes the problem?

eww works fine without Imagemagick.
But then I lose all the emacs features that need Imagemagick (like
formula image rendering in org-> latex exports).

Does the backtrace give a hint to what could have gone wrong with the
Imagemagick build?
What Imagemagick version are you using?

Does this error hint anything?

> emacs: Memory allocation failed `No such file or directory' @ fatal/tiff.c/UnregisterTIFFImage/2077

> Also, you originally said that "emacs -Q" doesn't exhibit this
> problem, but now you've succeeded in reproducing it in "emacs -Q" as
> well.  What did you need to do in order to succeed reproducing this in
> "emacs -Q"?

I usually use eww to open few work internal websites which are
autogenerated with an SVG plot and a huge HTML table. I have seen
those pages to open fine on emacs -Q but fail to load *sometimes* on
my emacs with my config loaded.

It just happens that yesterday I tried opening braveclojure.com in eww
and it froze my emacs and so I sent that email to emacs-devel. I
simply assumed that it will open fine on emacs -Q. But now we know
that it froze my emacs -Q too. I have consistently been able to freeze
emacs -Q (built with Imagemagick) when I open that braveclojure.com
site on eww.

--
Kaushal Modi

bug#21738: 25.0.50; eww freezes/crashes at times

[Eli Zaretskii]

> From: Kaushal Modi <kaushal.modi@gmail.com>
> Date: Fri, 23 Oct 2015 10:01:30 -0400
> Cc: 21738@debbugs.gnu.org
> 
> > This indicates that Emacs hangs inside Imagemagick code, trying to
> > display one of the images on that page.  Can you build Emacs without
> > Imagemagick support, and see if that fixes the problem?
> 
> eww works fine without Imagemagick.
> But then I lose all the emacs features that need Imagemagick (like
> formula image rendering in org-> latex exports).

Is your Imagemagick up-to-date?  If not, perhaps this is some bug in
Imagemagick that was already fixed, so upgrading might fix it.  Or
maybe downgrade to some previous version.

Another idea woukd be to ask on emacs-devel which versions of
Imagemagick do people use who can successfully display that page.

> Does the backtrace give a hint to what could have gone wrong with the
> Imagemagick build?

Not to me, I'm not familiar with Imagemagick enough for that.

> What Imagemagick version are you using?

I don't.  That's why I thought about building without it.

> Does this error hint anything?
> 
> > emacs: Memory allocation failed `No such file or directory' @ fatal/tiff.c/UnregisterTIFFImage/2077

It seems to be related, because the backtrace also points to that
function:

  #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

According to this, the function UnregisterStaticModules generated a
fatal exception.  I don't quite understand how "memory allocation
failed" can be explained by "No such file or directory", but then I'm
not familiar with Imagemagick in general and with that function in
particular.

> > Also, you originally said that "emacs -Q" doesn't exhibit this
> > problem, but now you've succeeded in reproducing it in "emacs -Q" as
> > well.  What did you need to do in order to succeed reproducing this in
> > "emacs -Q"?
> 
> I usually use eww to open few work internal websites which are
> autogenerated with an SVG plot and a huge HTML table. I have seen
> those pages to open fine on emacs -Q but fail to load *sometimes* on
> my emacs with my config loaded.
> 
> It just happens that yesterday I tried opening braveclojure.com in eww
> and it froze my emacs and so I sent that email to emacs-devel. I
> simply assumed that it will open fine on emacs -Q. But now we know
> that it froze my emacs -Q too. I have consistently been able to freeze
> emacs -Q (built with Imagemagick) when I open that braveclojure.com
> site on eww.

The images on that page are PNG image files.  Can you display PNG
image files with an Emacs compiled with Imagemagick support, or does
Emacs hang (or crash) with every PNG file?

bug#21738: 25.0.50; eww freezes/crashes at times

[Kaushal Modi]

> Is your Imagemagick up-to-date?  If not, perhaps this is some bug in
> Imagemagick that was already fixed, so upgrading might fix it.  Or
> maybe downgrade to some previous version.

I am on a fairly recent version: 6.8.9.1 (The latest as of today is 6.9.2.4).

> Another idea woukd be to ask on emacs-devel which versions of
> Imagemagick do people use who can successfully display that page.

Will do.

> I don't.  That's why I thought about building without it.

OK. Have you felt any reason to ever build with Imagemagick because
emacs built without it lacked any feature you needed?

> It seems to be related, because the backtrace also points to that
> function:
>
>   #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
>
> According to this, the function UnregisterStaticModules generated a
> fatal exception.  I don't quite understand how "memory allocation
> failed" can be explained by "No such file or directory", but then I'm
> not familiar with Imagemagick in general and with that function in
> particular.

OK.

> The images on that page are PNG image files.  Can you display PNG
> image files with an Emacs compiled with Imagemagick support, or does
> Emacs hang (or crash) with every PNG file?

You know what, I always thought that I can display PNG files in emacs.
In the version built with Imagemagick, it even successfully displayed
a PNG file.

C-x C-f SOMEFILE.png

When in the same buffer when I did

C-x C-f SOMEOTHERFILE.png

my emacs froze just like in that eww experiment!

So just the first png displayed fine.

bug#21738: 25.0.50; eww freezes/crashes at times

[Eli Zaretskii]

> From: Kaushal Modi <kaushal.modi@gmail.com>
> Date: Fri, 23 Oct 2015 10:41:34 -0400
> Cc: 21738@debbugs.gnu.org
> 
> > Another idea woukd be to ask on emacs-devel which versions of
> > Imagemagick do people use who can successfully display that page.
> 
> Will do.
> 
> > I don't.  That's why I thought about building without it.
> 
> OK. Have you felt any reason to ever build with Imagemagick because
> emacs built without it lacked any feature you needed?

No.  I don't have much use for showing images in Emacs.

> > The images on that page are PNG image files.  Can you display PNG
> > image files with an Emacs compiled with Imagemagick support, or does
> > Emacs hang (or crash) with every PNG file?
> 
> You know what, I always thought that I can display PNG files in emacs.
> In the version built with Imagemagick, it even successfully displayed
> a PNG file.
> 
> C-x C-f SOMEFILE.png
> 
> When in the same buffer when I did
> 
> C-x C-f SOMEOTHERFILE.png
> 
> my emacs froze just like in that eww experiment!
> 
> So just the first png displayed fine.

I guess it's time to ask on emacs-devel what versions others use, and
whether they have problems with PNG?

bug#21738: 25.0.50; eww freezes/crashes at times

[Wolfgang Jenkner]

On Fri, Oct 23 2015, Kaushal Modi wrote:

> C-x C-f SOMEFILE.png
>
> When in the same buffer when I did
>
> C-x C-f SOMEOTHERFILE.png
>
> my emacs froze just like in that eww experiment!
>
> So just the first png displayed fine.

What happens when you try this with other types of image files (e.g.,
jpg)?

bug#21738: 25.0.50; eww freezes/crashes at times

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

> I don't quite understand how "memory allocation failed" can be
> explained by "No such file or directory",

It just means that ImageMagick does not track errno precicely.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

bug#21738: 25.0.50; eww freezes/crashes at times

[Glenn Morris]

Kaushal Modi wrote:

> C-x C-f SOMEFILE.png
>
> When in the same buffer when I did
>
> C-x C-f SOMEOTHERFILE.png
>
> my emacs froze just like in that eww experiment!

I was going to say that this uses libpng, not ImageMagick.
But I see this has been changed in master v 24.5.
I see no relevant NEWS entry.

Previously (IIRC) we recommended against making such a change, precisely
because ImageMagick seemed to be a bit flakier than more "traditional"
image libraries.

(eww/shr is different since it uses ImageMagick so it can rescale.)

bug#21738: 25.0.50; eww freezes/crashes at times

[Kaushal Modi]

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

Hi all,

I updated to the latest Imagemagick (v 6.9.2-4) and "r -Q" emacs
session still freezes in gdb when I evaluate

(eww "http://www.braveclojure.com/basic-emacs")

This time though, I got a much longer backtrace (attached) but the
main error is still similar (that number following UnregisterTIFFImage
changed):

> emacs: Memory allocation failed `No such file or directory' @ fatal/tiff.c/UnregisterTIFFImage/2379.

[-- Attachment #2: emacs_25_Imagemagick_eww_freeze_gdb_bt.log --]
[-- Type: application/octet-stream, Size: 12981 bytes --]

(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 0x7fffedb6f700 (LWP 37949)]

(emacs:37940): GLib-GIO-CRITICAL **: g_settings_schema_source_lookup: assertion 'source != NULL' failed
[New Thread 0x7fffe5b13700 (LWP 38143)]
emacs: Memory allocation failed `No such file or directory' @ fatal/tiff.c/UnregisterTIFFImage/2379.
^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 libgcc-4.4.7-11.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  0x00007ffff607b388 in LockMagickMutex () at ./magick/semaphore-private.h:63
#2  MagickCoreTerminus () at magick/magick.c:1368
#3  0x00007ffff603c559 in DefaultFatalErrorHandler (severity=FatalErrorException,
    reason=<value optimized out>, description=0x0) at magick/exception.c:335
#4  0x00007ffff603cb00 in CatchException (exception=0x194bdd0) at magick/exception.c:211
#5  0x00007ffff62223da in UnregisterTIFFImage () at coders/tiff.c:2379
#6  0x00007ffff60ea975 in UnregisterStaticModules () at magick/static.c:485
#7  0x00007ffff607b3ca in MagickCoreTerminus () at magick/magick.c:1389
#8  0x0000000000692ad5 in imagemagick_load_image (f=0x12ae8b0, img=0x18c3b10,
    contents=0x26847a8 "\211PNG\r\n\032\n", size=134459, filename=0x0) at image.c:8797
#9  0x0000000000692ca8 in imagemagick_load (f=0x12ae8b0, img=0x18c3b10) at image.c:8850
#10 0x0000000000688492 in lookup_image (f=0x12ae8b0, spec=37629795) at image.c:1751
#11 0x0000000000686ce3 in Fimage_metadata (spec=37629795, frame=0) at image.c:929
#12 0x00000000005f8487 in Ffuncall (nargs=2, args=0x7fffffff4f18) at eval.c:2653
#13 0x000000000063c36f in exec_byte_code (bytestr=11206412, vector=11206445, maxdepth=14,
    args_template=0, nargs=0, args=0x0) at bytecode.c:880
#14 0x00000000005f8f8b in funcall_lambda (fun=11206349, nargs=1, arg_vector=0xaaff2d) at eval.c:2876
#15 0x00000000005f86fe in Ffuncall (nargs=2, args=0x7fffffff5438) at eval.c:2699
#16 0x000000000063c36f in exec_byte_code (bytestr=26476228, vector=19890373, maxdepth=38,
    args_template=0, nargs=0, args=0x0) at bytecode.c:880
#17 0x00000000005f8f8b in funcall_lambda (fun=19886629, nargs=3, arg_vector=0x12f80c5) at eval.c:2876
#18 0x00000000005f86fe in Ffuncall (nargs=4, args=0x7fffffff5988) at eval.c:2699
#19 0x000000000063c36f in exec_byte_code (bytestr=25677076, vector=19886261, maxdepth=26,
    args_template=0, nargs=0, args=0x0) at bytecode.c:880
---Type <return> to continue, or q <return> to quit---
#20 0x00000000005f8f8b in funcall_lambda (fun=19127253, nargs=4, arg_vector=0x12f70b5) at eval.c:2876
#21 0x00000000005f86fe in Ffuncall (nargs=5, args=0x7fffffff5ec0) at eval.c:2699
#22 0x00000000005f78eb in Fapply (nargs=2, args=0x7fffffff6050) at eval.c:2278
#23 0x00000000005f835c in Ffuncall (nargs=3, args=0x7fffffff6048) at eval.c:2630
#24 0x000000000063c36f in exec_byte_code (bytestr=26798820, vector=27708837, maxdepth=30,
    args_template=0, nargs=0, args=0x0) at bytecode.c:880
#25 0x00000000005f8f8b in funcall_lambda (fun=27708981, nargs=2, arg_vector=0x1a6cda5) at eval.c:2876
#26 0x00000000005f86fe in Ffuncall (nargs=3, args=0x7fffffff6580) at eval.c:2699
#27 0x00000000005f78eb in Fapply (nargs=2, args=0x7fffffff6700) at eval.c:2278
#28 0x00000000005f835c in Ffuncall (nargs=3, args=0x7fffffff66f8) at eval.c:2630
#29 0x000000000063c36f in exec_byte_code (bytestr=29931604, vector=29590773, maxdepth=34,
    args_template=0, nargs=0, args=0x0) at bytecode.c:880
#30 0x00000000005f8f8b in funcall_lambda (fun=29591021, nargs=0, arg_vector=0x1c384f5) at eval.c:2876
#31 0x00000000005f86fe in Ffuncall (nargs=1, args=0x7fffffff6c48) at eval.c:2699
#32 0x000000000063c36f in exec_byte_code (bytestr=29943956, vector=29426061, maxdepth=38,
    args_template=0, nargs=0, args=0x0) at bytecode.c:880
#33 0x00000000005f8f8b in funcall_lambda (fun=29426181, nargs=3, arg_vector=0x1c1018d) at eval.c:2876
#34 0x00000000005f86fe in Ffuncall (nargs=4, args=0x7fffffff7198) at eval.c:2699
#35 0x000000000063c36f in exec_byte_code (bytestr=29962420, vector=29591189, maxdepth=18,
    args_template=0, nargs=0, args=0x0) at bytecode.c:880
#36 0x00000000005f8f8b in funcall_lambda (fun=29041581, nargs=2, arg_vector=0x1c38695) at eval.c:2876
#37 0x00000000005f86fe in Ffuncall (nargs=3, args=0x7fffffff76c0) at eval.c:2699
#38 0x00000000005f78eb in Fapply (nargs=2, args=0x7fffffff7780) at eval.c:2278
#39 0x00000000005f7e3b in apply1 (fn=16858272, arg=37621267) at eval.c:2494
#40 0x000000000064b80b in read_process_output_call (fun_and_args=37621251) at process.c:5237
---Type <return> to continue, or q <return> to quit---
#41 0x00000000005f52f3 in internal_condition_case_1 (bfun=0x64b7dd <read_process_output_call>,
    arg=37621251, handlers=0, hfun=0x64b80d <read_process_output_error_handler>) at eval.c:1333
#42 0x000000000064bfa0 in read_and_dispose_of_process_output (p=0x1c53ed8,
    chars=0x7fffffff78a0 "0\374\203\260\177\270\065\272\353^`\227\v\250ߊ\334\302dZ\253~\310vZ\217Պ,\"\"\"\307\003\263\200\211\311p\253~\303f'\340\231\265\004\333\351\226A\300|v\203s\260m\fe\274mMu2\237U@\016\f\307f\214Z\230\215\272dT\267\036\aށ\317\377\332Ɂ\375\216#,\206a\360ި\353\205\377s\340k\021\021\021\221\346d\025\230ͺ^\204\332\302l\325E#\330kBXg\340\264V\333ب\232\352\362pf\303\003[\215\255\356\356\027ؚ\\\255\372}\365\062\002\373%W_\032Ψ\265\330N7\v\f\206\005\006p\243g\243\355Qx\026\021\021\221\246f'@\006\353\346\340\061\230/Ԁ\f\346", <incomplete sequence \375\225>..., nbytes=2130, coding=0x1932460)
    at process.c:5445
#43 0x000000000064bbf5 in read_process_output (proc=29703901, channel=22) at process.c:5356
#44 0x000000000064b177 in wait_reading_process_output (time_limit=30, nsecs=0, read_kbd=-1,
    do_display=true, wait_for_cell=0, wait_proc=0x0, just_wait_proc=0) at process.c:5063
#45 0x00000000004240ef in sit_for (timeout=122, reading=true, display_option=1) at dispnew.c:5751
#46 0x000000000055d7e0 in read_char (commandflag=1, map=37621667, prev_event=0,
    used_mouse_menu=0x7fffffff912f, end_time=0x0) at keyboard.c:2700
#47 0x000000000056a83b in read_key_sequence (keybuf=0x7fffffff92f0, bufsize=30, prompt=0,
    dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true,
    prevent_redisplay=false) at keyboard.c:9028
#48 0x000000000055a511 in command_loop_1 () at keyboard.c:1346
#49 0x00000000005f518e in internal_condition_case (bfun=0x55a103 <command_loop_1>, handlers=18912,
    hfun=0x559900 <cmd_error>) at eval.c:1309
#50 0x0000000000559e0b in command_loop_2 (ignore=0) at keyboard.c:1086
#51 0x00000000005f4987 in internal_catch (tag=19632, func=0x559de2 <command_loop_2>, arg=0)
    at eval.c:1073
---Type <return> to continue, or q <return> to quit---
#52 0x0000000000559d45 in command_loop () at keyboard.c:1057
#53 0x00000000005594d5 in recursive_edit_1 () at keyboard.c:671
#54 0x0000000000559662 in Frecursive_edit () at keyboard.c:742
#55 0x00000000005f842f in Ffuncall (nargs=1, args=0x7fffffff9758) at eval.c:2647
#56 0x000000000063c36f in exec_byte_code (bytestr=26798916, vector=29345797, maxdepth=166,
    args_template=514, nargs=2, args=0x7fffffff9cb8) at bytecode.c:880
#57 0x00000000005f8c5a in funcall_lambda (fun=29346429, nargs=2, arg_vector=0x7fffffff9cb8)
    at eval.c:2810
#58 0x00000000005f86fe in Ffuncall (nargs=3, args=0x7fffffff9cb0) at eval.c:2699
#59 0x00000000005f78eb in Fapply (nargs=2, args=0x7fffffff9d70) at eval.c:2278
#60 0x00000000005f7e3b in apply1 (fn=16464, arg=29334707) at eval.c:2494
#61 0x00000000005f31b9 in call_debugger (arg=29334707) at eval.c:308
#62 0x00000000005f5e84 in maybe_call_debugger (conditions=9568955, sig=48816, data=29334659)
    at eval.c:1687
#63 0x00000000005f593e in Fsignal (error_symbol=48816, data=29334659) at eval.c:1506
#64 0x00000000005f5a62 in xsignal (error_symbol=48816, data=29334659) at eval.c:1542
#65 0x00000000005f5abd in xsignal1 (error_symbol=48816, arg=3374224) at eval.c:1557
#66 0x00000000005da862 in Fsymbol_value (symbol=3374224) at data.c:1201
#67 0x00000000005f6a32 in eval_sub (form=3374224) at eval.c:2029
#68 0x00000000005f89c9 in apply_lambda (fun=29013661, args=27145699, count=13) at eval.c:2746
#69 0x00000000005f723d in eval_sub (form=27145683) at eval.c:2168
#70 0x00000000005f67ca in Feval (form=27145683, lexical=0) at eval.c:1953
#71 0x00000000005f8487 in Ffuncall (nargs=3, args=0x7fffffffa318) at eval.c:2653
#72 0x000000000063c36f in exec_byte_code (bytestr=11106636, vector=11106669, maxdepth=22,
    args_template=1030, nargs=1, args=0x7fffffffa850) at bytecode.c:880
---Type <return> to continue, or q <return> to quit---
#73 0x00000000005f8c5a in funcall_lambda (fun=11106589, nargs=1, arg_vector=0x7fffffffa848)
    at eval.c:2810
#74 0x00000000005f86fe in Ffuncall (nargs=2, args=0x7fffffffa840) at eval.c:2699
#75 0x000000000063c36f in exec_byte_code (bytestr=11107372, vector=11107405, maxdepth=18,
    args_template=1030, nargs=1, args=0x7fffffffae78) at bytecode.c:880
#76 0x00000000005f8c5a in funcall_lambda (fun=11107317, nargs=1, arg_vector=0x7fffffffae70)
    at eval.c:2810
#77 0x00000000005f86fe in Ffuncall (nargs=2, args=0x7fffffffae68) at eval.c:2699
#78 0x00000000005f0519 in Ffuncall_interactively (nargs=2, args=0x7fffffffae68) at callint.c:248
#79 0x00000000005f835c in Ffuncall (nargs=3, args=0x7fffffffae60) at eval.c:2630
#80 0x00000000005f29bb in Fcall_interactively (function=3681328, record_flag=0, keys=13407221)
    at callint.c:836
#81 0x00000000005f84c5 in Ffuncall (nargs=4, args=0x7fffffffb1b8) at eval.c:2657
#82 0x000000000063c36f in exec_byte_code (bytestr=10416348, vector=10416381, maxdepth=54,
    args_template=4102, nargs=1, args=0x7fffffffb710) at bytecode.c:880
#83 0x00000000005f8c5a in funcall_lambda (fun=10416301, nargs=1, arg_vector=0x7fffffffb708)
    at eval.c:2810
#84 0x00000000005f86fe in Ffuncall (nargs=2, args=0x7fffffffb700) at eval.c:2699
#85 0x00000000005f7e8d in call1 (fn=14736, arg1=3681328) at eval.c:2509
#86 0x000000000055a8d3 in command_loop_1 () at keyboard.c:1458
#87 0x00000000005f518e in internal_condition_case (bfun=0x55a103 <command_loop_1>, handlers=18912,
    hfun=0x559900 <cmd_error>) at eval.c:1309
#88 0x0000000000559e0b in command_loop_2 (ignore=0) at keyboard.c:1086
#89 0x00000000005f4987 in internal_catch (tag=45552, func=0x559de2 <command_loop_2>, arg=0)
    at eval.c:1073
---Type <return> to continue, or q <return> to quit---
#90 0x0000000000559db4 in command_loop () at keyboard.c:1065
#91 0x00000000005594d5 in recursive_edit_1 () at keyboard.c:671
#92 0x0000000000559662 in Frecursive_edit () at keyboard.c:742
#93 0x0000000000557675 in main (argc=2, argv=0x7fffffffbbe8) at emacs.c:1644

Lisp Backtrace:
"image-metadata" (0xffff4f20)
"image-multi-frame-p" (0xffff5440)
"shr-put-image" (0xffff5990)
"shr-image-fetched" (0xffff5ec8)
"apply" (0xffff6050)
"url-queue-callback-function" (0xffff6588)
"apply" (0xffff6700)
"url-http-activate-callback" (0xffff6c50)
"url-http-content-length-after-change-function" (0xffff71a0)
"url-http-generic-filter" (0xffff76c8)
"recursive-edit" (0xffff9760)
"debug" (0xffff9cb8)
"eww" (0xffffa148)
"eval" (0xffffa320)
"elisp--eval-last-sexp" (0xffffa848)
"eval-last-sexp" (0xffffae70)
"funcall-interactively" (0xffffae68)
"call-interactively" (0xffffb1c0)
"command-execute" (0xffffb708)
(gdb)

bug#21738: 25.0.50; eww freezes/crashes at times

[Kaushal Modi]

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

Here is another backtrace for the same freeze issue (attached).

This time it was causing by doing C-x C-f of png files twice in the same buffer.

Here's how to recreate:

1. cd to src/ dir
2. gdb ./emacs
3. r -Q
4. C-x C-f SOMEFILE1.png (emacs has not frozen yet)
5. C-x C-f SOMEFILE2.png (emacs freezes instantly)

===========================================

Built on x86_64-unknown-linux-gnu
Configure options:
--prefix=/home/kmodi/usr_local/apps/6/emacs/master_debug
'CPPFLAGS=-fgnu89-inline -I/home/kmodi/usr_local/6/include
-I/usr/include/freetype2 -I/usr/include' 'CFLAGS=-ggdb3 -O0'
'CXXFLAGS=-ggdb3 -O0' 'LDFLAGS=-L/home/kmodi/usr_local/6/lib
-L/home/kmodi/usr_local/6/lib64 -ggdb3'
Features: XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GCONF
GSETTINGS NOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE LIBOTF XFT
ZLIB TOOLKIT_SCROLL_BARS GTK2 X11

[-- Attachment #2: emacs_25_Imagemagick_png_open_freeze_gdb_bt.log --]
[-- Type: application/octet-stream, Size: 9501 bytes --]

(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 0x7fffedb6f700 (LWP 16970)]

(emacs:16965): GLib-GIO-CRITICAL **: g_settings_schema_source_lookup: assertion 'source != NULL' failed
[New Thread 0x7fffe677a700 (LWP 16994)]
Detaching after fork from child process 16995.
Detaching after fork from child process 16996.
emacs: Memory allocation failed `No such file or directory' @ fatal/tiff.c/UnregisterTIFFImage/2379.
^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 libgcc-4.4.7-11.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  0x00007ffff607b388 in LockMagickMutex () at ./magick/semaphore-private.h:63
#2  MagickCoreTerminus () at magick/magick.c:1368
#3  0x00007ffff603c559 in DefaultFatalErrorHandler (severity=FatalErrorException,
    reason=<value optimized out>, description=0x0) at magick/exception.c:335
#4  0x00007ffff603cb00 in CatchException (exception=0x18a8070) at magick/exception.c:211
#5  0x00007ffff62223da in UnregisterTIFFImage () at coders/tiff.c:2379
#6  0x00007ffff60ea975 in UnregisterStaticModules () at magick/static.c:485
#7  0x00007ffff607b3ca in MagickCoreTerminus () at magick/magick.c:1389
#8  0x0000000000692ad5 in imagemagick_load_image (f=0x12ae8b0, img=0xd4ef10, contents=0x0, size=0,
    filename=0x1868598 "/home/kmodi/temp/Clipboard02.png") at image.c:8797
#9  0x0000000000692c0d in imagemagick_load (f=0x12ae8b0, img=0xd4ef10) at image.c:8836
#10 0x0000000000688492 in lookup_image (f=0x12ae8b0, spec=20838995) at image.c:1751
#11 0x0000000000686a91 in Fimage_size (spec=20838995, pixels=44160, frame=0) at image.c:876
#12 0x00000000005f84c5 in Ffuncall (nargs=4, args=0x7fffffff7260) at eval.c:2657
#13 0x000000000063c36f in exec_byte_code (bytestr=15687156, vector=19894717, maxdepth=38,
    args_template=3078, nargs=2, args=0x7fffffff77b0) at bytecode.c:880
#14 0x00000000005f8c5a in funcall_lambda (fun=19894813, nargs=2, arg_vector=0x7fffffff77a0)
    at eval.c:2810
#15 0x00000000005f86fe in Ffuncall (nargs=3, args=0x7fffffff7798) at eval.c:2699
#16 0x000000000063c36f in exec_byte_code (bytestr=25001908, vector=19401317, maxdepth=30,
    args_template=2, nargs=0, args=0x7fffffff7d20) at bytecode.c:880
#17 0x00000000005f8c5a in funcall_lambda (fun=19401453, nargs=0, arg_vector=0x7fffffff7d20)
    at eval.c:2810
#18 0x00000000005f86fe in Ffuncall (nargs=1, args=0x7fffffff7d18) at eval.c:2699
---Type <return> to continue, or q <return> to quit---
#19 0x000000000063c36f in exec_byte_code (bytestr=24983892, vector=19421605, maxdepth=62,
    args_template=2, nargs=0, args=0x7fffffff8260) at bytecode.c:880
#20 0x00000000005f8c5a in funcall_lambda (fun=19426061, nargs=0, arg_vector=0x7fffffff8260)
    at eval.c:2810
#21 0x00000000005f86fe in Ffuncall (nargs=1, args=0x7fffffff8258) at eval.c:2699
#22 0x000000000063c36f in exec_byte_code (bytestr=24976404, vector=19433941, maxdepth=54,
    args_template=2, nargs=0, args=0x7fffffff87e0) at bytecode.c:880
#23 0x00000000005f8c5a in funcall_lambda (fun=19438389, nargs=0, arg_vector=0x7fffffff87e0)
    at eval.c:2810
#24 0x00000000005f86fe in Ffuncall (nargs=1, args=0x7fffffff87d8) at eval.c:2699
#25 0x000000000063c36f in exec_byte_code (bytestr=9952172, vector=9952205, maxdepth=22,
    args_template=2054, nargs=2, args=0x7fffffff8d50) at bytecode.c:880
#26 0x00000000005f8c5a in funcall_lambda (fun=9952125, nargs=2, arg_vector=0x7fffffff8d40)
    at eval.c:2810
#27 0x00000000005f86fe in Ffuncall (nargs=3, args=0x7fffffff8d38) at eval.c:2699
#28 0x000000000063c36f in exec_byte_code (bytestr=9951132, vector=9951165, maxdepth=50,
    args_template=1026, nargs=0, args=0x7fffffff9278) at bytecode.c:880
#29 0x00000000005f8c5a in funcall_lambda (fun=9951085, nargs=0, arg_vector=0x7fffffff9278)
    at eval.c:2810
#30 0x00000000005f86fe in Ffuncall (nargs=1, args=0x7fffffff9270) at eval.c:2699
#31 0x000000000063c36f in exec_byte_code (bytestr=9941012, vector=9941045, maxdepth=26,
    args_template=1026, nargs=1, args=0x7fffffff97e0) at bytecode.c:880
#32 0x00000000005f8c5a in funcall_lambda (fun=9940957, nargs=1, arg_vector=0x7fffffff97d8)
    at eval.c:2810
#33 0x00000000005f86fe in Ffuncall (nargs=2, args=0x7fffffff97d0) at eval.c:2699
---Type <return> to continue, or q <return> to quit---
#34 0x000000000063c36f in exec_byte_code (bytestr=9939900, vector=9939933, maxdepth=42,
    args_template=5122, nargs=2, args=0x7fffffff9d58) at bytecode.c:880
#35 0x00000000005f8c5a in funcall_lambda (fun=9939853, nargs=2, arg_vector=0x7fffffff9d48)
    at eval.c:2810
#36 0x00000000005f86fe in Ffuncall (nargs=3, args=0x7fffffff9d40) at eval.c:2699
#37 0x000000000063c36f in exec_byte_code (bytestr=9938100, vector=9938133, maxdepth=46,
    args_template=6170, nargs=6, args=0x7fffffffa2e8) at bytecode.c:880
#38 0x00000000005f8c5a in funcall_lambda (fun=9938053, nargs=6, arg_vector=0x7fffffffa2b8)
    at eval.c:2810
#39 0x00000000005f86fe in Ffuncall (nargs=7, args=0x7fffffffa2b0) at eval.c:2699
#40 0x000000000063c36f in exec_byte_code (bytestr=9936740, vector=9936773, maxdepth=70,
    args_template=4102, nargs=4, args=0x7fffffffa830) at bytecode.c:880
#41 0x00000000005f8c5a in funcall_lambda (fun=9936693, nargs=4, arg_vector=0x7fffffffa810)
    at eval.c:2810
#42 0x00000000005f86fe in Ffuncall (nargs=5, args=0x7fffffffa808) at eval.c:2699
#43 0x000000000063c36f in exec_byte_code (bytestr=9930092, vector=9930125, maxdepth=30,
    args_template=2054, nargs=2, args=0x7fffffffae40) at bytecode.c:880
#44 0x00000000005f8c5a in funcall_lambda (fun=9930037, nargs=2, arg_vector=0x7fffffffae30)
    at eval.c:2810
#45 0x00000000005f86fe in Ffuncall (nargs=3, args=0x7fffffffae28) at eval.c:2699
#46 0x00000000005f0519 in Ffuncall_interactively (nargs=3, args=0x7fffffffae28) at callint.c:248
#47 0x00000000005f835c in Ffuncall (nargs=4, args=0x7fffffffae20) at eval.c:2630
#48 0x00000000005f78eb in Fapply (nargs=3, args=0x7fffffffaf20) at eval.c:2278
#49 0x00000000005f098d in Fcall_interactively (function=3837888, record_flag=0, keys=13407221)
    at callint.c:385
---Type <return> to continue, or q <return> to quit---
#50 0x00000000005f84c5 in Ffuncall (nargs=4, args=0x7fffffffb1b8) at eval.c:2657
#51 0x000000000063c36f in exec_byte_code (bytestr=10416348, vector=10416381, maxdepth=54,
    args_template=4102, nargs=1, args=0x7fffffffb710) at bytecode.c:880
#52 0x00000000005f8c5a in funcall_lambda (fun=10416301, nargs=1, arg_vector=0x7fffffffb708)
    at eval.c:2810
#53 0x00000000005f86fe in Ffuncall (nargs=2, args=0x7fffffffb700) at eval.c:2699
#54 0x00000000005f7e8d in call1 (fn=14736, arg1=3837888) at eval.c:2509
#55 0x000000000055a8d3 in command_loop_1 () at keyboard.c:1458
#56 0x00000000005f518e in internal_condition_case (bfun=0x55a103 <command_loop_1>, handlers=18912,
    hfun=0x559900 <cmd_error>) at eval.c:1309
#57 0x0000000000559e0b in command_loop_2 (ignore=0) at keyboard.c:1086
#58 0x00000000005f4987 in internal_catch (tag=45552, func=0x559de2 <command_loop_2>, arg=0)
    at eval.c:1073
#59 0x0000000000559db4 in command_loop () at keyboard.c:1065
#60 0x00000000005594d5 in recursive_edit_1 () at keyboard.c:671
#61 0x0000000000559662 in Frecursive_edit () at keyboard.c:742
#62 0x0000000000557675 in main (argc=2, argv=0x7fffffffbbe8) at emacs.c:1644

Lisp Backtrace:
"image-size" (0xffff7268)
"image-display-size" (0xffff77a0)
"image-transform-check-size" (0xffff7d20)
"image-toggle-display-image" (0xffff8260)
"image-mode" (0xffff87e0)
"set-auto-mode-0" (0xffff8d40)
"set-auto-mode" (0xffff9278)
"normal-mode" (0xffff97d8)
"after-find-file" (0xffff9d48)
"find-file-noselect-1" (0xffffa2b8)
"find-file-noselect" (0xffffa810)
"find-file" (0xffffae30)
"funcall-interactively" (0xffffae28)
"call-interactively" (0xffffb1c0)
"command-execute" (0xffffb708)
(gdb)

bug#21738: 25.0.50; eww freezes/crashes at times

[Eli Zaretskii]

> From: Kaushal Modi <kaushal.modi@gmail.com>
> Date: Fri, 23 Oct 2015 15:01:12 -0400
> Cc: Eli Zaretskii <eliz@gnu.org>, 21738@debbugs.gnu.org
> 
> I updated to the latest Imagemagick (v 6.9.2-4) and "r -Q" emacs
> session still freezes in gdb when I evaluate
> 
> (eww "http://www.braveclojure.com/basic-emacs")
> 
> This time though, I got a much longer backtrace (attached) but the
> main error is still similar (that number following UnregisterTIFFImage
> changed):
> 
> > emacs: Memory allocation failed `No such file or directory' @ fatal/tiff.c/UnregisterTIFFImage/2379.

What does this display:

 (gdb) frame 63
 (gdb) pp error_symbol
 (gdb) pp data

bug#21738: 25.0.50; eww freezes/crashes at times

[Kaushal Modi]

I got the below after recreating the freeze, followed by C-z in the
terminal running gdb:

(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 0x7fffedb6f700 (LWP 18101)]

(emacs:18093): GLib-GIO-CRITICAL **: g_settings_schema_source_lookup:
assertion 'source != NULL' failed

[New Thread 0x7fffe6574700 (LWP 18303)]
emacs: Memory allocation failed `No such file or directory' @
fatal/tiff.c/UnregisterTIFFImage/2379.
^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
libgcc-4.4.7-11.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) frame 63
#63 0x000000000063c36f in exec_byte_code (bytestr=26620996,
vector=27212957, maxdepth=34,
    args_template=0, nargs=0, args=0x0) at bytecode.c:880
880                 TOP = Ffuncall (op + 1, &TOP);

(gdb) pp error_symbol
No symbol "error_symbol" in current context.

(gdb) pp data
nil


Is that "Missing separate debuginfos" line useful? I can skip pasting in future.

bug#21738: 25.0.50; eww freezes/crashes at times

[Kaushal Modi]

I wonder if that info in last email was of any use.. because I had
already exited the gdb session for which I had sent the log files.

What criteria did you pick to get frame 63? Does that number change
with each gdb run?

bug#21738: 25.0.50; eww freezes/crashes at times

[Eli Zaretskii]

> From: Kaushal Modi <kaushal.modi@gmail.com>
> Date: Fri, 23 Oct 2015 15:23:37 -0400
> Cc: Glenn Morris <rgm@gnu.org>, 21738@debbugs.gnu.org
> 
> I got the below after recreating the freeze, followed by C-z in the
> terminal running gdb:
> 
> (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 0x7fffedb6f700 (LWP 18101)]
> 
> (emacs:18093): GLib-GIO-CRITICAL **: g_settings_schema_source_lookup:
> assertion 'source != NULL' failed
> 
> [New Thread 0x7fffe6574700 (LWP 18303)]
> emacs: Memory allocation failed `No such file or directory' @
> fatal/tiff.c/UnregisterTIFFImage/2379.
> ^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
> libgcc-4.4.7-11.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) frame 63
> #63 0x000000000063c36f in exec_byte_code (bytestr=26620996,
> vector=27212957, maxdepth=34,
>     args_template=0, nargs=0, args=0x0) at bytecode.c:880
> 880                 TOP = Ffuncall (op + 1, &TOP);
> 
> (gdb) pp error_symbol
> No symbol "error_symbol" in current context.
> 
> (gdb) pp data
> nil

You never told you didn't keep the session in GDB.  Each new backtrace
is different, so the commands won't work in another session.

bug#21738: 25.0.50; eww freezes/crashes at times

[Kaushal Modi]

> You never told you didn't keep the session in GDB.  Each new backtrace
> is different, so the commands won't work in another session.

Sorry. I didn't know that earlier.

Also I don't know how to kill an emacs session frozen in gdb other
than doing Ctrl-d in gdb.

I needed to kill that eww-frozen emacs to provide another gdb bt for
freeze caused by opening png files.

I will now keep the frozen gdb session active.. which frame is
important for you to debug this?  I saw that #63 in the first attached
log had Fsignal (is that what you are looking for?)
> #63 0x00000000005f593e in Fsignal (error_symbol=48816, data=29334659) at eval.c:1506

I tried couple of times after that.. but those backtraces did not have
that Fsignal line.

/I used gdb for the first time yesterday.. and was excited to get that
backtrace. There's a lot to learn for me :)/

bug#21738: 25.0.50; eww freezes/crashes at times

[Kaushal Modi]

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

Here's another bt log (attached). I will not be exiting this gdb
session now. Please let me know what more info I can provide.

[-- Attachment #2: emacs_25_Imagemagick_eww_freeze_gdb_bt2.log --]
[-- Type: application/octet-stream, Size: 12354 bytes --]

(gdb) r -Q
Starting program: /home/kmodi/downloads/git/emacs_gdb/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 0x7fffedb6f700 (LWP 11241)]

(emacs:11233): GLib-GIO-CRITICAL **: g_settings_schema_source_lookup: assertion 'source != NULL' failed
[New Thread 0x7fffe6574700 (LWP 11272)]
emacs: Memory allocation failed `No such file or directory' @ fatal/tiff.c/UnregisterTIFFImage/2379.
^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 libgcc-4.4.7-11.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  0x00007ffff607b388 in LockMagickMutex () at ./magick/semaphore-private.h:63
#2  MagickCoreTerminus () at magick/magick.c:1368
#3  0x00007ffff603c559 in DefaultFatalErrorHandler (severity=FatalErrorException, reason=<value optimized out>, description=0x0) at magick/exception.c:335
#4  0x00007ffff603cb00 in CatchException (exception=0x1a70310) at magick/exception.c:211
#5  0x00007ffff62223da in UnregisterTIFFImage () at coders/tiff.c:2379
#6  0x00007ffff60ea975 in UnregisterStaticModules () at magick/static.c:485
#7  0x00007ffff607b3ca in MagickCoreTerminus () at magick/magick.c:1389
#8  0x0000000000692ad5 in imagemagick_load_image (f=0x12aa870, img=0x1a01b10, contents=0x1aeace8 "\211PNG\r\n\032\n", size=46447, filename=0x0) at image.c:8797
#9  0x0000000000692ca8 in imagemagick_load (f=0x12aa870, img=0x1a01b10) at image.c:8850
#10 0x0000000000688492 in lookup_image (f=0x12aa870, spec=27717491) at image.c:1751
#11 0x0000000000686ce3 in Fimage_metadata (spec=27717491, frame=0) at image.c:929
#12 0x00000000005f8487 in Ffuncall (nargs=2, args=0x7fffffff35f8) at eval.c:2653
#13 0x000000000063c36f in exec_byte_code (bytestr=11206412, vector=11206445, maxdepth=14, args_template=0, nargs=0, args=0x0) at bytecode.c:880
#14 0x00000000005f8f8b in funcall_lambda (fun=11206349, nargs=1, arg_vector=0xaaff2d) at eval.c:2876
#15 0x00000000005f86fe in Ffuncall (nargs=2, args=0x7fffffff3b18) at eval.c:2699
#16 0x000000000063c36f in exec_byte_code (bytestr=25249764, vector=19873925, maxdepth=38, args_template=0, nargs=0, args=0x0) at bytecode.c:880
#17 0x00000000005f8f8b in funcall_lambda (fun=19870133, nargs=2, arg_vector=0x12f4085) at eval.c:2876
#18 0x00000000005f86fe in Ffuncall (nargs=3, args=0x7fffffff4068) at eval.c:2699
#19 0x000000000063c36f in exec_byte_code (bytestr=16492036, vector=19890373, maxdepth=38, args_template=0, nargs=0, args=0x0) at bytecode.c:880
#20 0x00000000005f8f8b in funcall_lambda (fun=19660405, nargs=1, arg_vector=0x12f80c5) at eval.c:2876
#21 0x00000000005f86fe in Ffuncall (nargs=2, args=0x7fffffff45b8) at eval.c:2699
#22 0x000000000063c36f in exec_byte_code (bytestr=25090356, vector=19331141, maxdepth=30, args_template=0, nargs=0, args=0x0) at bytecode.c:880
#23 0x00000000005f8f8b in funcall_lambda (fun=19281981, nargs=1, arg_vector=0x126f845) at eval.c:2876
#24 0x00000000005f86fe in Ffuncall (nargs=2, args=0x7fffffff4af8) at eval.c:2699
#25 0x000000000063c36f in exec_byte_code (bytestr=24836836, vector=19870229, maxdepth=14, args_template=0, nargs=0, args=0x0) at bytecode.c:880
#26 0x00000000005f8f8b in funcall_lambda (fun=23939301, nargs=1, arg_vector=0x12f3215) at eval.c:2876
#27 0x00000000005f86fe in Ffuncall (nargs=2, args=0x7fffffff5018) at eval.c:2699
#28 0x000000000063c36f in exec_byte_code (bytestr=25090356, vector=19331141, maxdepth=30, args_template=0, nargs=0, args=0x0) at bytecode.c:880
#29 0x00000000005f8f8b in funcall_lambda (fun=19281981, nargs=1, arg_vector=0x126f845) at eval.c:2876
#30 0x00000000005f86fe in Ffuncall (nargs=2, args=0x7fffffff5558) at eval.c:2699
#31 0x000000000063c36f in exec_byte_code (bytestr=24836836, vector=19870229, maxdepth=14, args_template=0, nargs=0, args=0x0) at bytecode.c:880
#32 0x00000000005f8f8b in funcall_lambda (fun=23939301, nargs=1, arg_vector=0x12f3215) at eval.c:2876
#33 0x00000000005f86fe in Ffuncall (nargs=2, args=0x7fffffff5a78) at eval.c:2699
#34 0x000000000063c36f in exec_byte_code (bytestr=25090356, vector=19331141, maxdepth=30, args_template=0, nargs=0, args=0x0) at bytecode.c:880
#35 0x00000000005f8f8b in funcall_lambda (fun=19281981, nargs=1, arg_vector=0x126f845) at eval.c:2876
#36 0x00000000005f86fe in Ffuncall (nargs=2, args=0x7fffffff5fb8) at eval.c:2699
#37 0x000000000063c36f in exec_byte_code (bytestr=25267540, vector=19886461, maxdepth=26, args_template=0, nargs=0, args=0x0) at bytecode.c:880
#38 0x00000000005f8f8b in funcall_lambda (fun=20030525, nargs=1, arg_vector=0x12f717d) at eval.c:2876
#39 0x00000000005f86fe in Ffuncall (nargs=2, args=0x7fffffff64f8) at eval.c:2699
#40 0x000000000063c36f in exec_byte_code (bytestr=25090356, vector=19331141, maxdepth=30, args_template=0, nargs=0, args=0x0) at bytecode.c:880
#41 0x00000000005f8f8b in funcall_lambda (fun=19281981, nargs=1, arg_vector=0x126f845) at eval.c:2876
#42 0x00000000005f86fe in Ffuncall (nargs=2, args=0x7fffffff6a38) at eval.c:2699
#43 0x000000000063c36f in exec_byte_code (bytestr=25090356, vector=19331141, maxdepth=30, args_template=0, nargs=0, args=0x0) at bytecode.c:880
#44 0x00000000005f8f8b in funcall_lambda (fun=19281981, nargs=1, arg_vector=0x126f845) at eval.c:2876
#45 0x00000000005f86fe in Ffuncall (nargs=2, args=0x7fffffff6f78) at eval.c:2699
#46 0x000000000063c36f in exec_byte_code (bytestr=23580228, vector=19376725, maxdepth=14, args_template=0, nargs=0, args=0x0) at bytecode.c:880
#47 0x00000000005f8f8b in funcall_lambda (fun=21899893, nargs=1, arg_vector=0x127aa55) at eval.c:2876
#48 0x00000000005f86fe in Ffuncall (nargs=2, args=0x7fffffff7498) at eval.c:2699
#49 0x000000000063c36f in exec_byte_code (bytestr=25090356, vector=19331141, maxdepth=30, args_template=0, nargs=0, args=0x0) at bytecode.c:880
#50 0x00000000005f8f8b in funcall_lambda (fun=19281981, nargs=1, arg_vector=0x126f845) at eval.c:2876
#51 0x00000000005f86fe in Ffuncall (nargs=2, args=0x7fffffff79d8) at eval.c:2699
---Type <return> to continue, or q <return> to quit---
#52 0x000000000063c36f in exec_byte_code (bytestr=25073524, vector=21099085, maxdepth=62, args_template=0, nargs=0, args=0x0) at bytecode.c:880
#53 0x00000000005f8f8b in funcall_lambda (fun=19833077, nargs=1, arg_vector=0x141f24d) at eval.c:2876
#54 0x00000000005f86fe in Ffuncall (nargs=2, args=0x7fffffff7f98) at eval.c:2699
#55 0x000000000063c36f in exec_byte_code (bytestr=23377156, vector=26783805, maxdepth=62, args_template=6154, nargs=6, args=0x7fffffff8558) at bytecode.c:880
#56 0x00000000005f8c5a in funcall_lambda (fun=26784109, nargs=6, arg_vector=0x7fffffff8528) at eval.c:2810
#57 0x00000000005f86fe in Ffuncall (nargs=7, args=0x7fffffff8520) at eval.c:2699
#58 0x000000000063c36f in exec_byte_code (bytestr=23953108, vector=26783213, maxdepth=66, args_template=5130, nargs=4, args=0x7fffffff8a88) at bytecode.c:880
#59 0x00000000005f8c5a in funcall_lambda (fun=26783533, nargs=4, arg_vector=0x7fffffff8a68) at eval.c:2810
#60 0x00000000005f86fe in Ffuncall (nargs=5, args=0x7fffffff8a60) at eval.c:2699
#61 0x00000000005f78eb in Fapply (nargs=2, args=0x7fffffff8bf0) at eval.c:2278
#62 0x00000000005f835c in Ffuncall (nargs=3, args=0x7fffffff8be8) at eval.c:2630
#63 0x000000000063c36f in exec_byte_code (bytestr=27303796, vector=27312221, maxdepth=34, args_template=0, nargs=0, args=0x0) at bytecode.c:880
#64 0x00000000005f8f8b in funcall_lambda (fun=27312469, nargs=0, arg_vector=0x1a0c05d) at eval.c:2876
#65 0x00000000005f86fe in Ffuncall (nargs=1, args=0x7fffffff9138) at eval.c:2699
#66 0x000000000063c36f in exec_byte_code (bytestr=27319892, vector=27313253, maxdepth=58, args_template=0, nargs=0, args=0x0) at bytecode.c:880
#67 0x00000000005f8f8b in funcall_lambda (fun=27313725, nargs=3, arg_vector=0x1a0c465) at eval.c:2876
#68 0x00000000005f86fe in Ffuncall (nargs=4, args=0x7fffffff96b8) at eval.c:2699
#69 0x000000000063c36f in exec_byte_code (bytestr=27337716, vector=27315333, maxdepth=18, args_template=0, nargs=0, args=0x0) at bytecode.c:880
#70 0x00000000005f8f8b in funcall_lambda (fun=27315477, nargs=2, arg_vector=0x1a0cc85) at eval.c:2876
#71 0x00000000005f86fe in Ffuncall (nargs=3, args=0x7fffffff9be0) at eval.c:2699
#72 0x00000000005f78eb in Fapply (nargs=2, args=0x7fffffff9ca0) at eval.c:2278
#73 0x00000000005f7e3b in apply1 (fn=14221712, arg=26872579) at eval.c:2494
#74 0x000000000064b80b in read_process_output_call (fun_and_args=26872499) at process.c:5237
#75 0x00000000005f52f3 in internal_condition_case_1 (bfun=0x64b7dd <read_process_output_call>, arg=26872499, handlers=18912, hfun=0x64b80d <read_process_output_error_handler>) at eval.c:1333
#76 0x000000000064bfa0 in read_and_dispose_of_process_output (p=0x1a38740,
    chars=0x7fffffff9dc0 "\277\315\367\214k\362\375NC\376\222\371\022A\b\244\210\063\374|\366\222\254\004\362\223\315\311\307\317\321\313\304\b.ۮ\224\034\003\016\374\f4=@\264ص\016\307o.\177\276W\351N\277\375\364vm\b\276\023j_W\037\270\035&\273\276>\003;Lv\231\212\025;\f\267\232\b\270\016\027\326s\217\035\254Z\273ܩ\025!\270\271\222v\246\033rO\351F\330\313\324\005pP\370\217\377#6\364\350\270\371\373\375\201D\020\367\244}\372\200\214\245\217A\200\217IF|\311\335l\303\066\267\274\060\366z\205㣩7\034?\316{\234\352\b#\177\236c\311\006\370\033\225*#\257\235\024\252\204K\002\330]\352\210\314\322\336\340\276o\315\333qS"...,
    nbytes=1187, coding=0x1a3e270) at process.c:5445
#77 0x000000000064bbf5 in read_process_output (proc=27494213, channel=21) at process.c:5356
#78 0x000000000064b177 in wait_reading_process_output (time_limit=30, nsecs=0, read_kbd=-1, do_display=true, wait_for_cell=0, wait_proc=0x0, just_wait_proc=0) at process.c:5063
#79 0x00000000004240ef in sit_for (timeout=122, reading=true, display_option=1) at dispnew.c:5751
#80 0x000000000055d7e0 in read_char (commandflag=1, map=26873939, prev_event=0, used_mouse_menu=0x7fffffffb64f, end_time=0x0) at keyboard.c:2700
#81 0x000000000056a83b in read_key_sequence (keybuf=0x7fffffffb810, bufsize=30, prompt=0, dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false)
    at keyboard.c:9028
#82 0x000000000055a511 in command_loop_1 () at keyboard.c:1346
#83 0x00000000005f518e in internal_condition_case (bfun=0x55a103 <command_loop_1>, handlers=18912, hfun=0x559900 <cmd_error>) at eval.c:1309
#84 0x0000000000559e0b in command_loop_2 (ignore=0) at keyboard.c:1086
#85 0x00000000005f4987 in internal_catch (tag=45552, func=0x559de2 <command_loop_2>, arg=0) at eval.c:1073
#86 0x0000000000559db4 in command_loop () at keyboard.c:1065
#87 0x00000000005594d5 in recursive_edit_1 () at keyboard.c:671
#88 0x0000000000559662 in Frecursive_edit () at keyboard.c:742
#89 0x0000000000557675 in main (argc=2, argv=0x7fffffffbcc8) at emacs.c:1644
(gdb)

bug#21738: 25.0.50; eww freezes/crashes at times

[Eli Zaretskii]

> From: Kaushal Modi <kaushal.modi@gmail.com>
> Date: Fri, 23 Oct 2015 15:52:59 -0400
> Cc: Glenn Morris <rgm@gnu.org>, 21738@debbugs.gnu.org
> 
> Also I don't know how to kill an emacs session frozen in gdb other
> than doing Ctrl-d in gdb.

You can type "kill" at the GDB prompt.

> I will now keep the frozen gdb session active.. which frame is
> important for you to debug this?  I saw that #63 in the first attached
> log had Fsignal (is that what you are looking for?)
> > #63 0x00000000005f593e in Fsignal (error_symbol=48816, data=29334659) at eval.c:1506
> 
> I tried couple of times after that.. but those backtraces did not have
> that Fsignal line.

I guess it's unrelated to the problem.

The file etc/DEBUG has a section that explains how to find where Emacs
is inflooping.  Can you try that technique and report the results?

bug#21738: 25.0.50; eww freezes/crashes at times

[Kaushal Modi]

> You can type "kill" at the GDB prompt.

Thanks!

> The file etc/DEBUG has a section that explains how to find where Emacs
> is inflooping.  Can you try that technique and report the results?

Alright. I will work on that next week and post here when I get results.

By the way, I am now using emacs built without imagemagick. Now emacs
does not freeze in "emacs -Q" sessions.
But I got it to freeze (in a C-g quittable way) in my emacs using my config.

fci (fill column indicator mode is the culplrit!) -
http://www.emacswiki.org/emacs/fill-column-indicator.el

The bug is nasty.. probably in the package or my config (need to yet
figure that out).
If I have only the window with eww buffer in the whole frame then
everything is fine.
But (1) if I have two windows (or more) in a frame and
      (2) if one of the windows has a buffer with a major mode where I
have fci-mode enabled, and
     (3) I am loading eww in the other buffer, my eww freezes, luckily
doing C-g exits that state.

I took your advice and did

(setq debug-on-quit t)

On doing C-g, I get the below.

The bug, I mentioned, is nasty, because I don't enable fci-mode
globally; only in few prog modes, and definitely not in eww-mode. But
some sort of window walking is freezing emacs when probably fci tried
to do something in the eww buffer window. If I don't load the fci
package at all, eww loads http://www.braveclojure.com/basic-emacs fine
in my emacs with my config too! :)


Debugger entered--Lisp error: (quit)
  window-end(#<window 3 on *Backtrace*> updated)
  #[(w) "\301 !\302 \303\"B\207" [w window-start window-end updated]
4](#<window 3 on *Backtrace*>)
  mapcar(#[(w) "\301 !\302 \303\"B\207" [w window-start window-end
updated] 4] (#<window 3 on *Backtrace*>))
  fci-delete-unneeded()
  fci-redraw-frame()
  set-window-buffer(nil #<buffer  *temp*-559543>)
  shr-render-td-1((td ((class . "Body") (shr-td-cache-natural . 214)
(shr-td-cache-10-nil 209 214 1 (#("M->" 0 1 (face (variable-pitch
bold) shr-indentation nil) 1 3 (face (variable-pitch bold)))) 1 nil
nil)) "\n      " (strong nil "M->") "\n    ") 213 t)
  shr-render-td((td ((class . "Body") (shr-td-cache-natural . 214)
(shr-td-cache-10-nil 209 214 1 (#("M->" 0 1 (face (variable-pitch
bold) shr-indentation nil) 1 3 (face (variable-pitch bold)))) 1 nil
nil)) "\n      " (strong nil "M->") "\n    ") 213 t)


So, inspite of not yet finding a clean solution, I at least got that
web page loading in my regular emacs setup.

- no imagemagick
- no fci-mode

bug#21738: 25.0.50; eww freezes/crashes at times

[Eli Zaretskii]

> From: Kaushal Modi <kaushal.modi@gmail.com>
> Date: Fri, 23 Oct 2015 16:35:47 -0400
> Cc: Glenn Morris <rgm@gnu.org>, 21738@debbugs.gnu.org
> 
> By the way, I am now using emacs built without imagemagick. Now emacs
> does not freeze in "emacs -Q" sessions.
> But I got it to freeze (in a C-g quittable way) in my emacs using my config.
> 
> fci (fill column indicator mode is the culplrit!) -
> http://www.emacswiki.org/emacs/fill-column-indicator.el
> 
> The bug is nasty.. probably in the package or my config (need to yet
> figure that out).
> If I have only the window with eww buffer in the whole frame then
> everything is fine.
> But (1) if I have two windows (or more) in a frame and
>       (2) if one of the windows has a buffer with a major mode where I
> have fci-mode enabled, and
>      (3) I am loading eww in the other buffer, my eww freezes, luckily
> doing C-g exits that state.

This could be another manifestation of bug#21745, so please update
from master and try again.

bug#21738: 25.0.50; eww freezes/crashes at times

[Kaushal Modi]

> The bug is nasty.. probably in the package or my config (need to yet
> figure that out).

I am pretty sure, it is this piece of code in fill-column-indicator.el!

;; Hooks we use.
(defconst fci-hook-assignments
  '((after-change-functions fci-redraw-region t t)
    (before-change-functions fci-extend-rule-for-deletion nil t)
    (window-scroll-functions fci-update-window-for-scroll nil t)
    (window-configuration-change-hook  fci-redraw-frame)   ;
<--------------------------------------------------------------
    (post-command-hook  fci-post-command-check nil t)
    (change-major-mode-hook turn-off-fci-mode nil t)
    (longlines-mode-hook fci-update-all-windows nil t)))

But the definition of fci-redraw-frame has "(when fci-mode" too

(defun fci-redraw-frame ()
  "Redraw the fill-column rule in all windows on the selected frame."
  (let* ((wins (window-list (selected-frame) 'no-minibuf))
         (bufs (delete-dups (mapcar #'window-buffer wins))))
    (dolist (buf bufs)
      (with-current-buffer buf
        (when fci-mode
          (fci-delete-unneeded)
          (fci-update-all-windows))))))

So I am at loss why it is freezing eww if one of the other windows has
fci enabled. I checked that "C-h v fci-mode" returns nil in the eww
buffer.

bug#21738: 25.0.50; eww freezes/crashes at times

[Kaushal Modi]

I updated and rebuilt (without imagemagick).
I still get the same problem if I load eww in a 2-window frame, with fci loaded.
eww loads that webpage fine after I do C-x 1.

Backtrace after C-g and debug-on-quit set to t:

window-end(#<window 3 on *Backtrace*> updated)
  #[(w) "\301 !\302 \303\"B\207" [w window-start window-end updated]
4](#<window 3 on *Backtrace*>)
  mapcar(#[(w) "\301 !\302 \303\"B\207" [w window-start window-end
updated] 4] (#<window 3 on *Backtrace*>))
  fci-delete-unneeded()
  fci-redraw-frame()
  set-window-buffer(nil #<buffer  *temp*-411462>)
  shr-render-td-1((td ((class . "Body") (shr-td-cache-natural . 222)
(shr-td-cache-10-nil 217 222 1 (#("Yank." 0 1 (face variable-pitch
shr-indentation nil) 1 5 (face variable-pitch))) 1 nil nil)) "\n
Yank.\n    ") 268 t)
  shr-render-td((td ((class . "Body") (shr-td-cache-natural . 222)
(shr-td-cache-10-nil 217 222 1 (#("Yank." 0 1 (face variable-pitch
shr-indentation nil) 1 5 (face variable-pitch))) 1 nil nil)) "\n
Yank.\n    ") 268 t)




--
Kaushal Modi


On Fri, Oct 23, 2015 at 4:43 PM, Kaushal Modi <kaushal.modi@gmail.com> wrote:
>> The bug is nasty.. probably in the package or my config (need to yet
>> figure that out).
>
> I am pretty sure, it is this piece of code in fill-column-indicator.el!
>
> ;; Hooks we use.
> (defconst fci-hook-assignments
>   '((after-change-functions fci-redraw-region t t)
>     (before-change-functions fci-extend-rule-for-deletion nil t)
>     (window-scroll-functions fci-update-window-for-scroll nil t)
>     (window-configuration-change-hook  fci-redraw-frame)   ;
> <--------------------------------------------------------------
>     (post-command-hook  fci-post-command-check nil t)
>     (change-major-mode-hook turn-off-fci-mode nil t)
>     (longlines-mode-hook fci-update-all-windows nil t)))
>
> But the definition of fci-redraw-frame has "(when fci-mode" too
>
> (defun fci-redraw-frame ()
>   "Redraw the fill-column rule in all windows on the selected frame."
>   (let* ((wins (window-list (selected-frame) 'no-minibuf))
>          (bufs (delete-dups (mapcar #'window-buffer wins))))
>     (dolist (buf bufs)
>       (with-current-buffer buf
>         (when fci-mode
>           (fci-delete-unneeded)
>           (fci-update-all-windows))))))
>
> So I am at loss why it is freezing eww if one of the other windows has
> fci enabled. I checked that "C-h v fci-mode" returns nil in the eww
> buffer.

bug#21738: 25.0.50; eww freezes/crashes at times

[Kaushal Modi]

I put some debug statements in the fci-redraw-frame () function in
fill-column-indicator:

(defun fci-redraw-frame ()
  "Redraw the fill-column rule in all windows on the selected frame."
  (let* ((wins (window-list (selected-frame) 'no-minibuf))
         (bufs (delete-dups (mapcar #'window-buffer wins))))
    (message "Buffer list: %s" bufs)
    (dolist (buf bufs)
      (with-current-buffer buf
        (when fci-mode
          (message "In buffer %s" buf)
          (fci-delete-unneeded)
          (fci-update-all-windows))))))

After that,
(1) I had the frame with 2 windows.
(2) I had fill-column-indicator.el in one window, and
(3) did M-: (eww "http://www.braveclojure.com/basic-emacs") with point
in the other window.

Emacs of course went into infloop but I was able to get out of it with
C-g, and saw these messages in *Messages* buffer:

Buffer list: (*eww* fill-column-indicator.el)
In buffer fill-column-indicator.el
Contacting host: www.braveclojure.com:80
#<buffer  *http www.braveclojure.com:80*>
Buffer list: ( *temp* fill-column-indicator.el)
In buffer fill-column-indicator.el
Buffer list: (eww fill-column-indicator.el)
In buffer fill-column-indicator.el
Buffer list: ( *temp* fill-column-indicator.el)
In buffer fill-column-indicator.el
Buffer list: (eww fill-column-indicator.el)
In buffer fill-column-indicator.el
Buffer list: ( *temp* fill-column-indicator.el)
In buffer fill-column-indicator.el
Buffer list: (eww fill-column-indicator.el)
In buffer fill-column-indicator.el
Buffer list: ( *temp* fill-column-indicator.el)
In buffer fill-column-indicator.el
Buffer list: (eww fill-column-indicator.el)
In buffer fill-column-indicator.el
Buffer list: ( *temp* fill-column-indicator.el)
In buffer fill-column-indicator.el
Buffer list: (eww fill-column-indicator.el)
In buffer fill-column-indicator.el
Buffer list: ( *temp* fill-column-indicator.el)
In buffer fill-column-indicator.el
Buffer list: (eww fill-column-indicator.el)
In buffer fill-column-indicator.el
Buffer list: ( *temp* fill-column-indicator.el)
In buffer fill-column-indicator.el
Buffer list: (eww fill-column-indicator.el)
In buffer fill-column-indicator.el
Buffer list: ( *temp* fill-column-indicator.el)
In buffer fill-column-indicator.el
Buffer list: (eww fill-column-indicator.el)
In buffer fill-column-indicator.el
Buffer list: ( *temp* fill-column-indicator.el)
In buffer fill-column-indicator.el
Buffer list: (eww fill-column-indicator.el)
In buffer fill-column-indicator.el
Buffer list: ( *temp* fill-column-indicator.el)
In buffer fill-column-indicator.el
Buffer list: (eww fill-column-indicator.el)
In buffer fill-column-indicator.el
Buffer list: ( *temp* fill-column-indicator.el)
In buffer fill-column-indicator.el
Buffer list: (eww fill-column-indicator.el)
In buffer fill-column-indicator.el
Buffer list: ( *temp* fill-column-indicator.el)
In buffer fill-column-indicator.el
Buffer list: (eww fill-column-indicator.el)
In buffer fill-column-indicator.el
Buffer list: ( *temp* fill-column-indicator.el)
In buffer fill-column-indicator.el
Buffer list: (eww fill-column-indicator.el)
In buffer fill-column-indicator.el
Buffer list: ( *temp* fill-column-indicator.el)
In buffer fill-column-indicator.el
Buffer list: (eww fill-column-indicator.el)
In buffer fill-column-indicator.el
Buffer list: ( *temp* fill-column-indicator.el)
In buffer fill-column-indicator.el
Buffer list: (eww fill-column-indicator.el)
In buffer fill-column-indicator.el
Buffer list: ( *temp* fill-column-indicator.el)
In buffer fill-column-indicator.el
Buffer list: (eww fill-column-indicator.el)
In buffer fill-column-indicator.el
Buffer list: ( *temp* fill-column-indicator.el)
In buffer fill-column-indicator.el
Buffer list: (eww fill-column-indicator.el)
In buffer fill-column-indicator.el
Buffer list: ( *temp*-713219 fill-column-indicator.el)
In buffer fill-column-indicator.el
Buffer list: (eww fill-column-indicator.el)
In buffer fill-column-indicator.el
Buffer list: ( *temp*-364654 fill-column-indicator.el)
In buffer fill-column-indicator.el

There were many more of such messages

Does the fci-redraw-frame definition above and the fact that it is
added to window-configuration-change-hook give an idea as to what's
causing this infloop?


--
Kaushal Modi

bug#21738: 25.0.50; eww freezes/crashes at times

[Eli Zaretskii]

> From: Kaushal Modi <kaushal.modi@gmail.com>
> Date: Fri, 23 Oct 2015 17:16:23 -0400
> Cc: Glenn Morris <rgm@gnu.org>, 21738@debbugs.gnu.org
> 
> I updated and rebuilt (without imagemagick).
> I still get the same problem if I load eww in a 2-window frame, with fci loaded.
> eww loads that webpage fine after I do C-x 1.
> 
> Backtrace after C-g and debug-on-quit set to t:
> 
> window-end(#<window 3 on *Backtrace*> updated)
>   #[(w) "\301 !\302 \303\"B\207" [w window-start window-end updated]
> 4](#<window 3 on *Backtrace*>)
>   mapcar(#[(w) "\301 !\302 \303\"B\207" [w window-start window-end
> updated] 4] (#<window 3 on *Backtrace*>))
>   fci-delete-unneeded()
>   fci-redraw-frame()
>   set-window-buffer(nil #<buffer  *temp*-411462>)
>   shr-render-td-1((td ((class . "Body") (shr-td-cache-natural . 222)
> (shr-td-cache-10-nil 217 222 1 (#("Yank." 0 1 (face variable-pitch
> shr-indentation nil) 1 5 (face variable-pitch))) 1 nil nil)) "\n
> Yank.\n    ") 268 t)
>   shr-render-td((td ((class . "Body") (shr-td-cache-natural . 222)
> (shr-td-cache-10-nil 217 222 1 (#("Yank." 0 1 (face variable-pitch
> shr-indentation nil) 1 5 (face variable-pitch))) 1 nil nil)) "\n
> Yank.\n    ") 268 t)

Thanks.  Please make a separate bug report about this, it's an
unrelated issue.

bug#21738: 25.0.50; eww freezes/crashes at times

[Wolfgang Jenkner]

On Thu, Oct 22 2015, Kaushal Modi wrote:

> Missing separate debuginfo for /home/kmodi/usr_local/6/lib64/libgif.so.4

I wonder a bit about the versions of your various packages:

You said you are on RHEL 6.1, so I guess that (the old version of)
libgif above has been installed from a RHEL or CentOS package; in any
case, it seems to match the version in

http://mirror.centos.org/centos/6/os/x86_64/Packages/

On the other hand, on emacs-devel you said that your ImageMagick is
6.8.9.1, which is relatively recent (2014) and does not match the
version in the list above, viz. 6.7.2.7 (also, your gdb does not
complain about missing debug info here).

So, did you compile ImageMagick yourself?  Perhaps it might be
worthwhile to try the CentOS package above instead?

(Note that I have no idea about RHEL or CentOS, so I don't really know
what I'm talking about here.)

bug#21738: 25.0.50; eww freezes/crashes at times

[Kaushal Modi]

> You said you are on RHEL 6.1

I gave wrong information by mistake.. it's actually RHEL 6.6. But that
still doesn't change anything.

> so I guess that (the old version of) libgif above has been installed from a RHEL or CentOS package

I had to jump through some hoops to install libgif on my system. You
had helped me: https://lists.gnu.org/archive/html/emacs-devel/2015-09/msg00422.html
:)

> On the other hand, on emacs-devel you said that your ImageMagick is 6.8.9.1, which is relatively recent (2014) and does not match the version in the list above, viz. 6.7.2.7

I was unaware that the ImageMagick version had to match. I have to
manually install Imagemagick as it's not installed by default. I just
updated to the latest 6.9.2-4 but that too did not help. Do I have to
use the version associated with release.. 6.7.2-7 in this case?

> (also, your gdb does not complain about missing debug info here).

I don't know what that means. This is what I get:

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

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
libgcc-4.4.7-11.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

> So, did you compile ImageMagick yourself?

Yes

> Perhaps it might be worthwhile to try the CentOS package above instead?

I'll give that a try (I believe I will need to do it the same way I
did for libgif.. extract rpm, etc).

Thanks!

bug#21738: 25.0.50; eww freezes/crashes at times

[Kaushal Modi]

> Thanks.  Please make a separate bug report about this, it's an
> unrelated issue.

I will definitely create a new bug report for that issue I see with
window walking, fci and eww. I'll see if I can create a MWE without
needing to install fci.

bug#21738: 25.0.50; eww freezes/crashes at times

[Wolfgang Jenkner]

On Mon, Oct 26 2015, Kaushal Modi wrote:

> I was unaware that the ImageMagick version had to match. I have to
> manually install Imagemagick as it's not installed by default. I just
> updated to the latest 6.9.2-4 but that too did not help. Do I have to
> use the version associated with release.. 6.7.2-7 in this case?

It's OK to try newer library versions, of course, but, pragmatically
speaking, I'd guess that people might care more about emacs running on
a stock (if rather old) RHEL 6.6 than on some idiosyncratic system :-)

However, as I said, I have no idea about RHEL or CentOS, so instead of
wasting much time with a hopeless cause you might prefer to wait (or
search) for more qualified advice in this matter.

bug#21738: 25.0.50; eww freezes/crashes at times

[Wolfgang Jenkner]

On Fri, Oct 23 2015, Andreas Schwab wrote:

> It just means that ImageMagick does not track errno precicely.

Indeed, IIUC, it is pthread_key_delete(3) that fails (with EINVAL,
though):

http://git.imagemagick.org/repos/ImageMagick/blob/master/coders/tiff.c#L2383

http://git.imagemagick.org/repos/ImageMagick/blob/master/MagickCore/thread.c#L99

This means that compiling ImageMagick without threads support
(./configure --without-threads) should change... something.

bug#21738: 25.0.50; eww freezes/crashes at times

[Kaushal Modi]

> This means that compiling ImageMagick without threads support (./configure --without-threads) should change... something.

You are doing such a great job by just "guessing" :) That worked! This
is awesome! :D
Now I see Imagemagick resizing the images on that web-page on doing,

(eww "http://www.braveclojure.com/basic-emacs")

Earlier the images did not get re-sized when I used
--without-imagemagick when building emacs.

Also to confirm, here is my build info:

Built on x86_64-unknown-linux-gnu

Configure options: --prefix=/home/kmodi/usr_local/apps/6/emacs/master
'CPPFLAGS=-fgnu89-inline -I/home/kmodi/usr_local/6/include
-I/usr/include/freetype2 -I/usr/include' 'CFLAGS=-ggdb3 -O0'
'CXXFLAGS=-ggdb3 -O0' 'LDFLAGS=-L/home/kmodi/usr_local/6/lib
-L/home/kmodi/usr_local/6/lib64 -ggdb3'

Features: XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GCONF
GSETTINGS NOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE LIBOTF XFT
ZLIB TOOLKIT_SCROLL_BARS GTK2 X11

I built Imagemagick 6.9.2-4 with the --without-threads configure option.

Thanks once again for this help!

-- 
Kaushal Modi