Greetings, I've been (unsuccessfully) attempting to run a children's program through wine for some time. I've been trying successive releases since about may, without luck. The program appears to be extremely simple, just some painting apps for toddlers, but each run fails with what looks like a heap issue. The program is by Creative Wonders called Sesame Street Toddlers Deluxe Art workshop. I'm attaching the output that winedbg gives, but would appreciate any feedback. I'm fairly comfortable with winedbg, so I can provide additional info about the crash if needed. Mostly I'm just curious if this is an issue with Wine's heap implementation, or if it is more likely just a poorly built application that I should give up on.
winedbg output: 21:23:34 slight - cdrom>wine: Unhandled exception (thread 0014), starting debugger... WineDbg starting on pid 0xf Unhandled exception: page fault on read access to 0x41ea6f30 in 32-bit code (0x4019fa56). In 32 bit mode. Register dump: CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:0087 EIP:4019fa56 ESP:420254d0 EBP:420254f4 EFLAGS:00210287( - 00 RISP1C) EAX:000090c8 EBX:401d8e28 ECX:41eb0000 EDX:00110000 ESI:41ea6f30 EDI:41dd6f28 Stack dump: 0x420254d0: 00001000 00000004 40075bac 000090c8 0x420254e0: 41dd6f38 4019f9fb 401d8e28 41dc6f20 0x420254f0: 00010000 42025538 4019dcd9 41da0000 0x42025500: 41dd6f28 000d0008 00000000 401bd230 0x42025510: 00000802 00000000 00000000 41dc6f28 0x42025520: 00000000 40370000 41da0000 4052ca5c Backtrace: =>1 0x4019fa56 in ntdll (+0x1fa56) (0x420254f4) 2 0x4019dcd9 RtlAllocateHeap+0x1e9 in ntdll (0x42025538) 3 0x404ccd4d HeapAlloc+0x2d in kernel32 (0x42025550) 4 0x404cabbc GLOBAL_Alloc+0x7c in kernel32 (0x42025588) 5 0x404cad06 GlobalAlloc16+0x46 in kernel32 (0x420255a8) 6 0x4051a387 K32WOWGlobalAlloc16+0x27 in kernel32 (0x420255bc) 7 0x404d0a94 DllMain+0x94 in kernel32 (0x420255d8) 8 0x4051c378 __wine_spec_dll_entry+0x38 in kernel32 (0x420255f8) 9 0x401a1292 call_dll_entry_point+0x12 in ntdll (0x42025610) 10 0x401a396a in ntdll (+0x2396a) (0x42025698) 11 0x401a165e MODULE_DllThreadAttach+0xae in ntdll (0x420256c0) 12 0x4050e202 GetCurrentThreadId+0x136 in kernel32 (0x42025798) 13 0x401c21a2 NtCurrentTeb+0x1be in ntdll (0x42025fec) 14 0x40106b8a __clone+0x5a in libc.so.6 (0x00000000) 0x4019fa56: testb $0x1,0x0(%esi) Modules: Module Address Debug info Name (77 modules) ELF 0x40000000-40017000 Deferred ld-linux.so.2 ELF 0x40032000-4004c000 Deferred libwine.so.1 ELF 0x4004d000-4016a000 Export libc.so.6 ELF 0x4016a000-4016e000 Deferred libdl.so.2 ELF 0x4016e000-401e8000 Export ntdll<elf> -PE 0x40180000-401e8000 \ ntdll ELF 0x40203000-402f8000 Deferred libwine_unicode.so.1 ELF 0x402f8000-4031b000 Deferred libm.so.6 ELF 0x40336000-4033f000 Deferred libnss_compat.so.2 ELF 0x4033f000-40355000 Deferred libnsl.so.1 ELF 0x40355000-4035f000 Deferred libnss_nis.so.2 ELF 0x4035f000-40369000 Deferred libnss_files.so.2 ELF 0x40482000-4058c000 Export kernel32<elf> -PE 0x404a0000-4058c000 \ kernel32 ELF 0x405c2000-405d7000 Deferred winevdm<elf> -PE 0x405d0000-405d7000 \ winevdm ELF 0x406e0000-40815000 Deferred user32<elf> -PE 0x40700000-40815000 \ user32 ELF 0x40815000-408a5000 Deferred gdi32<elf> -PE 0x40830000-408a5000 \ gdi32 ELF 0x408a5000-408e3000 Deferred advapi32<elf> -PE 0x408b0000-408e3000 \ advapi32 ELF 0x408fe000-40968000 Deferred libfreetype.so.6 ELF 0x40968000-40979000 Deferred libz.so.1 ELF 0x40979000-409fd000 Deferred winex11.drv<elf> -PE 0x40990000-409fd000 \ winex11.drv ELF 0x40a18000-40a20000 Deferred libsm.so.6 ELF 0x40a20000-40a38000 Deferred libice.so.6 ELF 0x40a38000-40a3e000 Deferred libxxf86dga.so.1 ELF 0x40a3e000-40a43000 Deferred libxxf86vm.so.1 ELF 0x40a43000-40a51000 Deferred libxext.so.6 ELF 0x40a51000-40b1b000 Deferred libx11.so.6 ELF 0x40b1b000-40b93000 Deferred libgl.so.1 ELF 0x40b93000-412e4000 Deferred libglcore.so.1 ELF 0x412e4000-412e6000 Deferred libnvidia-tls.so.1 ELF 0x41399000-413a1000 Deferred libxrender.so.1 ELF 0x413a1000-413a4000 Deferred libxrandr.so.2 ELF 0x413a4000-413a7000 Deferred xlcdef.so.2 ELF 0x413a7000-413c5000 Deferred ximcp.so.2 ELF 0x413c5000-413e2000 Deferred imm32<elf> -PE 0x413d0000-413e2000 \ imm32 ELF 0x413e5000-413e9000 Deferred iso8859-1.so ELF 0x41404000-4140d000 Deferred libxcursor.so.1 ELF 0x41451000-414b4000 Deferred winedos<elf> -PE 0x41460000-414b4000 \ winedos ELF 0x414b4000-41538000 Deferred winmm<elf> -PE 0x414c0000-41538000 \ winmm ELF 0x41538000-4157f000 Deferred wineoss.drv<elf> -PE 0x41550000-4157f000 \ wineoss.drv ELF 0x4157f000-41597000 Deferred msacm.drv<elf> -PE 0x41590000-41597000 \ msacm.drv ELF 0x41597000-415ba000 Deferred msacm32<elf> -PE 0x415a0000-415ba000 \ msacm32 ELF 0x416d0000-416e5000 Deferred midimap<elf> -PE 0x416e0000-416e5000 \ midimap ELF 0x41827000-418be000 Deferred comdlg32<elf> -PE 0x41830000-418be000 \ comdlg32 ELF 0x418be000-41989000 Deferred shell32<elf> -PE 0x418d0000-41989000 \ shell32 ELF 0x41989000-419e4000 Deferred shlwapi<elf> -PE 0x419a0000-419e4000 \ shlwapi ELF 0x419e4000-41a78000 Deferred ole32<elf> -PE 0x41a00000-41a78000 \ ole32 ELF 0x41a78000-41abe000 Deferred rpcrt4<elf> -PE 0x41a90000-41abe000 \ rpcrt4 ELF 0x41abe000-41adc000 Deferred iphlpapi<elf> -PE 0x41ad0000-41adc000 \ iphlpapi ELF 0x41adc000-41bad000 Deferred comctl32<elf> -PE 0x41af0000-41bad000 \ comctl32 ELF 0x41bad000-41bd8000 Deferred winspool.drv<elf> -PE 0x41bc0000-41bd8000 \ winspool.drv ELF 0x41c4b000-41c67000 Deferred libcups.so.2 ELF 0x41c67000-41c98000 Deferred libssl.so.0 ELF 0x41c98000-41d97000 Deferred libcrypto.so.0 ELF 0x41eb0000-41ee3000 Deferred uxtheme<elf> -PE 0x41ec0000-41ee3000 \ uxtheme ELF 0x7bf00000-7bf07000 Deferred <wine-loader> Threads: process tid prio (all id:s are in hex) 0000000f (D) E:\winevdm.exe 00000014 15 <== 00000011 0 00000010 0 WineDbg terminated on pid 0xf
Much obliged,
Randall Walls
Randall Walls wrote:
Mostly I'm just curious if this is an issue with Wine's heap implementation, or if it is more likely just a poorly built application that I should give up on.
No and no. It's likely to be an issue with some other function in Wine that is corrupting the heap. The best way to deal with the problem is to open a bug in bugzilla, and attach a +relay,+olerelay trace.
Mike
Trace is 138 MB and then some. Should I attach the entire trace, or can I pare it down a bit to only the important stuff? I'm not sure exactly what to look for in this scenario.
Randall Walls
Mike McCormack wrote:
Randall Walls wrote:
Mostly I'm just curious if this is an issue with Wine's heap implementation, or if it is more likely just a poorly built application that I should give up on.
No and no. It's likely to be an issue with some other function in Wine that is corrupting the heap. The best way to deal with the problem is to open a bug in bugzilla, and attach a +relay,+olerelay trace.
Mike
Randall Walls wrote:
Trace is 138 MB and then some. Should I attach the entire trace, or can I pare it down a bit to only the important stuff? I'm not sure exactly what to look for in this scenario.
You can post the trace on a website and add a link to bugzilla if you need to.
If you want to try to debug the problem yourself, search backwards in the trace from the point of the crash and look for HeapAlloc and HeapFree calls that are using a similar address, give or take 0x100 hex. To do that, I use "less" and the first 6 digits in the address like: ?401234
You can also try a +relay,+heap trace. That might give you a heap error a little earlier and help narrow down the problem.
Mike
On Sun, 9 Oct 2005, Mike McCormack wrote:
Randall Walls wrote:
Trace is 138 MB and then some. Should I attach the entire trace, or can I pare it down a bit to only the important stuff? I'm not sure exactly what to look for in this scenario.
You can post the trace on a website and add a link to bugzilla if you need to.
Compress the trace with either 'bzip2 -9' or 'gzip -9' before putting it on the web site. That should bring it to well under 10MB which makes it more manageable.
-
Francois Gouget -
Mike McCormack -
Randall Walls