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 = img->type->load (f, img) == 0;
the value of the argument "spec" cannot be trusted. This is easy to prove; with
static LispObject spec_backup;
spec_backup = spec;
img->load_failed_p = img->type->load (f, img) == 0;
spec = spec_backup;
spec_backup = 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.
--
/L/e/k/t/u
Index: src/image.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/image.c,v
retrieving revision 1.23
diff -u -2 -r1.23 image.c
--- src/image.c 10 May 2005 09:16:46 -0000 1.23
+++ src/image.c 18 May 2005 15:38:22 -0000
@@ -1663,9 +1663,20 @@
extern Lisp_Object Qpostscript;
+#ifdef _MSC_VER
+ static Lisp_Object spec_backup;
+ spec_backup = spec;
+#endif
+
BLOCK_INPUT;
img = make_image (spec, hash);
cache_image (f, img);
+
img->load_failed_p = img->type->load (f, img) == 0;
+#ifdef _MSC_VER
+ spec = spec_backup;
+ spec_backup = Qnil;
+#endif
+
/* If we can't load the image, and we don't have a width and
height, use some arbitrary width and height so that we can
_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
