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 李丁 > Though there are some minor errors (easy to fix), the latest trunk > compiles fine with msvc. > > 2013/3/15 Fabrice Popineau > >> 李丁: 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 李丁 >> >>> 李丁, 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 >>> >>>> > From: Fabrice Popineau >>>> > Date: Thu, 14 Mar 2013 20:28:45 +0100 >>>> > Cc: 李丁 , 13939 <13939@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? >>>> >>> >>> >> >