From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Fabrice Popineau Newsgroups: gmane.emacs.bugs Subject: 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-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7b6228f8cb7a3c04d7fbf022 X-Trace: ger.gmane.org 1363377057 10700 80.91.229.3 (15 Mar 2013 19:50:57 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 15 Mar 2013 19:50:57 +0000 (UTC) Cc: 13939 <13939@debbugs.gnu.org> To: =?UTF-8?Q?=E6=9D=8E=E4=B8=81?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Mar 15 20:51:20 2013 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UGaet-0005Pt-MH for geb-bug-gnu-emacs@m.gmane.org; Fri, 15 Mar 2013 20:51:20 +0100 Original-Received: from localhost ([::1]:47598 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UGaeW-0005Cd-Qz for geb-bug-gnu-emacs@m.gmane.org; Fri, 15 Mar 2013 15:50:56 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:58743) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UGaeP-0005BD-TE for bug-gnu-emacs@gnu.org; Fri, 15 Mar 2013 15:50:53 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UGaeL-0002Sx-0i for bug-gnu-emacs@gnu.org; Fri, 15 Mar 2013 15:50:49 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:52678) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UGaeK-0002St-Tr for bug-gnu-emacs@gnu.org; Fri, 15 Mar 2013 15:50:44 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1UGafa-00060p-8U for bug-gnu-emacs@gnu.org; Fri, 15 Mar 2013 15:52:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Fabrice Popineau Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 15 Mar 2013 19:52:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13939 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 13939-submit@debbugs.gnu.org id=B13939.136337707223044 (code B ref 13939); Fri, 15 Mar 2013 19:52:02 +0000 Original-Received: (at 13939) by debbugs.gnu.org; 15 Mar 2013 19:51:12 +0000 Original-Received: from localhost ([127.0.0.1]:56787 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UGaek-0005za-Ht for submit@debbugs.gnu.org; Fri, 15 Mar 2013 15:51:11 -0400 Original-Received: from mail-ea0-f172.google.com ([209.85.215.172]:46040) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UGaeh-0005z9-OP for 13939@debbugs.gnu.org; Fri, 15 Mar 2013 15:51:09 -0400 Original-Received: by mail-ea0-f172.google.com with SMTP id d10so1682056eaj.17 for <13939@debbugs.gnu.org>; Fri, 15 Mar 2013 12:49:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=V3dThxuy2TcT5Jc81w3o6DkjM5uBRRyT5HXfpOIHJRE=; b=FnOCfbzfSsuc/i4A1P/M9D2k/lGH+rckZ6+aBo9C6nYASKNIdwNHPJE18W6oL4bbI2 OZiv/dWc52g6/iZAni5chLq8BCOeiure7Jm6ADRU3M5r2BA3WJeL5bkawr4yKBfwNwDK XekrWbSuLk87qa8cWLLjE8Ntg/SJBC9f/MjdnJJvGP6BsNr1i+wY0avtO6QP7v3yG3Uu 3gInI8kLfNMvG97hctZ0550QzOjUCqm7sIZD3hydRpjzJCIYjVcowpnATPIquUJR/LuY iFcUNhVYJW3un2GFaQs34lQdw2TtdBz2IsZHFJKjRF2x4Y6lLG727yI2FrJcFCeFhfB5 mJ1A== X-Received: by 10.14.219.129 with SMTP id m1mr21380981eep.16.1363376983457; Fri, 15 Mar 2013 12:49:43 -0700 (PDT) Original-Received: by 10.14.129.2 with HTTP; Fri, 15 Mar 2013 12:49:22 -0700 (PDT) In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:72559 Archived-At: --047d7b6228f8cb7a3c04d7fbf022 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thinking about it, another option is to use GC_MARK_STACK =3D 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 > 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 =E6=9D=8E=E4=B8=81 > >> Though there are some minor errors (easy to fix), the latest trunk >> compiles fine with msvc. >> >> 2013/3/15 Fabrice Popineau >> >>> =E6=9D=8E=E4=B8=81: could you try to compile the trunk with msvc and c= onfirm 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 =E6=9D=8E=E4=B8=81 >>> >>>> =E6=9D=8E=E4=B8=81, do you also compile Emacs 24.3 as a 64-bit executa= ble? 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 @ 509= 4] >>>> 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 thi= s >>>> 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 fi= rst >>>> garbage collection cycle does not mark any read-in form, thus all of t= hem >>>> 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: =E6=9D=8E=E4=B8=81 , 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, __int= 64 >>>>> > start, __int64 end) Line 1845 C >>>>> >>>>> Thanks. >>>>> >>>>> =E6=9D=8E=E4=B8=81, do you also compile Emacs 24.3 as a 64-bit execut= able? Or do >>>>> you build it as a 32-bit executable? >>>>> >>>> >>>> >>> >> > --047d7b6228f8cb7a3c04d7fbf022 Content-Type: text/html; charset=Big5 Content-Transfer-Encoding: quoted-printable
Thinking about it, another option is to use GC_MARK_STACK = =3D 0 . This way, people can stick to 24.3 .

I'm a b= it afraid of the unstable status of the trunk (strange things happens somet= imes, 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 fr= ames to the wrong dimensions).

Fabrice 


2013/3/15 Fab= rice Popineau <fabrice.popineau@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 c= hanges happened in this area.
Nothing very obvious anyway.

It is very unluc= ky, 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 =A7= =F5=A4B <iamliding@gmail.com>
Though there are some minor errors (easy to fix), the latest trunk comp= iles fine with msvc.

2013/3/15 Fabrice Popineau <fabrice.popineau@gmail.com>
=A7=F5=A4B:  could you tr= y 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 t= hings up.

Fabrice


2013/3/15 =A7=F5=A4B <iamliding@gmail.com>
=A7=F5=A4B, do = you also compile Emacs 24.3 as a 64-bit executable?  Or do
you buil= d it as a 32-bit executable?
=
I compiled Emacs as a 32-bit exe= cutable. 

If I run only temacs.exe without any= arguments, I get a very quick backtrace:

I als= o traced the execution of `temacs -batch -l loadup dump' with windbg, a= nd got a similar stack trace as Fabrice (I breakpointed Fgarbage_collect):<= /div>

temacs!Fgarbage_collect [d:\data\projects\emacs-24.3\src\alloc.c= @ 5094]
temacs!maybe_gc+0x3e [d:\data\projects\emacs-24.3\src\lis= p.h @ 3717]
temacs!eval_sub+0xda [d:\data\projects\emacs-24.= 3\src\eval.c @ 2042]
temacs!readevalloop+0x600 [d:\d= ata\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\pro= jects\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\pro= jects\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\s= rc\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\s= rc\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))
<= div class=3D"gmail_extra">
xsignal1 (Qinvalid_functi= on, 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)' cau= sed temacs to exit with the "DEAD" message. As I previously repor= ted, 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@gnu.org>
> From: Fabrice Popineau <fabrice.popineau@gmail.com>
> Date: Thu, 14 Mar 2013 20:28:45 +0100
> Cc: =A7=F5=A4B <iamliding@gmail.com>, 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/temac= s.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<= br> > start, __int64 end) Line 1845 C

Thanks.

=A7=F5=A4B, do you also compile Emacs 24.3 as a 64-bit executable?  Or= do
you build it as a 32-bit executable?





--047d7b6228f8cb7a3c04d7fbf022--