GNU bug report logs - #38774
crash in image_pix_context_get_pixel

Previous Next

Package: emacs;

Reported by: Madhu <enometh <at> meer.net>

Date: Sat, 28 Dec 2019 14:50:02 UTC

Severity: normal

Done: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 38774 in the body.
You can then email your comments to 38774 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#38774; Package emacs. (Sat, 28 Dec 2019 14:50:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Madhu <enometh <at> meer.net>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Sat, 28 Dec 2019 14:50:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Madhu <enometh <at> meer.net>
To: bug-gnu-emacs <at> gnu.org
Subject: crash in image_pix_context_get_pixel
Date: Sat, 28 Dec 2019 19:57:06 +0530
Recent emacs configured with

configure -C --without-all --with-xml2 --with-dbus --with-m17n-flt
 --with-libotf --with-xft --with-x-toolkit=athena
 --with-toolkit-scroll-bars --with-xaw3d --with-cairo --with-harfbuzz
 --with-png

crashes on startup. The backtrace is

Starting program: /7/gtk/emacs/build-xt-debug/src/emacs -Q
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
delete terminal 0xa4b720 called

Program received signal SIGSEGV, Segmentation fault.
0x00000000005bf574 in image_pix_context_get_pixel (y=<optimized out>, x=0, 
    image=0xb3a210) at /7/gtk/emacs/src/image.c:183
(gdb) back
#0  0x00000000005bf574 in image_pix_context_get_pixel (y=<optimized out>, 
    x=0, image=0xb3a210) at /7/gtk/emacs/src/image.c:183
#1  image_pix_context_get_pixel (image=0xb3a210, x=0, y=<optimized out>)
    at /7/gtk/emacs/src/image.c:180
#2  0x00000000005bf65c in four_corners_best (pimg=0xb3a210, 
    corners=corners <at> entry=0xde108c, width=2, height=24)
    at /7/gtk/emacs/src/image.c:1334
#3  0x00000000005c2dfc in image_background (img=0xde1020, f=0xb0e9c0, 
    pimg=<optimized out>, pimg <at> entry=0x0) at /7/gtk/emacs/src/image.c:1374
#4  0x00000000004c8c9b in x_setup_relief_colors (s=s <at> entry=0x7fffffffbaa0)
    at /7/gtk/emacs/src/xterm.c:2746
#5  0x00000000004c8e09 in x_draw_glyph_string_box (s=s <at> entry=0x7fffffffbaa0)
    at /7/gtk/emacs/src/xterm.c:3029
#6  0x00000000004c9c98 in x_draw_glyph_string (s=0x7fffffffbaa0)
    at /7/gtk/emacs/src/xterm.c:3970
#7  0x000000000045d045 in draw_glyphs (w=0xbfd670, x=<optimized out>, 
    row=0xc9d960, area=TEXT_AREA, start=<optimized out>, end=<optimized out>, 
    hl=<optimized out>, overlaps=<optimized out>)
    at /7/gtk/emacs/src/xdisp.c:28490
#8  0x0000000000462731 in gui_write_glyphs (w=0xbfd670, 
    updated_row=<optimized out>, start=<optimized out>, 
    updated_area=TEXT_AREA, len=13) at /7/gtk/emacs/src/xdisp.c:30517
#9  0x000000000041d843 in update_text_area (vpos=0, updated_row=0xc9d960, 
    w=0xbfd670) at /7/gtk/emacs/src/dispnew.c:3832
#10 update_window_line (w=w <at> entry=0xbfd670, vpos=vpos <at> entry=0, 
    mouse_face_overwritten_p=mouse_face_overwritten_p <at> entry=0x7fffffffc33f)
    at /7/gtk/emacs/src/dispnew.c:4075
#11 0x0000000000422099 in update_window (w=w <at> entry=0xbfd670, 
    force_p=<optimized out>, force_p <at> entry=true)
    at /7/gtk/emacs/src/dispnew.c:3604
#12 0x00000000004238ae in update_frame (f=f <at> entry=0xb0e9c0, 
    force_p=<optimized out>, force_p <at> entry=false, 
    inhibit_hairy_id_p=inhibit_hairy_id_p <at> entry=false)
    at /7/gtk/emacs/src/dispnew.c:3206
#13 0x0000000000457f65 in redisplay_internal ()
    at /7/gtk/emacs/src/xdisp.c:15702
#14 0x00000000004f45d7 in read_char (commandflag=1, map=XIL(0xad0d63), 
    prev_event=XIL(0), used_mouse_menu=0x7fffffffdd8b, end_time=0x0)
    at /7/gtk/emacs/src/keyboard.c:2488
