bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#39948: 28.0.50; crash in fchmodat


From: Robert Pluim
Subject: bug#39948: 28.0.50; crash in fchmodat
Date: Fri, 06 Mar 2020 17:45:49 +0100

>>>>> 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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]