GNU bug report logs - #22301
25.1.50; Emacs crashes while lisp debugging

Previous Next

Package: emacs;

Reported by: Vincent Belaïche <vincentb1 <at> users.sourceforge.net>

Date: Sun, 3 Jan 2016 22:44:02 UTC

Severity: normal

Tags: moreinfo, wontfix

Found in version 25.1.50

Done: Glenn Morris <rgm <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


Message #47 received at 22301 <at> debbugs.gnu.org (full text, mbox):

From: Vincent Belaïche <vincentb1 <at> users.sourceforge.net> 
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Vincent Belaïche <vincentb1 <at> users.sourceforge.net>,
 22301 <at> debbugs.gnu.org
Subject: Re: bug#22301: 25.1.50; Emacs crashes while lisp debugging
Date: Wed, 20 Jan 2016 00:34:28 +0100
Dear Eli,

I have recompiled with the latest source and using the compiler options
which you gave me, and I do not reproduce the crash (although I have
been debugging my SES bugs at length). I have recompiled with the 32bit
MinGW. However I am not sure whether the Emacs version that was crashing
(that of 2015-12-16), was compiled with this MinGW or with the 64bit
MinGW.

I think that it was also compiled with the 32bit, because my MSYS fstab
file date is "12-16 08:49", and the crashing emacs.exe date is "12-16
10:27". So the fstab setting (currently pointing at the 32bit MinGW
compiler) is anterior the crashing Emacs emacs.exe. However I am not
100% sure, I may well have launched the compilation earlier than
changing the fstab file, but as compiling is so long, the emacs.exe date
could however be after the fstab modification time.

In a nutshell, is there any way to know whether the crashing Emacs was
compiled with the 32bit MinGW or with another MinGW. Please note that
the `M-x report-emacs-bug' gives on the crashing Emacs the following
text:

  In GNU Emacs 25.1.50.1 (i686-pc-mingw32)
    of 2015-12-16

as was in my initial bug report.

So, where does this `i686-pc-mingw32' in the bug report come from?

   Vincent.

PS: does TRT mean "trick 'r treat" or "Turkish Radio Television"?

Le 15/01/2016 09:12, Eli Zaretskii a écrit :
>> From: Vincent Belaïche <vincentb1 <at> users.sourceforge.net> 
>> Cc: Vincent Belaïche <vincentb1 <at> users.sourceforge.net>  ,
>>  22301 <at> debbugs.gnu.org
>> Date: Fri, 15 Jan 2016 08:56:44 +0100
>>
>> I had compiled with this line in the script launching it all:
>>
>>   export CPPFLAGS="$CPPFLAGS -DFOR_MSW=1 -I ${HERE_DIR}/libXpm-3.5.8/include -I ${HERE_DIR}/libXpm-3.5.8/src -L ${HERE_DIR}/libXpm-3.5.8/src"
>>
>> I will recompile with it modified as follows (-Og added):
>>
>>   export CPPFLAGS="$CPPFLAGS -Og -DFOR_MSW=1 -I ${HERE_DIR}/libXpm-3.5.8/include -I ${HERE_DIR}/libXpm-3.5.8/src -L ${HERE_DIR}/libXpm-3.5.8/src"
>>
>> Could you please confirm it is what you want before I go there.
>
> Not -Og, -O0.  Also, it's wrong to put all these into CPPFLAGS, so I
> suggest this instead (2 commands instead of one):
>
>   export CPPFLAGS="$CPPFLAGS -DFOR_MSW=1 -I ${HERE_DIR}/libXpm-3.5.8/include -I ${HERE_DIR}/libXpm-3.5.8/src"
>   export CFLAGS="$CFLAGS -O0 -g3 -L ${HERE_DIR}/libXpm-3.5.8/src"
>
>> PS: BTW, it won't be the same Emacs source code as the one crashing
>> anyway, because I did some git pull meanwhile. what shall I do with
>> that, shouldn't I try another git pull to work on the latest src
>> version, or should I try to get the same src as the one crashing by
>> getting a work area revision bashed on crashing Eamcs version
>> compilation date.
>
> Using the latest sources is always TRT.  Thanks.





This bug report was last modified 8 years and 166 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.