#15 0x00000000004f6eee in read_key_sequence (keybuf=<optimized out>, 
    prompt=XIL(0), dont_downcase_last=<optimized out>, 
    can_return_switch_frame=true, fix_current_buffer=true, 
    prevent_redisplay=<optimized out>) at /7/gtk/emacs/src/keyboard.c:9538
#16 0x00000000004f856e in command_loop_1 () at /7/gtk/emacs/src/lisp.h:1047
#17 0x000000000055bf57 in internal_condition_case (
    bfun=bfun <at> entry=0x4f8390 <command_loop_1>, 
    handlers=handlers <at> entry=XIL(0x90), hfun=hfun <at> entry=0x4ef690 <cmd_error>)
    at /7/gtk/emacs/src/eval.c:1355
#18 0x00000000004ea44c in command_loop_2 (ignore=ignore <at> entry=XIL(0))
    at /7/gtk/emacs/src/lisp.h:1047
#19 0x000000000055beb1 in internal_catch (tag=tag <at> entry=XIL(0xcc60), 
    func=func <at> entry=0x4ea430 <command_loop_2>, arg=arg <at> entry=XIL(0))
    at /7/gtk/emacs/src/eval.c:1116
#20 0x00000000004ea3f4 in command_loop () at /7/gtk/emacs/src/lisp.h:1047
#21 0x00000000004ef2a6 in recursive_edit_1 ()
    at /7/gtk/emacs/src/keyboard.c:714
#22 0x00000000004ef5d0 in Frecursive_edit ()
    at /7/gtk/emacs/src/keyboard.c:786
#23 0x000000000041aa71 in main (argc=2, argv=<optimized out>)
    at /7/gtk/emacs/src/emacs.c:2078

Lisp Backtrace:
"redisplay_internal (C function)" (0x0)
(gdb)  p image->data

0x0

With emacs -nw (which doesn't crash) the following details are printed:

In GNU Emacs 28.0.50 (build 2, x86_64-pc-linux-gnu, X toolkit, cairo version 1.\
16.0, Xaw3d scroll bars) of 2019-12-28 built on leonis4

[BTW
Composing main Info directory...done
user-error: Info file emacs does not exist
	;; What nonsense! Of course it exists! in /7/gtk/emacs/info/emacs.info
]

Configured features:
XAW3D PNG CAIRO DBUS LIBXML2 FREETYPE HARFBUZZ M17N_FLT LIBOTF
TOOLKIT_SCROLL_BARS LUCID X11 XDBE XIM PDUMPER GMP

Now I had this same crash on master a few weeks ago even before the
emacs-28 branch (when compiled with gtk instead of xt - the crash
happened on a emacs -Q -f gnus in that case)

The information in this bug report may not be enough as it may depend on
the versions of the graphics libraries. I will be glad to supply the
info if it is needed.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#38774; Package emacs. (Sat, 28 Dec 2019 17:21:02 GMT) Full text and rfc822 format available.

Message #8 received at 38774 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Madhu <enometh <at> meer.net>
Cc: 38774 <at> debbugs.gnu.org
Subject: Re: bug#38774: crash in image_pix_context_get_pixel
Date: Sat, 28 Dec 2019 19:20:21 +0200
> From: Madhu <enometh <at> meer.net>
> Date: Sat, 28 Dec 2019 19:57:06 +0530
> 
> Recent emacs configured with
> 
> configure -C --without-all --with-xml2 --with-dbus --with-m17n-flt
>  --with-libotf --with-xft --with-x-toolkit=athena
>  --with-toolkit-scroll-bars --with-xaw3d --with-cairo --with-harfbuzz
>  --with-png
> 
> crashes on startup.

Thanks.

Assuming that you sync with the Git repository from time to time, what
was the last development version that worked for you?  Was that
version configured the same?  Did you update your system's libraries
since the last time Emacs worked?

> Program received signal SIGSEGV, Segmentation fault.
> 0x00000000005bf574 in image_pix_context_get_pixel (y=<optimized out>, x=0, 
>     image=0xb3a210) at /7/gtk/emacs/src/image.c:183

Please show the contents of the 'image' argument, like this:

 (gdb) p *image

And btw, why are the arguments shown in reverse order?  The signature
of image_pix_context_get_pixel is this:

  image_pix_context_get_pixel (Emacs_Pix_Context image, int x, int y)

And also:

  #0  0x00000000005bf574 in image_pix_context_get_pixel (y=<optimized out>, 
      x=0, image=0xb3a210) at /7/gtk/emacs/src/image.c:183
  #1  image_pix_context_get_pixel (image=0xb3a210, x=0, y=<optimized out>)
      at /7/gtk/emacs/src/image.c:180

