https://bugs.winehq.org/show_bug.cgi?id=40238
Bug ID: 40238 Summary: Liquid... Wen? (demoscene, Haujobb, 2002) crashes to desktop Product: Wine-staging Version: unspecified Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: aapmak@gmail.com CC: erich.e.hoover@wine-staging.com, michael@fds-team.de, sebastian@fds-team.de Distribution: ---
Created attachment 53783 --> https://bugs.winehq.org/attachment.cgi?id=53783 Crash dump
The demo (demoscene) "Liquid... Wen?" by Haujobb, made in 2002 consistently crashes to desktop at a fixed moment of its run.
Demo can be downloaded here:
http://www.pouet.net/prod.php?which=7130
and a video can be found here:
https://www.youtube.com/watch?v=Ae8UK9mscWg
The point it crashes is around the 07:05 mark, after (in-demo) a countdown completes, upon which another scene should start.
This phenomenon has occurred for me throughout 1.7.x, 1.8.x and now also with all versions of 1.9.x and is not limited to just Wine Staging, regular Wine also exhibits this behaviour. Switching between PulseAudio and ALSA has seen no resolution either. Neither is it limited to just 1 set of hardware, for me at least.
A crashdump has been attached.
https://bugs.winehq.org/show_bug.cgi?id=40238
Sebastian Lackner sebastian@fds-team.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download URL| |http://www.pouet.net/prod.p | |hp?which=7130 Component|-unknown |-unknown Version|unspecified |1.9.4 Product|Wine-staging |Wine
--- Comment #1 from Sebastian Lackner sebastian@fds-team.de --- The bug doesn't look Wine-Staging specific, so moving to the Wine product.
https://bugs.winehq.org/show_bug.cgi?id=40238
Sergey Isakov isakov-sl@bk.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |isakov-sl@bk.ru
--- Comment #2 from Sergey Isakov isakov-sl@bk.ru --- Created attachment 53791 --> https://bugs.winehq.org/attachment.cgi?id=53791 It works
wine-1.9.4-188-g5953927 MacOSX Nvidia 7300LE using winex11.drv
installed .Net 4.0
https://bugs.winehq.org/show_bug.cgi?id=40238
--- Comment #3 from Sergey Isakov isakov-sl@bk.ru --- Additionally I can sey that the game crash with winemac.drv in glu32.dll.
https://bugs.winehq.org/show_bug.cgi?id=40238
--- Comment #4 from Armin Altorffer aapmak@gmail.com --- (In reply to Sergey Isakov from comment #2)
Created attachment 53791 [details] It works
wine-1.9.4-188-g5953927 MacOSX Nvidia 7300LE using winex11.drv
installed .Net 4.0
As stated in my bug report, it crashes at a very specific point. Your screenshot is long before the point it crashes. Keep running it, it should crash at around 07:05.
https://bugs.winehq.org/show_bug.cgi?id=40238
--- Comment #5 from Sergey Isakov isakov-sl@bk.ru --- OK, I got the crash after about 8 minutes playing. I don't know how did you see time scale. The crash shows nothing interesting. Just page fault with memory overflow. I may propose it is the game bug.
https://bugs.winehq.org/show_bug.cgi?id=40238
--- Comment #6 from Sergey Isakov isakov-sl@bk.ru --- Yes, you are right, crash after 7:05 ~~~~ Unhandled exception: page fault on read access to 0x00000015 in 32-bit code (0x00413f67). Register dump: CS:0017 SS:001f DS:001f ES:001f FS:1007 GS:0037 EIP:00413f67 ESP:0033fc54 EBP:0033fcf4 EFLAGS:00210206( R- -- I - -P- ) EAX:426cfe60 EBX:00000000 ECX:3eb71444 EDX:00000009 ESI:013d8d00 EDI:013d8d48 Stack dump: 0x0033fc54: 00000000 00000000 00000000 00000000 0x0033fc64: 0123fa10 00000000 3f6e766a 4081c128 0x0033fc74: 00000000 00000051 00000b50 3f4e57e0 0x0033fc84: 00000b5c 0033fca8 3f6c51af 40812400 0x0033fc94: 42001920 c323fe25 7a882fa4 3f800000 0x0033fca4: 7a8842db 0033fcb8 96acbdb7 40812400 0200: sel=1007 base=7ffc0000 limit=00000fff 32-bit rw- Backtrace: =>0 0x00413f67 in liquid (+0x13f67) (0x0033fcf4) 1 0x004159f3 in liquid (+0x159f2) (0x7a8842d0) 0x00413f67: call *0xc(%edx) Modules: Module Address Debug info Name (241 modules) PE 400000- 4b1000 Export liquid PE 10000000-10057000 Deferred bass PE 3c001000-3c1ba000 Deferred libwine.1.dylib PE 3c1ba000-3c1dc000 Deferred libgcc_s.1.dylib ~~~ As I see this is a game bug.
https://bugs.winehq.org/show_bug.cgi?id=40238
--- Comment #7 from Armin Altorffer aapmak@gmail.com --- (In reply to Sergey Isakov from comment #6)
Yes, you are right, crash after 7:05 As I see this is a game bug.
Well, no... as it works just fine on native Windows. See the Youtube video in my original bug report; obviously recorded on a Windows machine.
https://bugs.winehq.org/show_bug.cgi?id=40238
--- Comment #8 from Sergey Isakov isakov-sl@bk.ru --- Confirm, no crash in real Windows 7-32.
https://bugs.winehq.org/show_bug.cgi?id=40238
--- Comment #9 from Sergey Isakov isakov-sl@bk.ru --- Relevant part of wine log when crash ~~~~ fixme:win:RegisterDeviceNotificationW (hwnd=0x14e600, filter=0x64f55c,flags=0x00000001) returns a fake device notification handle! err:ole:CoCreateInstanceEx apartment not initialised wine: Unhandled page fault on read access to 0xa4040492 at address 0x413f67 (thread 0037), starting debugger... ~~~~
https://bugs.winehq.org/show_bug.cgi?id=40238
--- Comment #10 from kutajydam-5795@yopmail.com --- 1.9.9 still crashes.
https://bugs.winehq.org/show_bug.cgi?id=40238
--- Comment #11 from kutajydam-5795@yopmail.com --- 1.9.11 still crashes and, in fact, a lot sooner than before. Originally, it crashed at 07:05 but now, it crashes after some 15 - 20 seconds.
https://bugs.winehq.org/show_bug.cgi?id=40238
--- Comment #12 from kutajydam-5795@yopmail.com --- Addendum to my previous post:
1.9.11 does indeed still crash and it is still sooner than before but the 15-20 second mark was as a result of the Gallium Nine codepath in Gallium enabled Wine. Base 1.9.11 does still crash though and, as stated, faster than before.
Given the varying nature of the crash point (07:05 originally, 15 - 20 seconds with Gallium Wine and ~6 minutes with 1.9.11) I'm thinking ... memory leak?
Both 64-bit prefixes as well as 32-bit prefixes crash. Kernel version seems to have no impact whatsoever nor does Mesa version.
https://bugs.winehq.org/show_bug.cgi?id=40238
--- Comment #13 from kutajydam-5795@yopmail.com --- 1.9.13 also crashing and this time, it does not even matter whether or not I use the Gallium Nine enabled Wine or not; it crashes very quickly either way.
The demo itself does not matter tremendously, it is just one demo and an ancient one at that but the fact it does not run properly does suggest Wine is having issues with how the demo was coded; a demo which runs without any problems whatsoever on Windows.
In other words -- Wine's implementation of the Windows API stack is, in this case, insufficient. Given the fact it is an older piece of software, this does suggest that other older software could have problems executing as well.
https://bugs.winehq.org/show_bug.cgi?id=40238
kutajydam-5795@yopmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|1.9.4 |1.9.13 Distribution|--- |Ubuntu
https://bugs.winehq.org/show_bug.cgi?id=40238
--- Comment #14 from kutajydam-5795@yopmail.com --- 1.9.15 still crashing; still at the increased pace.
https://bugs.winehq.org/show_bug.cgi?id=40238
7sn9gg+9s89ynchv42x4@sharklasers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |7sn9gg+9s89ynchv42x4@sharkl | |asers.com
--- Comment #15 from 7sn9gg+9s89ynchv42x4@sharklasers.com --- I can confirm that this behaviour is still displayed in wine 2.8. Both devel as well as staging.
The demo will run but simply will not complete its run, crashing in a relatively unclean manner. Additionally leaving the desktop resolution distorted.
https://bugs.winehq.org/show_bug.cgi?id=40238
--- Comment #16 from 7sn9gg+9s89ynchv42x4@sharklasers.com --- As of Wine 2.14, the demo completely stopped functioning. After its inital loading screen, it just fades to a single static frame and no longer does anything.
Not even any sound is audible.
Over the course of quite some time now, this demo by itself has demonstrated a tendency for regression within Wine. Away from complete compatibility with the Windows / DirectX APIs towards something I can assume is primarily focused on being compatibile with more contemporary software.
Shame.
https://bugs.winehq.org/show_bug.cgi?id=40238
Fabian Maurer dark.shadow4@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW CC| |dark.shadow4@web.de Ever confirmed|0 |1
--- Comment #17 from Fabian Maurer dark.shadow4@web.de ---
Over the course of quite some time now, this demo by itself has demonstrated a tendency for regression within Wine.
What kind of regressions? Starts up fine with wine 4.0-rc4.
Original problem is still present though, crash around 7:05.
https://bugs.winehq.org/show_bug.cgi?id=40238
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Liquid... Wen? (demoscene, |Liquid... Wen? (demoscene, |Haujobb, 2002) crashes to |Haujobb, 2002) crashes |desktop |around 7 minute mark URL|http://www.pouet.net/prod.p |https://web.archive.org/web |hp?which=7130 |/20180811014039/http://arch | |ive.scene.org/pub/demos/gro | |ups/haujobb/hjb_liqu.zip CC| |focht@gmx.net
--- Comment #18 from Anastasius Focht focht@gmx.net --- Hello folks,
confirming.
Adding stable download link via Internet Archive.
https://web.archive.org/web/20180811014039/http://archive.scene.org/pub/demo...
--- snip --- $ WINEDEBUG=+seh,+loaddll,+opengl wine ./liquid.exe >>log.txt 2>&1 ... 012c:Call opengl32.glMaterialfv(00000404,00001201,0032fd78) ret=00415956 012c:trace:opengl:glMaterialfv (1028, 4609, 0x32fd78) 012c:Ret opengl32.glMaterialfv() retval=7bd243e4 ret=00415956 012c:Call opengl32.glColor4f(g,g,g,g) ret=004159aa 012c:trace:opengl:glColor4f (1.000000, 1.000000, 1.000000, 1.000000) 012c:Ret opengl32.glColor4f() retval=7bd243f4 ret=004159aa 012c:Call opengl32.glEnable(00000b50) ret=004159c1 012c:trace:opengl:glEnable (2896) 012c:Ret opengl32.glEnable() retval=00000001 ret=004159c1 012c:Call opengl32.glShadeModel(00001d01) ret=004159d9 012c:trace:opengl:glShadeModel (7425) 012c:Ret opengl32.glShadeModel() retval=00001d01 ret=004159d9 012c:trace:seh:dispatch_exception code=c0000005 flags=0 addr=00413F65 ip=00413f65 tid=012c 012c:trace:seh:dispatch_exception info[0]=00000000 012c:trace:seh:dispatch_exception info[1]=c29eb5ad 012c:warn:seh:dispatch_exception EXCEPTION_ACCESS_VIOLATION exception (code=c0000005) raised 012c:trace:seh:dispatch_exception eax=c29eb5ad ebx=00000000 ecx=c29eb5ad edx=0262ce10 esi=0262cdc8 edi=0262ce10 012c:trace:seh:dispatch_exception ebp=0032fd5c esp=0032fcbc cs=0023 ds=002b es=002b fs=0063 gs=006b flags=00210206 012c:trace:seh:call_vectored_handlers calling handler at 7B00F5D0 code=c0000005 flags=0 012c:trace:seh:call_vectored_handlers handler at 7B00F5D0 returned 0 012c:trace:seh:call_stack_handlers calling handler at 0043CC80 code=c0000005 flags=0 012c:trace:seh:call_stack_handlers handler at 0043CC80 returned 1 012c:trace:seh:call_stack_handlers calling handler at 00425B98 code=c0000005 flags=0 ... wine: Unhandled page fault on read access to C29EB5AD at address 00413F65 (thread 012c), starting debugger... --- snip ---
It looks like a late manifestation of heap corruption. If you enable heap debugging it crashes much earlier, after few scenes.
--- snip --- $ WINEDEBUG=+seh,+heap,+loaddll,+opengl wine ./liquid.exe >>log_heap.txt 2>&1 ... 0100:trace:heap:RtlAllocateHeap (016A0000,70000062,00000030): returning 02435CB0 0100:trace:heap:RtlFreeHeap (016A0000,70000062,02435CB0): returning TRUE 0100:trace:heap:RtlAllocateHeap (016A0000,70000062,00000030): returning 02435CF0 0100:trace:heap:RtlFreeHeap (016A0000,70000062,02435CF0): returning TRUE 0100:trace:heap:RtlAllocateHeap (016A0000,70000062,00000030): returning 02435D30 0100:trace:heap:RtlFreeHeap (016A0000,70000062,02435D30): returning TRUE 0100:trace:heap:RtlAllocateHeap (016A0000,70000062,00000030): returning 01706A68 0100:trace:heap:RtlFreeHeap (016A0000,70000062,01706A68): returning TRUE 0100:trace:heap:RtlAllocateHeap (016A0000,70000062,00000030): returning 02435D70 0100:trace:heap:RtlFreeHeap (016A0000,70000062,02435D70): returning TRUE 0100:trace:heap:RtlAllocateHeap (016A0000,70000062,00000030): returning 02435DB0 0100:trace:heap:RtlFreeHeap (016A0000,70000062,02435DB0): returning TRUE 0100:trace:heap:RtlAllocateHeap (016A0000,70000062,00000030): returning 02435DF0 0100:trace:heap:RtlFreeHeap (016A0000,70000062,02435DF0): returning TRUE 0100:trace:heap:RtlAllocateHeap (016A0000,70000062,00000030): returning 01706C08 0100:trace:heap:RtlFreeHeap (016A0000,70000062,01706C08): returning TRUE 0100:trace:heap:RtlAllocateHeap (016A0000,70000062,00000800): returning 04622420 0100:trace:heap:RtlFreeHeap (016A0000,70000062,04621CE0): returning TRUE 0100:trace:heap:RtlFreeHeap (016A0000,70000062,03E2E550): returning TRUE 0100:trace:opengl:glMatrixMode (5889) 0100:trace:opengl:glLoadIdentity () 0100:trace:opengl:glMultMatrixd (0x32fd08) 0100:trace:opengl:glViewport (0, 0, 640, 480) 0100:trace:opengl:glMatrixMode (5888) 0100:trace:opengl:glLoadIdentity () 0100:trace:opengl:glClearColor (0.000000, 0.000000, 0.000000, 1.000000) 0100:trace:opengl:glClear (16384) 0100:trace:opengl:glViewport (0, 0, 640, 480) 0100:trace:opengl:glPushMatrix () 0100:trace:opengl:glClearColor (0.000000, 0.000000, 0.000000, 1.000000) 0100:trace:opengl:glClear (256) 0100:trace:opengl:glMaterialfv (1028, 4609, 0x32fdb0) 0100:trace:opengl:glColor4f (1.000000, 1.000000, 1.000000, 1.000000) 0100:trace:opengl:glDisable (2896) 0100:trace:opengl:glShadeModel (7424) 0100:trace:seh:dispatch_exception code=c0000005 flags=0 addr=00413F65 ip=00413f65 tid=0100 0100:trace:seh:dispatch_exception info[0]=00000000 0100:trace:seh:dispatch_exception info[1]=55555555 0100:warn:seh:dispatch_exception EXCEPTION_ACCESS_VIOLATION exception (code=c0000005) raised 0100:trace:seh:dispatch_exception eax=43155bf3 ebx=00000000 ecx=55555555 edx=05380ef8 esi=05380eb0 edi=05380ef8 0100:trace:seh:dispatch_exception ebp=0032fd94 esp=0032fcf4 cs=0023 ds=002b es=002b fs=0063 gs=006b flags=00210202 0100:trace:seh:call_vectored_handlers calling handler at 7B00F5D0 code=c0000005 flags=0 0100:trace:seh:call_vectored_handlers handler at 7B00F5D0 returned 0 0100:trace:seh:call_stack_handlers calling handler at 0043CC80 code=c0000005 flags=0 0100:trace:seh:call_stack_handlers handler at 0043CC80 returned 1 0100:trace:seh:call_stack_handlers calling handler at 00425B98 code=c0000005 flags=0 wine: Unhandled page fault on read access to 55555555 at address 00413F65 (thread 0100), starting debugger... --- snip ---
$ sha1sum hjb_liqu.zip e4ccc6e5626b26a6e4deb6f40ce7ce4064bc0063 hjb_liqu.zip
$ du -sh hjb_liqu.zip 12M hjb_liqu.zip
$ wine --version wine-6.3
Regards
-
wine-bugs＠winehq.org -
WineHQ Bugzilla