GNU bug report logs - #13939
24.3; Emacs 24.3 release won't compile on Windows with the msvc toolchain

Previous Next

Full log

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

From: Fabrice Popineau <fabrice.popineau <at> gmail.com>
To: 李丁 <iamliding <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 13939 <13939 <at> debbugs.gnu.org>
Subject: Re: bug#13939: 24.3; Emacs 24.3 release won't compile on Windows with
	the msvc toolchain
Date: Fri, 15 Mar 2013 20:49:22 +0100

[Message part 1 (text/plain, inline)]

Thinking about it, another option is to use GC_MARK_STACK = 0 . This way,
people can stick to 24.3 .

I'm a bit afraid of the unstable status of the trunk (strange things
happens sometimes, at the moment,
it seems that emacs keeps track of the size of my laptop, but gets it wrong
when I connect to an
external display. It keeps resizing frames to the wrong dimensions).

Fabrice


2013/3/15 Fabrice Popineau <fabrice.popineau <at> gmail.com>

> I guess this ends the hunt for what change fixed 24.3 for msvc.
> I spent several hours trying to track it down, but couldn't. My closest
> guest
> is among the vector/list reading code. Lots of changes happened in this
> area.
> Nothing very obvious anyway.
>
> It is very unlucky, because I compile the trunk quite often and this bug
> never surfaced
> for quite a long time (pre 24.1).
>
> I guess the best option is to use the trunk as per Eli's proposal.
>
> Fabrice
>
>
> 2013/3/15 李丁 <iamliding <at> gmail.com>
>
>> Though there are some minor errors (easy to fix), the latest trunk
>> compiles fine with msvc.
>>
>> 2013/3/15 Fabrice Popineau <fabrice.popineau <at> gmail.com>
>>
>>> 李丁:  could you try to compile the trunk with msvc and confirm that it
>>> is working for you?
>>> I would be very glad to hear a positive report, meaning I didn't mess
>>> things up.
>>>
>>> Fabrice
>>>
>>>
>>> 2013/3/15 李丁 <iamliding <at> gmail.com>
>>>
>>>> 李丁, do you also compile Emacs 24.3 as a 64-bit executable?  Or do
>>>>> you build it as a 32-bit executable?
>>>>
>>>>
>>>> I compiled Emacs as a 32-bit executable.
>>>>
>>>> If I run only temacs.exe without any arguments, I get a very quick
>>>>> backtrace:
>>>>
>>>>
>>>> I also traced the execution of `temacs -batch -l loadup dump' with
>>>> windbg, and got a similar stack trace as Fabrice (I breakpointed
>>>> Fgarbage_collect):
>>>>
>>>> temacs!Fgarbage_collect [d:\data\projects\emacs-24.3\src\alloc.c @ 5094]
>>>> temacs!maybe_gc+0x3e [d:\data\projects\emacs-24.3\src\lisp.h @ 3717]
>>>>  temacs!eval_sub+0xda [d:\data\projects\emacs-24.3\src\eval.c @ 2042]
>>>> temacs!readevalloop+0x600 [d:\data\projects\emacs-24.3\src\lread.c @
>>>> 1843]
>>>> temacs!Fload+0xb86 [d:\data\projects\emacs-24.3\src\lread.c @ 1317]
>>>> temacs!eval_sub+0x5da [d:\data\projects\emacs-24.3\src\eval.c @ 2159]
>>>> temacs!Feval+0x60 [d:\data\projects\emacs-24.3\src\eval.c @ 2005]
>>>> temacs!top_level_2+0x15 [d:\data\projects\emacs-24.3\src\keyboard.c @
>>>> 1177]
>>>> temacs!internal_condition_case+0xde
>>>> [d:\data\projects\emacs-24.3\src\eval.c @ 1289]
>>>> temacs!top_level_1+0x26 [d:\data\projects\emacs-24.3\src\keyboard.c @
>>>> 1185]
>>>> temacs!internal_catch+0x97 [d:\data\projects\emacs-24.3\src\eval.c @
>>>> 1060]
>>>> temacs!command_loop+0x69 [d:\data\projects\emacs-24.3\src\keyboard.c @
>>>> 1146]
>>>> temacs!recursive_edit_1+0x71
>>>> [d:\data\projects\emacs-24.3\src\keyboard.c @ 779]
>>>> temacs!Frecursive_edit+0x101
>>>> [d:\data\projects\emacs-24.3\src\keyboard.c @ 844]
>>>> temacs!main+0xae7 [d:\data\projects\emacs-24.3\src\emacs.c @ 1530]
>>>> temacs!__tmainCRTStartup+0x1bf
>>>> [f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c @ 555]
>>>> temacs!mainCRTStartup+0xf
>>>> [f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c @ 371]
>>>> temacs!_start+0x62 [d:\data\projects\emacs-24.3\src\unexw32.c @ 134]
>>>>
>>>>
>>>> When I stepped out Fgarbage_collect, the error occurred just after this
>>>> gc at here in eval_sub:
>>>>
>>>> if (!CONSP (fun))
>>>> xsignal1 (Qinvalid_function, original_fun);
>>>>
>>>> I also tried removing most of loadup.el, and temacs can execute only
>>>> the first few lines, and even an additional `(+ 1 1)' caused temacs to exit
>>>> with the "DEAD" message. As I previously reported, I guess that the first
>>>> garbage collection cycle does not mark any read-in form, thus all of them
>>>> are collected (and their car set to Vdead).
>>>>
>>>>
>>>> 2013/3/15 Eli Zaretskii <eliz <at> gnu.org>
>>>>
>>>>>  > From: Fabrice Popineau <fabrice.popineau <at> gmail.com>
>>>>> > Date: Thu, 14 Mar 2013 20:28:45 +0100
>>>>> > Cc: 李丁 <iamliding <at> gmail.com>, 13939 <13939 <at> debbugs.gnu.org>
>>>>> >
>>>>> > I tried importing this change in editfns.c but it doesn't change
>>>>> anything.
>>>>> >
>>>>> > If I run only temacs.exe without any arguments, I get a very quick
>>>>> > backtrace:
>>>>> >
>>>>> > C:\>"C:\Source\XEmTeX\emacs\emacs-24.3\src/obj-spd/AMD64/temacs.exe"
>>>>> > Loading loadup.el (source)...
>>>>> > Invalid function: "DEAD"
>>>>> >
>>>>> > > temacs.exe!eval_sub(__int64 form) Line 2195 C
>>>>> >   temacs.exe!readevalloop(__int64 readcharfun, _iobuf * stream,
>>>>> __int64
>>>>> > sourcename, char printflag, __int64 unibyte, __int64 readfun, __int64
>>>>> > start, __int64 end) Line 1845 C
>>>>>
>>>>> Thanks.
>>>>>
>>>>> 李丁, do you also compile Emacs 24.3 as a 64-bit executable?  Or do
>>>>> you build it as a 32-bit executable?
>>>>>
>>>>
>>>>
>>>
>>
>

[Message part 2 (text/html, inline)]

Previous Next

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