From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Juanma Barranquero Newsgroups: gmane.emacs.devel Subject: Problem with library images on Windows (again) Date: Wed, 18 May 2005 17:53:05 +0200 Message-ID: Reply-To: Juanma Barranquero NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: sea.gmane.org 1116442453 9557 80.91.229.2 (18 May 2005 18:54:13 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 18 May 2005 18:54:13 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed May 18 20:54:12 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1DYTee-0004Ra-Fr for ged-emacs-devel@m.gmane.org; Wed, 18 May 2005 20:52:28 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DYTh8-000079-GY for ged-emacs-devel@m.gmane.org; Wed, 18 May 2005 14:55:02 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DYRPn-0004pF-8X for emacs-devel@gnu.org; Wed, 18 May 2005 12:29:01 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DYRPm-0004om-Dk for emacs-devel@gnu.org; Wed, 18 May 2005 12:28:58 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DYRFC-0008Mz-E0 for emacs-devel@gnu.org; Wed, 18 May 2005 12:18:02 -0400 Original-Received: from [64.233.184.193] (helo=wproxy.gmail.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1DYQz5-0007tr-Hl for emacs-devel@gnu.org; Wed, 18 May 2005 12:01:23 -0400 Original-Received: by wproxy.gmail.com with SMTP id 50so277882wri for ; Wed, 18 May 2005 08:53:05 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=MDg0E+CwyJo8LeTMV8vppQoINodedxcNZkl7PlSq2SQXAisiMoGRCYxqaqN+b5uxjF1jVaEPSbdj+C2SdR7ILGaNSI65Fln7Ez2jGxS7x4RmGajZ5uZSOtbaOu7n0vWeHHlHLJXH9beGKP+Yj5WMq5CUwkmoORDVjM5CeXdTDQE= Original-Received: by 10.54.15.15 with SMTP id 15mr391189wro; Wed, 18 May 2005 08:53:05 -0700 (PDT) Original-Received: by 10.54.82.6 with HTTP; Wed, 18 May 2005 08:53:05 -0700 (PDT) Original-To: emacs-devel@gnu.org Content-Disposition: inline X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:37281 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:37281 For some time now, TIFF images do crash optimized MSVC builds of Emacs when using the MinGW-supplied TIFF library. The crash happens in image_spec_value(), but it all boils down to the fact that on lookup_image(), after img->load_failed_p =3D img->type->load (f, img) =3D=3D 0; the value of the argument "spec" cannot be trusted. This is easy to prove; = with static LispObject spec_backup; spec_backup =3D spec; img->load_failed_p =3D img->type->load (f, img) =3D=3D 0; spec =3D spec_backup; spec_backup =3D Qnil; everything works as expected. Now, when this happened before (with the local variable img) someone said that the MinGW libraries were not respecting calling conventions, but I'm not sure. Calling conventions for MSVC say that you cannot trust EAX, EBX, ECX, EDX, ESI, or EDI registers after a subroutine call, and AFAICS, the problem is that on optimized builds VC is expecting spec to still be cached in a register. So, I can apply the attached patch and at least stop Emacs from crashing on Windows, but I certainly would appreciate a more insightful analysis from the "people in the know" wrt image support and/or Windows. --=20 /L/e/k/t/u Index: src/image.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /cvsroot/emacs/emacs/src/image.c,v retrieving revision 1.23 diff -u -2 -r1.23 image.c --- src/image.c=0910 May 2005 09:16:46 -0000=091.23 +++ src/image.c=0918 May 2005 15:38:22 -0000 @@ -1663,9 +1663,20 @@ extern Lisp_Object Qpostscript; =20 +#ifdef _MSC_VER + static Lisp_Object spec_backup; + spec_backup =3D spec; +#endif + BLOCK_INPUT; img =3D make_image (spec, hash); cache_image (f, img); + img->load_failed_p =3D img->type->load (f, img) =3D=3D 0; =20 +#ifdef _MSC_VER + spec =3D spec_backup; + spec_backup =3D Qnil; +#endif + /* If we can't load the image, and we don't have a width and =09 height, use some arbitrary width and height so that we can