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:
ntdll.dll!7c928fea()
ntdll.dll!7c91104b()
msvcr71d.dll!_lock_file(void * pf=0x77c2fce0) Line 236 C
> msvcr71d.dll!fread(void * buffer=0x0082e268, unsigned int
size=0x00000001, unsigned int count=0x00000004, _iobuf *
stream=0x77c2fce0) Line 75 + 0x9 C
libpng13d.dll!png_default_read_data(png_struct_def *
png_ptr=0x20844540, unsigned char * data=0x0082e268, unsigned int
length=0x00000004) Line 55 + 0x19 C
libpng13d.dll!png_read_data(png_struct_def * png_ptr=0x20844540,
unsigned char * data=0x0082e268, unsigned int length=0x00000004) Line
31 + 0x14 C
libpng13d.dll!png_read_info(png_struct_def * png_ptr=0x20844540,
png_info_struct * info_ptr=0x208483e0) Line 402 + 0xf C
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 >= (void *)_iob) && (pf <= (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.)
--
/L/e/k/t/u
_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
