bug#38774: crash in image_pix_context_get_pixel

[mituharu]

>>> 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@math.s.chiba-u.ac.jp