Subject: bug#39948: 28.0.50; crash in fchmodat

From: Stephen Berman <[email-masked]>
Date: Sat, 07 Mar 2020 14:43:29 +0100

On Sat, 07 Mar 2020 01:30:58 +0100 Stephen Berman <[email-masked]> wrote:

> On Fri, 6 Mar 2020 15:54:07 -0800 Paul Eggert <[email-masked]> 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