This claims that image_pix_context_get_pixel calls itself on line 180
of image.c, which is false.  I guess the optimized build makes the
backtrace corrupted.

Can you build Emacs without optimizations and show the backtrace in
that build?  (Assuming the crash doesn't disappear if you do that.)

> [BTW
> Composing main Info directory...done
> user-error: Info file emacs does not exist
> 	;; What nonsense! Of course it exists! in /7/gtk/emacs/info/emacs.info
> ]

Why did you assume Emacs will know to look in that directory?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#38774; Package emacs. (Sun, 29 Dec 2019 12:53:01 GMT) Full text and rfc822 format available.

Message #11 received at 38774 <at> debbugs.gnu.org (full text, mbox):

From: mituharu <at> math.s.chiba-u.ac.jp
To: "Madhu" <enometh <at> meer.net>
Cc: 38774 <at> debbugs.gnu.org
Subject: Re: bug#38774: crash in image_pix_context_get_pixel
Date: Sun, 29 Dec 2019 21:52:19 +0900
>
> Recent emacs configured with
>
> configure -C --without-all --with-xml2 --with-dbus --with-m17n-flt
>  --with-libotf --with-xft --with-x-toolkit=athena
>  --with-toolkit-scroll-bars --with-xaw3d --with-cairo --with-harfbuzz
>  --with-png
>
> crashes on startup

Could you try the patch below?

				     YAMAMOTO Mitsuharu
				mituharu <at> math.s.chiba-u.ac.jp

diff --git a/src/image.c b/src/image.c
index fc90c5ea74..7172bfc810 100644
--- a/src/image.c
+++ b/src/image.c
@@ -1242,6 +1242,10 @@ prepare_image_for_display (struct frame *f, struct
image *img)
       if (img->cr_data == NULL || (cairo_pattern_get_type (img->cr_data)
 				   != CAIRO_PATTERN_TYPE_SURFACE))
 	{
+	  /* Fill in the background/background_transparent field while
+	     we have img->pixmap->data/img->mask->data.  */
+	  IMAGE_BACKGROUND (img, f, img->pixmap);
+	  IMAGE_BACKGROUND_TRANSPARENT (img, f, img->mask);
 	  cr_put_image_to_cr_data (img);
 	  if (img->cr_data == NULL)
 	    {






Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#38774; Package emacs. (Mon, 30 Dec 2019 06:11:02 GMT) Full text and rfc822 format available.

Message #14 received at 38774 <at> debbugs.gnu.org (full text, mbox):

From: mituharu <at> math.s.chiba-u.ac.jp
To: "Madhu" <enometh <at> meer.net>,
 38774 <at> debbugs.gnu.org
Subject: Re: bug#38774: crash in image_pix_context_get_pixel
Date: Mon, 30 Dec 2019 15:10:40 +0900
>>
>> Recent emacs configured with
>>
>> configure -C --without-all --with-xml2 --with-dbus --with-m17n-flt
>>  --with-libotf --with-xft --with-x-toolkit=athena
>>  --with-toolkit-scroll-bars --with-xaw3d --with-cairo --with-harfbuzz
>>  --with-png
>>
>> crashes on startup
>
> Could you try the patch below?
>
>      YAMAMOTO Mitsuharu
> mituharu <at> math.s.chiba-u.ac.jp
>
> diff --git a/src/image.c b/src/image.c
> index fc90c5ea74..7172bfc810 100644
> --- a/src/image.c
> +++ b/src/image.c
> @@ -1242,6 +1242,10 @@ prepare_image_for_display (struct frame *f, struct
> image *img)
>        if (img->cr_data == NULL || (cairo_pattern_get_type (img->cr_data)
>     != CAIRO_PATTERN_TYPE_SURFACE))
>  {
> +  /* Fill in the background/background_transparent field while
> +     we have img->pixmap->data/img->mask->data.  */
> +  IMAGE_BACKGROUND (img, f, img->pixmap);
> +  IMAGE_BACKGROUND_TRANSPARENT (img, f, img->mask);
>    cr_put_image_to_cr_data (img);
>    if (img->cr_data == NULL)
>      {

Also, could you try if the following patch gives some output in
the terminal from which you invoke Emacs?  I suspect find-image
failed to get a proper tool bar icon image file because
file-readable-p erroneously returned nil.

				     YAMAMOTO Mitsuharu
				mituharu <at> math.s.chiba-u.ac.jp

diff --git a/src/fileio.c b/src/fileio.c
index 01f8a04e5d..997faa9820 100644
--- a/src/fileio.c
+++ b/src/fileio.c
@@ -162,6 +162,12 @@ file_access_p (char const *file, int amode)
   if (faccessat (AT_FDCWD, file, amode, AT_EACCESS) == 0)
     return true;

+  if (errno == EINTR)
+    {
+      perror ("faccessat");
+      fprintf (stderr, "file = %s, amode = %d\n", file, amode);
+    }
+
 #ifdef CYGWIN
   /* Return success if faccessat failed because Cygwin couldn't
      determine the file's UID or GID.  */






Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#38774; Package emacs. (Wed, 01 Jan 2020 06:09:01 GMT) Full text and rfc822 format available.

Message #17 received at 38774 <at> debbugs.gnu.org (full text, mbox):

From: mituharu <at> math.s.chiba-u.ac.jp
To: "Madhu" <enometh <at> meer.net>
Cc: 38774 <at> debbugs.gnu.org
Subject: Re: bug#38774: crash in image_pix_context_get_pixel
Date: Wed, 1 Jan 2020 15:08:40 +0900
>>> Could you try the patch below?
>>> diff --git a/src/image.c b/src/image.c
>>> index fc90c5ea74..7172bfc810 100644
>
> Thanks. With that patch I do not get the crash.

Thanks for testing.  I'll install the patch later.

>> Also, could you try if the following patch gives some output in
>> the terminal from which you invoke Emacs?  I suspect find-image
>> failed to get a proper tool bar icon image file because
>> file-readable-p erroneously returned nil.
>
>> diff --git a/src/fileio.c b/src/fileio.c
>> index 01f8a04e5d..997faa9820 100644
>
> I did not get any output from this code branch.  I had the previous
> version of emacs (which did crash) lying around and doing an strace -e
> faccessat emacs, the last image files that are accessed are calls to
> accessat(AT_FDCWD, "/7/gtk/emacs/etc/images/separator.pbm", R_OK) = 0
> before it crashed.

Actually it is strange to access the PBM version because we only
use the XPM one.  Is the XPM version in the same directory
accessed before the PBM one?  If so, can you get the errno in the
strace output?

I could observe spontaneous interrupted faccessat calls on Linux
4.13.0 with a network-mounted source tree on Parallels Desktop
12.

  faccessat(AT_FDCWD,
"/home/mituharu/src/git/emacs/trunk/etc/images/separator.xpm", R_OK) = ?
ERESTARTSYS (To be restarted if SA_RESTART is set)

The man page of faccessat does not say it may fail with EINTR,
but it actually does on some environments (probably with NFS, see
also Bug#9256).  Maybe we should retry faccessat when it fails
with EINTR so file-readable-p and the like may not return false
results.

				     YAMAMOTO Mitsuharu
				mituharu <at> math.s.chiba-u.ac.jp





Reply sent to YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>:
You have taken responsibility. (Tue, 07 Jan 2020 03:55:02 GMT) Full text and rfc822 format available.

Notification sent to Madhu <enometh <at> meer.net>:
bug acknowledged by developer. (Tue, 07 Jan 2020 03:55:02 GMT) Full text and rfc822 format available.

Message #22 received at 38774-done <at> debbugs.gnu.org (full text, mbox):

From: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
To: "Madhu" <enometh <at> meer.net>
Cc: 38774-done <at> debbugs.gnu.org
Subject: Re: bug#38774: crash in image_pix_context_get_pixel
Date: Tue, 07 Jan 2020 12:54:31 +0900
On Wed, 01 Jan 2020 15:08:40 +0900,
mituharu <at> math.s.chiba-u.ac.jp wrote:
> 
> >>> Could you try the patch below?
> >>> diff --git a/src/image.c b/src/image.c
> >>> index fc90c5ea74..7172bfc810 100644
> >
> > Thanks. With that patch I do not get the crash.
> 
> Thanks for testing.  I'll install the patch later.

Installed to the emacs-27 branch.  Closing the bug.

				     YAMAMOTO Mitsuharu
				mituharu <at> math.s.chiba-u.ac.jp




bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Tue, 04 Feb 2020 12:24:07 GMT) Full text and rfc822 format available.

This bug report was last modified 5 years and 195 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.