bug#39948: 28.0.50; crash in fchmodat

bug#39948: 28.0.50; crash in fchmodat

[Stephen Berman]

I updated from master today and now Emacs is crashing when I use Gnus.
The first time it happened I been reading news groups for a while, then
email arrived and when I pulled it into Gnus, Emacs crashed.  Then I
restarted Emacs under GDB and now get the crash already on starting Gnus
(with my initializations; it doesn't happen when I start an unconfigured
Gnus in Emacs -Q).  I tried to get a full backtrace, but the output of
`bt full' seemed to be in an endless loop; here's the start of the
backtrace:

Thread 1 "emacs" received signal SIGSEGV, Segmentation fault.
0x000000000060c9b2 in fchmodat (dir=dir@entry=-100,
    file=file@entry=0x4be6b40 "/home/steve/Mail/unsorted.nov",
    mode=mode@entry=384, flags=flags@entry=0)
    at /home/steve/src/emacs/emacs-master/lib/fchmodat.c:65
65      {
(gdb) bt full
#0  0x000000000060c9b2 in fchmodat
    (dir=dir@entry=-100, file=file@entry=0x4be6b40 "/home/steve/Mail/unsorted.nov", mode=mode@entry=384, flags=flags@entry=0)
    at /home/steve/src/emacs/emacs-master/lib/fchmodat.c:65
#1  0x000000000060cae4 in orig_fchmodat
    (dir=dir@entry=-100, file=file@entry=0x4be6b40 "/home/steve/Mail/unsorted.nov", mode=mode@entry=384, flags=flags@entry=0)
    at /home/steve/src/emacs/emacs-master/lib/fchmodat.c:33
#2  0x000000000060c9e0 in fchmodat
    (dir=dir@entry=-100, file=file@entry=0x4be6b40 "/home/steve/Mail/unsorted.nov", mode=mode@entry=384, flags=flags@entry=0)
    at /home/steve/src/emacs/emacs-master/lib/fchmodat.c:134
#3  0x000000000060cae4 in orig_fchmodat
    (dir=dir@entry=-100, file=file@entry=0x4be6b40 "/home/steve/Mail/unsorted.nov", mode=mode@entry=384, flags=flags@entry=0)
    at /home/steve/src/emacs/emacs-master/lib/fchmodat.c:33
#4  0x000000000060c9e0 in fchmodat
    (dir=dir@entry=-100, file=file@entry=0x4be6b40 "/home/steve/Mail/unsorted.nov", mode=mode@entry=384, flags=flags@entry=0)
    at /home/steve/src/emacs/emacs-master/lib/fchmodat.c:134
#5  0x000000000060cae4 in orig_fchmodat
    (dir=dir@entry=-100, file=file@entry=0x4be6b40 "/home/steve/Mail/unsorted.nov", mode=mode@entry=384, flags=flags@entry=0)
   ter/lib/fchmodat.c:33

This pattern repeated for tens of thousands of frames, then I
interrupted it and typed `c':

(gdb) c
Continuing.

Thread 1 "emacs" hit Breakpoint 1, terminate_due_to_signal (sig=sig@entry=11,
    backtrace_limit=backtrace_limit@entry=40)
    at /home/steve/src/emacs/emacs-master/src/emacs.c:370
