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: Re: Problem with library images on Windows (again) Date: Mon, 6 Jun 2005 13:26:33 +0200 Message-ID: References: <853brzh9o6.fsf@lola.goethe.zz> 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 1118057184 24016 80.91.229.2 (6 Jun 2005 11:26:24 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 6 Jun 2005 11:26:24 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jun 06 13:26:18 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1DfFjm-0000kx-6o for ged-emacs-devel@m.gmane.org; Mon, 06 Jun 2005 13:25:46 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DfFq4-0003LZ-LR for ged-emacs-devel@m.gmane.org; Mon, 06 Jun 2005 07:32:16 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DfFpf-0003HH-Rj for emacs-devel@gnu.org; Mon, 06 Jun 2005 07:31:52 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DfFpZ-0003Es-QF for emacs-devel@gnu.org; Mon, 06 Jun 2005 07:31:46 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DfFpZ-0003EM-AQ for emacs-devel@gnu.org; Mon, 06 Jun 2005 07:31:45 -0400 Original-Received: from [64.233.182.195] (helo=nproxy.gmail.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1DfFnf-0003m2-1G for emacs-devel@gnu.org; Mon, 06 Jun 2005 07:29:47 -0400 Original-Received: by nproxy.gmail.com with SMTP id i2so50999nfe for ; Mon, 06 Jun 2005 04:26:33 -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:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=kQvI/N5o6sAOt2c/qPe0F5u5RIyzfuABs7svRdz4D1Rd7D862hT2RBH/9WmUJKbHm9jYnfghnB+Fc344562KPuRpp9qNxgx1LNv7jX9i2ONqiz5cOl76Lc0w0R81rqOJKuhiwgTtXqiEGChG8LscEY+difyrca2EgazVD++9cLk= Original-Received: by 10.48.240.5 with SMTP id n5mr52032nfh; Mon, 06 Jun 2005 04:26:33 -0700 (PDT) Original-Received: by 10.48.250.5 with HTTP; Mon, 6 Jun 2005 04:26:33 -0700 (PDT) Original-To: emacs-devel@gnu.org In-Reply-To: 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:38156 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:38156 Funnier and funnier. I've been able to compile an MSVC debug release of libpng13; with it, both the MSVC and the GCC builds of Emacs crash. It happens inside msvcr71d.dll; (part of) the stack is: =09ntdll.dll!7c928fea() =09 =09ntdll.dll!7c91104b() =09 =09msvcr71d.dll!_lock_file(void * pf=3D0x77c2fce0) Line 236=09C >=09msvcr71d.dll!fread(void * buffer=3D0x0082e268, unsigned int size=3D0x00000001, unsigned int count=3D0x00000004, _iobuf * stream=3D0x77c2fce0) Line 75 + 0x9=09C =09libpng13d.dll!png_default_read_data(png_struct_def * png_ptr=3D0x20844540, unsigned char * data=3D0x0082e268, unsigned int length=3D0x00000004) Line 55 + 0x19=09C =09libpng13d.dll!png_read_data(png_struct_def * png_ptr=3D0x20844540, unsigned char * data=3D0x0082e268, unsigned int length=3D0x00000004) Line 31 + 0x14=09C =09libpng13d.dll!png_read_info(png_struct_def * png_ptr=3D0x20844540, png_info_struct * info_ptr=3D0x208483e0) Line 402 + 0xf=09C The crash is on the _lock_file() call inside the msvcr71 implementation of fread(); the relevant code is: void __cdecl _lock_file ( void *pf ) { /* * The way the FILE (pointed to by pf) is locked depends on whether * it is part of _iob[] or not */ if ( (pf >=3D (void *)_iob) && (pf <=3D (void *)(&_iob[_IOB_ENTRIES= -1])) ) /* * FILE lies in _iob[] so the lock lies in _locktable[]. */ _lock( _STREAM_LOCKS + (int)((FILE *)pf - _iob) ); else /* * Not part of _iob[]. Therefore, *pf is a _FILEX and the * lock field of the struct is an initialized critical * section. */ EnterCriticalSection( &(((_FILEX *)pf)->lock) ); } The code decides that the FILE * is not part of _iob[] and calls EnterCriticalSection, which gets an access violation writing on 0x00000010. (I suppose I could get around the issue by writing read functions for libpng and jpeg and bypassing the standard code altogether; still, it'd be great to understand what's happening.) --=20 /L/e/k/t/u