This is a email that serves multiple purposes, and you all may find intersting.
Wine, as we all know, is able to load and run native programs that the real McCoy can't run, but these programs are also close to 20 years old, so nobody really cares anyways.
That's right, programs for Windows 2.0
I recently downloaded a full distrib (bin+src) of one such program. It is a xeyes clone with color. Orignally, it worked in Wine, showing a large window with a pair of eyes that followed the cursor, with a blue-green background (the part where the "eyes" aren't drawn in the window)
This program was running in a window, and this appears to be broken, as under the real McCoy, version 3.1 (*gasp!*), it runs minimized, cannot be restored, and modifies it's own icon to preform the eyes deal (with a grey "background", as described above).
I went to make sure that Wine wasn't broken, so I re-exec'd the binary, but only to get this:
First chance exception: page fault on write access to 0x000f0400 in 32-bit code (0xb7df2e97). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:003b GS:0033 EIP:b7df2e97 ESP:7fbff570 EBP:7fbff5b0 EFLAGS:00010246( - 00 -RIZP1) EAX:00000000 EBX:7eee7ff0 ECX:00000023 EDX:00000000 ESI:000f0400 EDI:000f0400 Stack dump: 0x7fbff570: 00000000 7eed0e49 000f0400 00000000 0x7fbff580: 0000008c 7ffd50f0 00010000 7ffb190b 0x7fbff590: 7ffdcc24 7fc94988 00000000 0000ffff 0x7fbff5a0: 0000f30f 7eee7ff0 00000000 00000001 0x7fbff5b0: 7fbff5bc 7eed158d 7eee7ff0 7fbff5dc 0x7fbff5c0: 7eee51c4 7eec0000 00000001 00000000 Backtrace: =>1 0xb7df2e97 memset+0x37 in libc.so.6 (0xb7df2e97) 2 0x7eed158d DllMain+0x22 in winedos (0x7eed158d) 3 0x7eee51c4 in winedos (+0x251c4) (0x7eee51c4) 4 0x7ffb0a2d call_dll_entry_point+0x15 in ntdll (0x7ffb0a2d) 5 0x7ffb11f2 in ntdll (+0x211f2) (0x7ffb11f2) 6 0x7ffb13c5 in ntdll (+0x213c5) (0x7ffb13c5) 7 0x7ffb2d8c LdrLoadDll+0x5e in ntdll (0x7ffb2d8c) 8 0x7fc6bab1 in kernel32 (+0x2bab1) (0x7fc6bab1) 9 0x7fc6bb36 LoadLibraryExW+0x4f in kernel32 (0x7fc6bb36) 10 0x7fc6bbe5 LoadLibraryExA+0x2d in kernel32 (0x7fc6bbe5) 11 0x7fc6bc0b LoadLibraryA+0x1b in kernel32 (0x7fc6bc0b) 12 0x7fc1f219 main+0xb7 in winevdm (0x7fc1f219) 13 0x7fc1fb0b in winevdm (+0xfb0b) (0x7fc1fb0b) 14 0x7fc730f3 in kernel32 (+0x330f3) (0x7fc730f3) 15 0xb7ee654b wine_switch_to_stack+0x17 in libwine.so.1 (0xb7ee654b) 0xb7df2e97 memset+0x37 in libc.so.6: repe stosl %es:(%edi)
Now, I am no debugger expert, but it appears that Wine is trying to write to a NULL pointer using memset. (I could be reading the stack dump wrong, bear with me here)
I hope this helps.
Segin wrote:
you all may find intersting.
Not me. Nyah, nyah.
I went to make sure that Wine wasn't broken, so I re-exec'd the binary, but only to get this:
I've recently seen exceptions too when trying to run Win3.1 (and DOS, but I'm not sure that's supposed to work) applications.
Sucks, I wonder what can be done in general about that.
Just starting the application causes it to segfault, so one approach could be to find a buckload of Win3.1 programs and create a testsuite that just tries to run them and declare the test a success if they're still running after 10 seconds.
No, seriously :-).
First chance exception: page fault on write access to 0x000f0400 in 32-bit code (0xb7df2e97). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:003b GS:0033 EIP:b7df2e97 ESP:7fbff570 EBP:7fbff5b0 EFLAGS:00010246( - 00 -RIZP1) EAX:00000000 EBX:7eee7ff0 ECX:00000023 EDX:00000000 ESI:000f0400 EDI:000f0400 Stack dump: 0x7fbff570: 00000000 7eed0e49 000f0400 00000000 0x7fbff580: 0000008c 7ffd50f0 00010000 7ffb190b 0x7fbff590: 7ffdcc24 7fc94988 00000000 0000ffff 0x7fbff5a0: 0000f30f 7eee7ff0 00000000 00000001 0x7fbff5b0: 7fbff5bc 7eed158d 7eee7ff0 7fbff5dc 0x7fbff5c0: 7eee51c4 7eec0000 00000001 00000000 Backtrace: =>1 0xb7df2e97 memset+0x37 in libc.so.6 (0xb7df2e97) 2 0x7eed158d DllMain+0x22 in winedos (0x7eed158d) 3 0x7eee51c4 in winedos (+0x251c4) (0x7eee51c4) 4 0x7ffb0a2d call_dll_entry_point+0x15 in ntdll (0x7ffb0a2d) 5 0x7ffb11f2 in ntdll (+0x211f2) (0x7ffb11f2) 6 0x7ffb13c5 in ntdll (+0x213c5) (0x7ffb13c5) 7 0x7ffb2d8c LdrLoadDll+0x5e in ntdll (0x7ffb2d8c) 8 0x7fc6bab1 in kernel32 (+0x2bab1) (0x7fc6bab1) 9 0x7fc6bb36 LoadLibraryExW+0x4f in kernel32 (0x7fc6bb36) 10 0x7fc6bbe5 LoadLibraryExA+0x2d in kernel32 (0x7fc6bbe5) 11 0x7fc6bc0b LoadLibraryA+0x1b in kernel32 (0x7fc6bc0b) 12 0x7fc1f219 main+0xb7 in winevdm (0x7fc1f219) 13 0x7fc1fb0b in winevdm (+0xfb0b) (0x7fc1fb0b) 14 0x7fc730f3 in kernel32 (+0x330f3) (0x7fc730f3) 15 0xb7ee654b wine_switch_to_stack+0x17 in libwine.so.1 (0xb7ee654b) 0xb7df2e97 memset+0x37 in libc.so.6: repe stosl %es:(%edi)
You might want to file a bug report? I think the core developers have much more interesting things to do besides fixing bugs, so the best bet is probably to create a bug report (with URL to the app) and wait for a developer to become bored or hungry for a small victory.
Molle Bestefich wrote:
Segin wrote:
you all may find intersting.
Not me. Nyah, nyah.
I went to make sure that Wine wasn't broken, so I re-exec'd the binary, but only to get this:
I've recently seen exceptions too when trying to run Win3.1 (and DOS, but I'm not sure that's supposed to work) applications.
Sucks, I wonder what can be done in general about that.
Just starting the application causes it to segfault, so one approach could be to find a buckload of Win3.1 programs and create a testsuite that just tries to run them and declare the test a success if they're still running after 10 seconds.
No, seriously :-).
First chance exception: page fault on write access to 0x000f0400 in 32-bit code (0xb7df2e97). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:003b GS:0033 EIP:b7df2e97 ESP:7fbff570 EBP:7fbff5b0 EFLAGS:00010246( - 00 -RIZP1) EAX:00000000 EBX:7eee7ff0 ECX:00000023 EDX:00000000 ESI:000f0400 EDI:000f0400 Stack dump: 0x7fbff570: 00000000 7eed0e49 000f0400 00000000 0x7fbff580: 0000008c 7ffd50f0 00010000 7ffb190b 0x7fbff590: 7ffdcc24 7fc94988 00000000 0000ffff 0x7fbff5a0: 0000f30f 7eee7ff0 00000000 00000001 0x7fbff5b0: 7fbff5bc 7eed158d 7eee7ff0 7fbff5dc 0x7fbff5c0: 7eee51c4 7eec0000 00000001 00000000 Backtrace: =>1 0xb7df2e97 memset+0x37 in libc.so.6 (0xb7df2e97) 2 0x7eed158d DllMain+0x22 in winedos (0x7eed158d) 3 0x7eee51c4 in winedos (+0x251c4) (0x7eee51c4) 4 0x7ffb0a2d call_dll_entry_point+0x15 in ntdll (0x7ffb0a2d) 5 0x7ffb11f2 in ntdll (+0x211f2) (0x7ffb11f2) 6 0x7ffb13c5 in ntdll (+0x213c5) (0x7ffb13c5) 7 0x7ffb2d8c LdrLoadDll+0x5e in ntdll (0x7ffb2d8c) 8 0x7fc6bab1 in kernel32 (+0x2bab1) (0x7fc6bab1) 9 0x7fc6bb36 LoadLibraryExW+0x4f in kernel32 (0x7fc6bb36) 10 0x7fc6bbe5 LoadLibraryExA+0x2d in kernel32 (0x7fc6bbe5) 11 0x7fc6bc0b LoadLibraryA+0x1b in kernel32 (0x7fc6bc0b) 12 0x7fc1f219 main+0xb7 in winevdm (0x7fc1f219) 13 0x7fc1fb0b in winevdm (+0xfb0b) (0x7fc1fb0b) 14 0x7fc730f3 in kernel32 (+0x330f3) (0x7fc730f3) 15 0xb7ee654b wine_switch_to_stack+0x17 in libwine.so.1 (0xb7ee654b) 0xb7df2e97 memset+0x37 in libc.so.6: repe stosl %es:(%edi)
You might want to file a bug report? I think the core developers have much more interesting things to do besides fixing bugs, so the best bet is probably to create a bug report (with URL to the app) and wait for a developer to become bored or hungry for a small victory.
The app doesn't have a web site, concidering that when it was written, USENET, UUCP, and FTP were bascially all the networking options you had (save email, but that's implied)
I'll put it in http://segin.no-ip.org/~segin/eyes/ but if that site is down/slow, don't complain, it's my home PC.
В сообщении от 22 апреля 2006 19:36 Segin написал(a): ...
=>1 0xb7df2e97 memset+0x37 in libc.so.6 (0xb7df2e97) 2 0x7eed158d DllMain+0x22 in winedos (0x7eed158d)
...
I hope this helps.
Check the bug 5008: http://bugs.winehq.org/show_bug.cgi?id=5008 I saw there log output like your one.
-
Molle Bestefich -
Segin -
Vitaly Lipatov