Re: Problem with library images on Windows (again)

[Juanma Barranquero <lekktu@gmail.com>]

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