[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