I get this stack overflow exception while trying to run the Watchtower Library Setup on FreeBSD 6.1. I have extracted some debug lines which I think is relevant. Please ask if you need more information.
0009:Call ntdll.LdrFindResource_U(00400000,0034ecf0,00000003,0034ec8c) ret=9c266b12 0009:trace:resource:LdrFindResource_U module 0x400000 type #0006 name #0901 lang 0414 level 3 0009:trace:resource:find_entry_by_id root 0x40b000 dir 0x40b000 id 0006 ret 0x40b090 0009:trace:resource:find_entry_by_id root 0x40b000 dir 0x40b090 id 0901 ret 0x40bb98 0009:trace:resource:find_entry_by_id root 0x40b000 dir 0x40bb98 id 0414 ret 0x40d1c8 0009:Ret ntdll.LdrFindResource_U() retval=00000000 ret=9c266b12 0009:Ret kernel32.FindResourceExA() retval=0040d1c8 ret=00405ac0 0009:Call kernel32.LoadResource(00400000,0040d1c8) ret=00405ae4 0009:trace:resource:LoadResource 0x400000 0x40d1c8 0009:Call ntdll.LdrAccessResource(00400000,0040d1c8,0034ed48,00000000) ret=9c26807b 0009:trace:resource:access_resource access resource 0009:trace:resource:access_resource *ptr=0x4219d0 0009:Ret ntdll.LdrAccessResource() retval=00000000 ret=9c26807b 0009:Ret kernel32.LoadResource() retval=004219d0 ret=00405ae4 0009:Call ntdll.NtCreateEvent(0034e634,001f0003,0034e8dc,00000001,00000000) ret=9c22d14a 0009:Ret ntdll.NtCreateEvent() retval=00000000 ret=9c22d14a wine: Unhandled stack overflow at address 0x405b1d (thread 0009), starting debugger...
(There was thread two (to 000b and back to 0009) context switches in between, which I filtered out)
I single stepped the last instructions before the crash and found that it crashed while trying to write to the memory pointed to by the returned pointer from LoadResource. It loaded the address with some offset into register %esi and crashed at an andw instruction:
First chance exception: stack overflow in 32-bit code (0x00405b1d). file_set_error: Bad address file_set_error: Bad address Register dump: CS:0033 SS:003b DS:003b ES:003b FS:1007 GS:001b EIP:00405b1d ESP:0035ee08 EBP:0035f224 EFLAGS:00010346( - 00 RITZP1) EAX:0000006c EBX:00000000 ECX:00000003 EDX:00000000 ESI:00421b5e EDI:00421a86 Stack dump: 0x0035ee08: 9c266cc0 0035f954 0035f230 00000000 0x0035ee18: 00401df3 00009003 0035f224 0035f958 0x0035ee28: 0035f954 00000000 9c086a19 9c0da2c0 0x0035ee38: 0035ee78 9c092b72 00120020 00000001 0x0035ee48: 9c086957 00000000 00000000 0035ee34 0x0035ee58: 005ca2c0 9c08b791 00167e10 00000000 0200: sel=1007 base=00110000 limit=00001fff 32-bit rw- Backtrace: =>1 0x00405b1d in setup (+0x5b1d) (0x00405b1d) 0x00405b1d: andw $0,0x0(%esi)
Wine-dbg>info share Module Address Debug info Name (3 modules) PE 0x9c070000-9c0dd000 --none-- ntdll PE 0x9c210000-9c2f1000 --none-- kernel32 PE 0x00400000-0042b000 Export setup
Can a win32 program expect that it has write access to the memory pointed to by the return value of LoadResource with module 0x00400000? Should LoadResource in some cases copy the memory and return a writeable copy of the resource?
Jan-Espen Pettersen
On Tue, 20 Jun 2006 12:49:25 +0200, Jan-Espen Pettersen wrote:
Can a win32 program expect that it has write access to the memory pointed to by the return value of LoadResource with module 0x00400000? Should LoadResource in some cases copy the memory and return a writeable copy of the resource?
The SEH handling code should catch this case and un-protect the resource section. At least it does for InstallShield ... I'm not sure why it's not working here.
thanks -mike
-
Jan-Espen Pettersen -
Mike Hearn