http://bugs.winehq.org/show_bug.cgi?id=24549
Summary: Firestarter Demo crashes on exit when mouse is moved. Product: Wine Version: 1.3.3 Platform: x86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: wylda@volny.cz
Created an attachment (id=30983) --> (http://bugs.winehq.org/attachment.cgi?id=30983) Cconsole log from wine-1.3.3-282-g440cf08
Now when bug 24249 is fixed, you can run Firestarter Demo. Choose Menu -> Quit and watch outtro subtitles. When you move mouse, game crashes somewhere in ntdll.
If i run the game with WINEDEBUG=warn+heap it displays:
"... invalid in-use arena magic 00000000 ..."
and it won't crash in this case :)
http://bugs.winehq.org/show_bug.cgi?id=24549
Wylda wylda@volny.cz changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download URL| |http://www.gamershell.com/d | |ownload_4489.shtml
http://bugs.winehq.org/show_bug.cgi?id=24549
--- Comment #1 from Wylda wylda@volny.cz 2010-09-28 00:17:19 CDT --- Created an attachment (id=30984) --> (http://bugs.winehq.org/attachment.cgi?id=30984) Valgrind +heap log from wine-1.3.3-282-g440cf08
I gave valgrind a chance. It looks good (IMHO) till it reach:
==9175== Invalid read of size 4 ==9175== at 0x7BC27F2F: __wine_call_from_regs (in /build/wine-git_build/dlls/ntdll/ntdll.dll.so) ==9175== by ...
http://bugs.winehq.org/show_bug.cgi?id=24549
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dank@kegel.com
--- Comment #2 from Dan Kegel dank@kegel.com 2010-09-28 08:31:43 CDT --- you probably want to add --workaround-gcc296-bugs=yes
What is this bit in the log?
/bin/sh: /usr/bin/egrep: not found /usr/bin/strings: '/home/pavel/.wine/drive_c/Program': No such file /usr/bin/strings: 'Files/FireStarter': No such file /usr/bin/strings: 'Demo/fsShell.exe': No such file
http://bugs.winehq.org/show_bug.cgi?id=24549
--- Comment #3 from Wylda wylda@volny.cz 2010-09-28 08:38:46 CDT --- (In reply to comment #2)
you probably want to add --workaround-gcc296-bugs=yes
Even if i compiled wine by gcc-4.4.5?
What is this bit in the log?
/bin/sh: /usr/bin/egrep: not found /usr/bin/strings: '/home/pavel/.wine/drive_c/Program': No such file /usr/bin/strings: 'Files/FireStarter': No such file /usr/bin/strings: 'Demo/fsShell.exe': No such file
That come from Squeeze i guess. "which egrep" says me /bin/egrep
...and i really don't know, why /usr/bin/strings "parses" path by spaces :(
http://bugs.winehq.org/show_bug.cgi?id=24549
--- Comment #4 from Dan Kegel dank@kegel.com 2010-09-28 08:59:56 CDT --- try sudo ln -s /bin/egrep /usr/bin/egrep but I still have no idea who's running grep there. Strings is complaining because it's being passed an unquoted filename, but I have no idea who's running strings, I doubt wine is doing that. Is that something you did?
http://bugs.winehq.org/show_bug.cgi?id=24549
--- Comment #5 from Wylda wylda@volny.cz 2010-09-28 09:16:14 CDT --- (In reply to comment #4)
try sudo ln -s /bin/egrep /usr/bin/egrep
I already thought about this, when you pinpoint that.
I doubt wine is doing that. Is that something you did?
No at all. It happens under valgrind in all apps i tried. And everything (except wine and kernel) comes pre-packaged by debians maintainers. Maybe valgrinds runs them normally, but one don't know, because calling egrep&string normally successed. I never saw such output in Lenny's time.
http://bugs.winehq.org/show_bug.cgi?id=24549
Julian Seward jseward@acm.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jseward@acm.org
--- Comment #6 from Julian Seward jseward@acm.org 2010-10-19 05:11:35 CDT --- (In reply to comment #1, comment #2)
==9175== Invalid read of size 4 ==9175== at 0x7BC27F2F: __wine_call_from_regs (in /build/wine-git_build/dlls/ntdll/ntdll.dll.so) ==9175== by ...
you probably want to add --workaround-gcc296-bugs=yes
I reckon this is a bug in Wine, that needs to be fixed rather than hidden with --workaround-gcc296-bugs=yes.
In order for it not to be dangerous, you'd have to promise that no signals will ever be delivered to Wine at the point that there is live data on the stack below %esp. If that did ever happen then the data would be trashed by the signal delivery frame, and you'd have an almost impossible-to-recreate timing dependent failure.
http://bugs.winehq.org/show_bug.cgi?id=24549
--- Comment #7 from Alexandre Julliard julliard@winehq.org 2010-10-19 05:39:06 CDT --- (In reply to comment #6)
In order for it not to be dangerous, you'd have to promise that no signals will ever be delivered to Wine at the point that there is live data on the stack below %esp. If that did ever happen then the data would be trashed by the signal delivery frame, and you'd have an almost impossible-to-recreate timing dependent failure.
We use signal stacks for this reason. If a signal touches the main stack that's a bug. There is no guarantee that there even is a main stack for signal delivery, apps play some very strange games sometimes.
http://bugs.winehq.org/show_bug.cgi?id=24549
--- Comment #8 from Julian Seward jseward@acm.org 2010-10-19 07:13:01 CDT --- (In reply to comment #7)
We use signal stacks for this reason. [...]
Well, fair enough. Nevertheless it does cause problems when Valgrinding Windows apps on Wine, for two reasons
* the errors need to be suppressed, which is extra effort, hassle, etc, and can also be slow if it happens millions of times
* when the data is read from below %esp, Memcheck's default rules assume the data is initialised [1]. Hence if the stored value was uninitialised it will be reloaded as initialised, so an outside chance of false negatives.
I looked at the fn and it doesn't look difficult to ensure there is no below-%esp accesses. Is there some reason why the function has this particular below-%esp accesses, or is it just an accident of history?
[1] Yes, I know this sounds stupid. See http://www.valgrind.org/docs/manual/mc-manual.html#mc-manual.together 8th bullet point for rationale.
http://bugs.winehq.org/show_bug.cgi?id=24549
--- Comment #9 from Alexandre Julliard julliard@winehq.org 2010-10-19 07:32:55 CDT --- (In reply to comment #8)
I looked at the fn and it doesn't look difficult to ensure there is no below-%esp accesses. Is there some reason why the function has this particular below-%esp accesses, or is it just an accident of history?
Mostly for efficiency reasons, though at this point the function can probably be simplified a bit by not restoring all the segment regs.
http://bugs.winehq.org/show_bug.cgi?id=24549
--- Comment #10 from Austin English austinenglish@gmail.com 2012-04-02 00:10:23 CDT --- Original link wouldn't download for me. I used http://www.fileplanet.com/134046/130000/fileinfo/Firestarter-Demo
cc6648cebac6173e192fc49761b215331b5d8378 firestarter_installdemo.exe
works fine for me in 1.5.1, can you retest Wylda?
http://bugs.winehq.org/show_bug.cgi?id=24549
--- Comment #11 from Andrey Gusev andrey.goosev@gmail.com 2013-12-10 11:03:37 CST --- Confirming. No crash in 1.7.8
http://bugs.winehq.org/show_bug.cgi?id=24549
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WORKSFORME
--- Comment #12 from Austin English austinenglish@gmail.com 2013-12-10 12:36:20 CST --- WORKSFORME.
http://bugs.winehq.org/show_bug.cgi?id=24549
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #13 from Austin English austinenglish@gmail.com --- Closing.