370     {
(gdb)
Continuing.
Fatal error 11: Segmentation fault
Backtrace:
/home/steve/build/emacs-master/src/emacs[0x524450]
/home/steve/build/emacs-master/src/emacs[0x5068e0]
/home/steve/build/emacs-master/src/emacs[0x522745]
/home/steve/build/emacs-master/src/emacs[0x522772]
/home/steve/build/emacs-master/src/emacs[0x5227cf]
/home/steve/build/emacs-master/src/emacs[0x522895]
/lib/libpthread.so.0(+0x12680)[0x7ffff61a5680]
/home/steve/build/emacs-master/src/emacs(fchmodat+0x2f)[0x60c9db]
/home/steve/build/emacs-master/src/emacs[0x60cae4]
/home/steve/build/emacs-master/src/emacs(fchmodat+0x34)[0x60c9e0]
/home/steve/build/emacs-master/src/emacs[0x60cae4]
/home/steve/build/emacs-master/src/emacs(fchmodat+0x34)[0x60c9e0]
/home/steve/build/emacs-master/src/emacs[0x60cae4]
/home/steve/build/emacs-master/src/emacs(fchmodat+0x34)[0x60c9e0]
/home/steve/build/emacs-master/src/emacs[0x60cae4]
/home/steve/build/emacs-master/src/emacs(fchmodat+0x34)[0x60c9e0]
/home/steve/build/emacs-master/src/emacs[0x60cae4]
/home/steve/build/emacs-master/src/emacs(fchmodat+0x34)[0x60c9e0]
/home/steve/build/emacs-master/src/emacs[0x60cae4]
/home/steve/build/emacs-master/src/emacs(fchmodat+0x34)[0x60c9e0]
/home/steve/build/emacs-master/src/emacs[0x60cae4]
/home/steve/build/emacs-master/src/emacs(fchmodat+0x34)[0x60c9e0]
/home/steve/build/emacs-master/src/emacs[0x60cae4]
/home/steve/build/emacs-master/src/emacs(fchmodat+0x34)[0x60c9e0]
/home/steve/build/emacs-master/src/emacs[0x60cae4]
/home/steve/build/emacs-master/src/emacs(fchmodat+0x34)[0x60c9e0]
/home/steve/build/emacs-master/src/emacs[0x60cae4]
/home/steve/build/emacs-master/src/emacs(fchmodat+0x34)[0x60c9e0]
/home/steve/build/emacs-master/src/emacs[0x60cae4]
/home/steve/build/emacs-master/src/emacs(fchmodat+0x34)[0x60c9e0]
/home/steve/build/emacs-master/src/emacs[0x60cae4]
/home/steve/build/emacs-master/src/emacs(fchmodat+0x34)[0x60c9e0]
/home/steve/build/emacs-master/src/emacs[0x60cae4]
/home/steve/build/emacs-master/src/emacs(fchmodat+0x34)[0x60c9e0]
/home/steve/build/emacs-master/src/emacs[0x60cae4]
/home/steve/build/emacs-master/src/emacs(fchmodat+0x34)[0x60c9e0]
/home/steve/build/emacs-master/src/emacs[0x60cae4]
/home/steve/build/emacs-master/src/emacs(fchmodat+0x34)[0x60c9e0]
/home/steve/build/emacs-master/src/emacs[0x60cae4]
/home/steve/build/emacs-master/src/emacs(fchmodat+0x34)[0x60c9e0]
/home/steve/build/emacs-master/src/emacs[0x60cae4]
...

Thread 1 "emacs" received signal SIGSEGV, Segmentation fault.
raise (sig=sig@entry=11) at ../sysdeps/unix/sysv/linux/raise.c:50
50      ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.



In GNU Emacs 28.0.50 (build 5, x86_64-pc-linux-gnu, GTK+ Version 3.24.5, cairo version 1.16.0)
 of 2020-03-06 built on strobe-lfs84
Repository revision: c996fe1ec69de0082043397d4965d08cb94892fb
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12003000
System Description: Linux From Scratch

Recent messages:
Loading /home/steve/.emacs.d/srb/srb-mail.el (source)...done
Loading /home/steve/.emacs.d/srb/srb-elisp.el (source)...done
Loading todo-mode...done
Loading /home/steve/.emacs.d/srb/srb-cal+diary+appt.el (source)...done
Loading /home/steve/.emacs.d/srb/srb-global-key-bindings.el (source)...done
Preparing diary...
No diary entries for Friday, March 6, 2020
Preparing diary...done
Appointment reminders enabled
For information about GNU Emacs and the GNU system, type C-h C-a.

Configured using:
 'configure 'CFLAGS=-Og -g3' PKG_CONFIG_PATH=/opt/qt5/lib/pkgconfig'

Configured features:
XPM JPEG TIFF GIF PNG RSVG CAIRO SOUND DBUS GSETTINGS GLIB NOTIFY
INOTIFY ACL GNUTLS LIBXML2 FREETYPE HARFBUZZ M17N_FLT LIBOTF ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM MODULES THREADS JSON PDUMPER LCMS2
GMP

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  pdf-occur-global-minor-mode: t
  shell-dirtrack-mode: t
  show-paren-mode: t
  recentf-mode: t
  display-time-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  temp-buffer-resize-mode: t
  column-number-mode: t
  line-number-mode: t

Load-path shadows:
None found.

Features:
(shadow mail-extr gnus-msg gnus-art mm-uu mml2015 mm-view mml-smime
smime dig gnus-sum shr svg dom gnus-group gnus-undo gnus-start
gnus-cloud nnimap nnmail mail-source utf7 netrc nnoo gnus-spec gnus-int
gnus-range gnus-win gnus nnheader emacsbug message rmc puny rfc822 mml
mml-sec epa epg epg-config gnus-util rmail rmail-loaddefs mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
cal-china lunar solar cal-dst cal-bahai cal-islam cal-hebrew holidays
hol-loaddefs face-remap appt edmacro kmacro srb-cal+diary+appt todo-mode
diary-lib diary-loaddefs cal-menu calendar cal-loaddefs srb-recentf
noutline outline pdf-occur ibuf-ext ibuffer ibuffer-loaddefs tablist
tablist-filter semantic/wisent/comp semantic/wisent
semantic/wisent/wisent semantic/util-modes semantic/util semantic
semantic/tag semantic/lex semantic/fw mode-local find-func cedet
pdf-isearch let-alist pdf-misc imenu pdf-tools compile cus-edit pdf-view
bookmark text-property-search pp jka-compr pdf-cache pdf-info pdf-util
image-mode exif srb-emms emms-librefm-stream emms-librefm-scrobbler
emms-playlist-limit emms-volume emms-volume-mixerctl emms-volume-pulse
emms-volume-amixer emms-i18n emms-history emms-score emms-stream-info
emms-metaplaylist-mode emms-bookmarks emms-cue emms-mode-line-icon
emms-browser sort emms-playlist-sort emms-last-played emms-player-xine
emms-player-mpd tq emms-playing-time emms-lyrics emms-url url url-proxy
url-privacy url-expand url-methods url-history url-cookie url-domsuf
mailcap emms-streams emms-show-all emms-tag-editor emms-mark
emms-mode-line emms-cache emms-info-opusinfo emms-info-ogginfo
emms-info-mp3info emms-info later-do emms-playlist-mode emms-player-vlc
advice emms-player-mpv emms-player-mplayer emms-player-simple
emms-source-playlist emms-source-file locate dired dired-loaddefs
emms-setup emms emms-compat tramp-sh tramp-gvfs tramp-cache zeroconf
url-util dbus xml tramp tramp-loaddefs trampver tramp-integration
files-x tramp-compat shell pcomplete comint ansi-color ring parse-time
iso8601 time-date ls-lisp format-spec srb-light-theme paren recentf
tree-widget wid-edit delsel cus-start cus-load srb-mode-line time
flotte-karotte srb-misc derived thingatpt easy-mmode quail help-mode
pcase tex-site info package easymenu browse-url url-handlers url-parse
auth-source cl-seq eieio eieio-core cl-macs eieio-loaddefs
password-cache json subr-x map url-vars seq byte-opt gv bytecomp
byte-compile cconv cl-loaddefs cl-lib tooltip eldoc electric uniquify
ediff-hook vc-hooks lisp-float-type mwheel term/x-win x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch timer
select scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame minibuffer 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 composite charscript charprop case-table epa-hook
jka-cmpr-hook help simple abbrev obarray 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 threads dbusbind inotify lcms2 dynamic-setting
system-font-setting font-render-setting cairo move-toolbar gtk x-toolkit
x multi-tty make-network-process emacs)

Memory information:
((conses 16 725576 10145)
 (symbols 48 24562 4)
 (strings 32 152593 3058)
 (string-bytes 1 10332720)
 (vectors 16 41284)
 (vector-slots 8 1373571 32340)
 (floats 8 789 129)
 (intervals 56 394 0)
 (buffers 1000 14))

bug#39948: 28.0.50; crash in fchmodat

[Robert Pluim]

>>>>> On Fri, 06 Mar 2020 15:16:43 +0100, Stephen Berman <stephen.berman@gmx.net> said:

    Stephen> I updated from master today and now Emacs is crashing when I use Gnus.
    Stephen> The first time it happened I been reading news groups for a while, then
    Stephen> email arrived and when I pulled it into Gnus, Emacs crashed.  Then I
    Stephen> restarted Emacs under GDB and now get the crash already on starting Gnus
    Stephen> (with my initializations; it doesn't happen when I start an unconfigured
    Stephen> Gnus in Emacs -Q).  I tried to get a full backtrace, but the output of
    Stephen> `bt full' seemed to be in an endless loop; here's the start of the
    Stephen> backtrace:

Wild Guess: does reverting 07da629926daf849aab248175c88cf53a5e21558
help? Or maybe 9d626dffc6ba62c0d7a1a5c712f576ed8684fd66 ?

Robert

bug#39948: 28.0.50; crash in fchmodat

[Stephen Berman]

On Fri, 06 Mar 2020 16:31:50 +0100 Robert Pluim <rpluim@gmail.com> wrote:

>>>>>> On Fri, 06 Mar 2020 15:16:43 +0100, Stephen Berman
> <stephen.berman@gmx.net> said:
>
>     Stephen> I updated from master today and now Emacs is crashing
>     Stephen> when I use Gnus.  The first time it happened I been
>     Stephen> reading news groups for a while, then email arrived and
>     Stephen> when I pulled it into Gnus, Emacs crashed.  Then I
>     Stephen> restarted Emacs under GDB and now get the crash already
>     Stephen> on starting Gnus (with my initializations; it doesn't
>     Stephen> happen when I start an unconfigured Gnus in Emacs -Q).  I
>     Stephen> tried to get a full backtrace, but the output of `bt
>     Stephen> full' seemed to be in an endless loop; here's the start
>     Stephen> of the backtrace:
>
> Wild Guess: does reverting 07da629926daf849aab248175c88cf53a5e21558
> help? Or maybe 9d626dffc6ba62c0d7a1a5c712f576ed8684fd66 ?

Reverting 07da629 does appear to prevent the crash.  Specifically, as a
sanity check, before reverting, I ran my build from master under GDB
again, started Gnus, but now Emacs didn't crash; however, then I
composed a mail to myself in Gnus and upon sending it, Emacs did crash
exactly as before in fchmodat.  This I did `git revert -n
07da629926daf849aab248175c88cf53a5e21558', rebuilt, started Emacs again,
started Gnus, there was no crash, sent a mail to myself, again with no
crash, and pulled the mail into Gnus also without the crash.  So it
appears that that commit is indeed the cause of the crash.  Thanks for
pinpointing it.

Steve Berman

bug#39948: 28.0.50; crash in fchmodat

[Stephen Berman]

On Fri, 06 Mar 2020 17:26:54 +0100 Stephen Berman <stephen.berman@gmx.net> wrote:

> On Fri, 06 Mar 2020 16:31:50 +0100 Robert Pluim <rpluim@gmail.com> wrote:
>
>>>>>>> On Fri, 06 Mar 2020 15:16:43 +0100, Stephen Berman
>> <stephen.berman@gmx.net> said:
>>
>>     Stephen> I updated from master today and now Emacs is crashing
>>     Stephen> when I use Gnus.  The first time it happened I been
>>     Stephen> reading news groups for a while, then email arrived and
>>     Stephen> when I pulled it into Gnus, Emacs crashed.  Then I
>>     Stephen> restarted Emacs under GDB and now get the crash already
>>     Stephen> on starting Gnus (with my initializations; it doesn't
>>     Stephen> happen when I start an unconfigured Gnus in Emacs -Q).  I
>>     Stephen> tried to get a full backtrace, but the output of `bt
>>     Stephen> full' seemed to be in an endless loop; here's the start
>>     Stephen> of the backtrace:
>>
>> Wild Guess: does reverting 07da629926daf849aab248175c88cf53a5e21558
>> help? Or maybe 9d626dffc6ba62c0d7a1a5c712f576ed8684fd66 ?
>
> Reverting 07da629 does appear to prevent the crash.  Specifically, as a
> sanity check, before reverting, I ran my build from master under GDB
> again, started Gnus, but now Emacs didn't crash; however, then I
> composed a mail to myself in Gnus and upon sending it, Emacs did crash
> exactly as before in fchmodat.  This I did `git revert -n
> 07da629926daf849aab248175c88cf53a5e21558', rebuilt, started Emacs again,
> started Gnus, there was no crash, sent a mail to myself, again with no
> crash, and pulled the mail into Gnus also without the crash.  So it
> appears that that commit is indeed the cause of the crash.  Thanks for
> pinpointing it.

I also got the crash using Tramp, so I guess 9d626dff also needs to be
fixed (or reverted).

Steve Berman

bug#39948: 28.0.50; crash in fchmodat

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@gmx.net>
> Date: Fri, 06 Mar 2020 15:16:43 +0100
> 
> I updated from master today and now Emacs is crashing when I use Gnus.
> The first time it happened I been reading news groups for a while, then
> email arrived and when I pulled it into Gnus, Emacs crashed.  Then I
> restarted Emacs under GDB and now get the crash already on starting Gnus
> (with my initializations; it doesn't happen when I start an unconfigured
> Gnus in Emacs -Q).  I tried to get a full backtrace, but the output of
> `bt full' seemed to be in an endless loop; here's the start of the
> backtrace:
> 
> Thread 1 "emacs" received signal SIGSEGV, Segmentation fault.
> 0x000000000060c9b2 in fchmodat (dir=dir@entry=-100,
>     file=file@entry=0x4be6b40 "/home/steve/Mail/unsorted.nov",
>     mode=mode@entry=384, flags=flags@entry=0)
>     at /home/steve/src/emacs/emacs-master/lib/fchmodat.c:65
> 65      {
> (gdb) bt full
> #0  0x000000000060c9b2 in fchmodat
>     (dir=dir@entry=-100, file=file@entry=0x4be6b40 "/home/steve/Mail/unsorted.nov", mode=mode@entry=384, flags=flags@entry=0)
>     at /home/steve/src/emacs/emacs-master/lib/fchmodat.c:65
> #1  0x000000000060cae4 in orig_fchmodat
>     (dir=dir@entry=-100, file=file@entry=0x4be6b40 "/home/steve/Mail/unsorted.nov", mode=mode@entry=384, flags=flags@entry=0)
>     at /home/steve/src/emacs/emacs-master/lib/fchmodat.c:33
> #2  0x000000000060c9e0 in fchmodat
>     (dir=dir@entry=-100, file=file@entry=0x4be6b40 "/home/steve/Mail/unsorted.nov", mode=mode@entry=384, flags=flags@entry=0)
>     at /home/steve/src/emacs/emacs-master/lib/fchmodat.c:134
> #3  0x000000000060cae4 in orig_fchmodat
>     (dir=dir@entry=-100, file=file@entry=0x4be6b40 "/home/steve/Mail/unsorted.nov", mode=mode@entry=384, flags=flags@entry=0)
>     at /home/steve/src/emacs/emacs-master/lib/fchmodat.c:33
> #4  0x000000000060c9e0 in fchmodat
>     (dir=dir@entry=-100, file=file@entry=0x4be6b40 "/home/steve/Mail/unsorted.nov", mode=mode@entry=384, flags=flags@entry=0)
>     at /home/steve/src/emacs/emacs-master/lib/fchmodat.c:134
> #5  0x000000000060cae4 in orig_fchmodat
>     (dir=dir@entry=-100, file=file@entry=0x4be6b40 "/home/steve/Mail/unsorted.nov", mode=mode@entry=384, flags=flags@entry=0)
>    ter/lib/fchmodat.c:33
> 
> This pattern repeated for tens of thousands of frames, then I
> interrupted it and typed `c':

Sounds like infinite recursion, which causes stack overflow.

bug#39948: 28.0.50; crash in fchmodat

[Robert Pluim]

>>>>> On Fri, 06 Mar 2020 17:45:13 +0200, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Stephen Berman <stephen.berman@gmx.net>
    >> Date: Fri, 06 Mar 2020 15:16:43 +0100
    >> 
    >> I updated from master today and now Emacs is crashing when I use Gnus.
    >> The first time it happened I been reading news groups for a while, then
    >> email arrived and when I pulled it into Gnus, Emacs crashed.  Then I
    >> restarted Emacs under GDB and now get the crash already on starting Gnus
    >> (with my initializations; it doesn't happen when I start an unconfigured
    >> Gnus in Emacs -Q).  I tried to get a full backtrace, but the output of
    >> `bt full' seemed to be in an endless loop; here's the start of the
    >> backtrace:
    >> 
    >> Thread 1 "emacs" received signal SIGSEGV, Segmentation fault.
    >> 0x000000000060c9b2 in fchmodat (dir=dir@entry=-100,
    >> file=file@entry=0x4be6b40 "/home/steve/Mail/unsorted.nov",
    >> mode=mode@entry=384, flags=flags@entry=0)
    >> at /home/steve/src/emacs/emacs-master/lib/fchmodat.c:65
    >> 65      {
    >> (gdb) bt full
    >> #0  0x000000000060c9b2 in fchmodat
    >> (dir=dir@entry=-100, file=file@entry=0x4be6b40 "/home/steve/Mail/unsorted.nov", mode=mode@entry=384, flags=flags@entry=0)
    >> at /home/steve/src/emacs/emacs-master/lib/fchmodat.c:65
    >> #1  0x000000000060cae4 in orig_fchmodat
    >> (dir=dir@entry=-100, file=file@entry=0x4be6b40 "/home/steve/Mail/unsorted.nov", mode=mode@entry=384, flags=flags@entry=0)
    >> at /home/steve/src/emacs/emacs-master/lib/fchmodat.c:33
    >> #2  0x000000000060c9e0 in fchmodat
    >> (dir=dir@entry=-100, file=file@entry=0x4be6b40 "/home/steve/Mail/unsorted.nov", mode=mode@entry=384, flags=flags@entry=0)
    >> at /home/steve/src/emacs/emacs-master/lib/fchmodat.c:134
    >> #3  0x000000000060cae4 in orig_fchmodat
    >> (dir=dir@entry=-100, file=file@entry=0x4be6b40 "/home/steve/Mail/unsorted.nov", mode=mode@entry=384, flags=flags@entry=0)
    >> at /home/steve/src/emacs/emacs-master/lib/fchmodat.c:33
    >> #4  0x000000000060c9e0 in fchmodat
    >> (dir=dir@entry=-100, file=file@entry=0x4be6b40 "/home/steve/Mail/unsorted.nov", mode=mode@entry=384, flags=flags@entry=0)
    >> at /home/steve/src/emacs/emacs-master/lib/fchmodat.c:134
    >> #5  0x000000000060cae4 in orig_fchmodat
    >> (dir=dir@entry=-100, file=file@entry=0x4be6b40 "/home/steve/Mail/unsorted.nov", mode=mode@entry=384, flags=flags@entry=0)
    >> ter/lib/fchmodat.c:33
    >> 
    >> This pattern repeated for tens of thousands of frames, then I
    >> interrupted it and typed `c':

    Eli> Sounds like infinite recursion, which causes stack overflow.

lib/fchmodat.c:fchmodat can call lib/fchmodat.c:orig_fchmodat, which
can call fchmodat. Presumably that last one is meant to be the system
fchmodat, but itʼs calling the fchmodat.c:fchmodat one instead. CC'ing
Paul.

Robert

bug#39948: 28.0.50; crash in fchmodat

[Paul Eggert]

On 3/6/20 8:45 AM, Robert Pluim wrote:

> lib/fchmodat.c:fchmodat can call lib/fchmodat.c:orig_fchmodat, which
> can call fchmodat. Presumably that last one is meant to be the system
> fchmodat, but itʼs calling the fchmodat.c:fchmodat one instead.

Yes, orig_fchmodat is supposed to call the system fchmodat.

Do you get the same problem with 'make bootstrap'? If not, we're done.

Otherwise, to help debug this please send the preprocessor output when 
compiling lib/fchmodat.c. Something like this:

rm lib/fchmodat.o
make V=1
Now, repeat the GCC command that compiles lib/fchmod.c, except use 'gcc 
-E' instead of 'gcc -c'.

Also, what are the values of HAVE_FCHMODAT (see src/config.h), and of 
GNULIB_FCHMODAT and REPLACE_FCHMODAT (look at the output of the command 
'diff -u lib/sys_stat.in.h lib/sys/stat.h')? Also, please double-check 
lib/gnulib.mk for those three values.

 From your symptoms I would guess for you HAVE_FCHMODAT and 
GNULIB_FCHMODAT are 1 but REPLACE_FCHMODAT is 0. But if that's the case, 
your build shouldn't be compiling lib/fchmodat.c at all, because 
'configure' says this:

   if test $HAVE_FCHMODAT = 0 || test $REPLACE_FCHMODAT = 1; then
     gl_LIBOBJS="$gl_LIBOBJS fchmodat.$ac_objext"
   fi

and so we need to investigate why this 'if' is being triggered,

bug#39948: 28.0.50; crash in fchmodat

[Stephen Berman]

On Fri, 6 Mar 2020 15:54:07 -0800 Paul Eggert <eggert@cs.ucla.edu> wrote:

> On 3/6/20 8:45 AM, Robert Pluim wrote:
>
>> lib/fchmodat.c:fchmodat can call lib/fchmodat.c:orig_fchmodat, which
>> can call fchmodat. Presumably that last one is meant to be the system
>> fchmodat, but itʼs calling the fchmodat.c:fchmodat one instead.
>
> Yes, orig_fchmodat is supposed to call the system fchmodat.
>
> Do you get the same problem with 'make bootstrap'? If not, we're done.

I was just about to shut down for the night when your mail arrived, so I
did `make bootstrap' but got the same crash both when sending a mail
with Gnus and when transfering a file with Tramp.  I'll follow up on
your other suggestions on Saturday and report back.

Steve Berman

bug#39948: 28.0.50; crash in fchmodat

[Stephen Berman]

On Sat, 07 Mar 2020 01:30:58 +0100 Stephen Berman <stephen.berman@gmx.net> wrote:

> On Fri, 6 Mar 2020 15:54:07 -0800 Paul Eggert <eggert@cs.ucla.edu> wrote:
>
>> On 3/6/20 8:45 AM, Robert Pluim wrote:
>>
>>> lib/fchmodat.c:fchmodat can call lib/fchmodat.c:orig_fchmodat, which
>>> can call fchmodat. Presumably that last one is meant to be the system
>>> fchmodat, but itʼs calling the fchmodat.c:fchmodat one instead.
>>
>> Yes, orig_fchmodat is supposed to call the system fchmodat.
>>
>> Do you get the same problem with 'make bootstrap'? If not, we're done.
>
> I was just about to shut down for the night when your mail arrived, so I
> did `make bootstrap' but got the same crash both when sending a mail
> with Gnus and when transfering a file with Tramp.  I'll follow up on
> your other suggestions on Saturday and report back.

>> Otherwise, to help debug this please send the preprocessor output when
>> compiling lib/fchmodat.c. Something like this:
>>
>> rm lib/fchmodat.o
>> make V=1
>> Now, repeat the GCC command that compiles lib/fchmod.c, except use 'gcc -E'
>> instead of 'gcc -c'.
>>
>> Also, what are the values of HAVE_FCHMODAT (see src/config.h), and of
>> GNULIB_FCHMODAT and REPLACE_FCHMODAT (look at the output of the command 
>> 'diff -u lib/sys_stat.in.h lib/sys/stat.h')? Also, please double-check
>> lib/gnulib.mk for those three values.
>>
>> From your symptoms I would guess for you HAVE_FCHMODAT and GNULIB_FCHMODAT are
>> 1 but REPLACE_FCHMODAT is 0. But if that's the case, your build shouldn't be
>> compiling lib/fchmodat.c at all, because 'configure' says this:
>>
>>   if test $HAVE_FCHMODAT = 0 || test $REPLACE_FCHMODAT = 1; then
>>     gl_LIBOBJS="$gl_LIBOBJS fchmodat.$ac_objext"
>>   fi
>>
>> and so we need to investigate why this 'if' is being triggered,

It appears that my OP was a false alarm.  I build emacs out-of-tree but
several months ago I ran `make TAGS' in the source directory and that
seems to have also compiled the files in the source lib/, since it
contained object files dated from that time.  Is it possible that these
were used when building in the build directory?  Anyway, I ran `make
distclean' in the Emacs source directory and also in the lib/ build
directory, then reconfigured and rebuilt Emacs, and now I no longer get
the crash.

Unfortunately, I rashly did this before trying out your other
suggestions, so I no longer have the previous state to check.  But I can
at least confirm that HAVE_FCHMODAT, GNULIB_FCHMODAT and
REPLACE_FCHMODAT are (now) all set to 1.

I'll keep running with this build and if the crash does not happen
anymore, I'll close the bug later today or tomorrow, unless someone
wants further testing or clarification.

Thanks for the helpful feedback.

Steve Berman

bug#39948: 28.0.50; crash in fchmodat

[Stephen Berman]

On Sat, 07 Mar 2020 14:43:29 +0100 Stephen Berman <stephen.berman@gmx.net> wrote:

> I'll keep running with this build and if the crash does not happen
> anymore, I'll close the bug later today or tomorrow, unless someone
> wants further testing or clarification.

Closed.

Steve Berman