Re: [Mingw-users] Update: application failed to initialize, bad jmp to malloc?

[Brian Dessent <brian@xxxxxxxxxxx>]

David Daeschler wrote:

> (gdb) bt
> #0  0x003e14a0 in malloc ()
> #1  0x003e111c in DllMainCRTStartup@12 (hDll=0x3e0000, dwReason=1,
>     lpReserved=0x22fd30) at dllcrt1.c:56
> #2  0x7c9011a7 in ntdll!LdrSetAppCompatDllRedirectionCallback ()
>    from C:\WINDOWS\system32\ntdll.dll
> #3  0x003e0000 in ?? ()
> #4  0x00000001 in ?? ()
> #5  0x003e10c0 in __dll_exit () at dllcrt1.c:149
> #6  0x00000000 in ?? ()

There are a couple of things that seem worrisome about this backtrace. 
One, why is dllcrt1.o (as opposed to dllcrt2.o) ever being used?  That
sounds wrong.  How and why is that being pulled into the link?  And what
module's DllMain is this, i.e. what DLL is this?

Two, why is a DLL trying to load at base address 0x3e0000?  That seems
wrong too, because the default base address for the main module is
0x400000, and the default base for DLLs is 0x1000000, and I would never
expect anything to load *below* 0x400000 let alone a mere 20000 bytes
below it.  It almost seems like a DLL startup module got linked in as
the entry point of the main module (exe).

> Disassembly of 0x003e14a0 (frame 0):
> 
> (gdb) disas 0x3e14a0
> Dump of assembler code for function malloc:
> 0x003e14a0 <malloc+0>:  jmp    *0x90c0609c
> 
> There's that indirect jump..
> 
> > Again, this is not a jump to 0x90c0609c, it's an indirect jump.  What
> > does "p *0x90c0609c" say?
> 
> (gdb) print *0x90c0609c
> Cannot access memory at address 0x90c0609c

Right, so this 0x3e14a0 is probably uninitialized.

> Here is the disassembly, it looks like a direct call, it doesn't look
> like it even tries to call msvcrt!malloc in frame 1, it just calls that
> thunk at 0x3e14a0:

You're right, I misinterpreted what you said in the previous email.  The
DllMainCRTStartup is directly calling this malloc thunk at 0x3e14a0
which appears to be junk.

I'm not really sure where to go from here other than trying to figure
out why this code is calling the stub at 0x3e14a0 instead of the stub at
0x40c780.

Some debugging tools that might help are -Wl,-verbose and
Wl,--enable-extra-pe-debug and -Wl,-Map,filename.

Brian

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
MinGW-users mailing list
MinGW-users@xxxxxxxxxxxxxxxxxxxxx

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users