[Bug 20380] New: Heroes of Might and Magic III hangs with err:seh:setup_exception_record nested exception on signal stack
http://bugs.winehq.org/show_bug.cgi?id=20380
Summary: Heroes of Might and Magic III hangs with err:seh:setup_exception_record nested exception on signal stack Product: Wine Version: 1.1.31 Platform: PC-x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: mc2374@mclink.it
Starting from wine 1.1.31, the game always hangs quickly after starting a campaign scenario or a previously saved game.
Sometimes the sound starts stuttering and sometimes it does not; in any case the game crashes and the console shows the following message: err:seh:setup_exception_record nested exception on signal stack in thread 0009 eip 7efb2d50 esp 7ffdbc7c stack 0x242000-0x340000 Segmentation fault.
This seems a sound related thing and a regression for wine 1.1.31, because: * disabling entirely the sound in wine (i.e. unchecking all the drivers in the audio tab of wineconfig) fixes the problem: homm3 works fine, without any sound;
* reverting to wine 1.1.30 also makes the problem disappear: homm3 works fine with sound (as it did for me until wine 1.1.31).
The hang and the error message are very similar to those described in bug #15195, but for homm3 they were absent before wine 1.1.31.
http://bugs.winehq.org/show_bug.cgi?id=20380
--- Comment #1 from Giovanni Mariani mc2374@mclink.it 2009-10-15 15:57:27 --- Created an attachment (id=24154) --> (http://bugs.winehq.org/attachment.cgi?id=24154) A +relay,+seh,+tid log (as requested in bug #15195 comment #2) for wine 1.1.31.
I used tail -n 500 to include the error message: err:seh:setup_exception_record nested exception on signal stack in thread 0009 eip 7efb2d50 esp 7ffdbc7c stack 0x242000-0x340000.
http://bugs.winehq.org/show_bug.cgi?id=20380
Dmitry Timoshkov dmitry@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression
--- Comment #2 from Dmitry Timoshkov dmitry@codeweavers.com 2009-10-16 01:25:10 --- Please provide the results of your regression test: http://wiki.winehq.org/RegressionTesting
http://bugs.winehq.org/show_bug.cgi?id=20380
Wylda wylda@volny.cz changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |thunderbird2k@gmail.com, | |wylda@volny.cz
--- Comment #3 from Wylda wylda@volny.cz 2009-10-17 00:54:45 ---
1. Confirming, please consider UNCONFIRMED->NEW
2. Did a regression test between 1.1.30 and 1.1.31:
6b8753185f30197047773af6a26eafd34d45367c is first bad commit commit 6b8753185f30197047773af6a26eafd34d45367c Author: Roderick Colenbrander thunderbird2k@gmail.com Date: Sat Sep 26 14:52:46 2009 +0200
winex11: Add support for 16-bit/32-bit DIB sections.
:040000 040000 f2d2821909d152a1d37ae2932bf6017d7b622344 74221a3bdd0b8be716ed4c7900a58fddc93a2f08 M dlls
3. There is another bugreport suffering from this commit, see bug 20391. But in this game there are no graphical issues or errors. So i guess the game fails on different part of patch (not duplicate??)
4. Reverting this patch in 1.1.31 make that hang/freezing (err:seh:setup_exception_record) go away.
5. Adding author of this patch to CC and voting for this bugreport.
http://bugs.winehq.org/show_bug.cgi?id=20380
Giovanni Mariani mc2374@mclink.it changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1
--- Comment #4 from Giovanni Mariani mc2374@mclink.it 2009-10-17 01:57:14 --- *** This bug has been confirmed by popular vote. ***
http://bugs.winehq.org/show_bug.cgi?id=20380
--- Comment #5 from Wylda wylda@volny.cz 2009-10-17 02:58:20 ---
I can confirm one more thing - turning audio off in winecfg 1.1.31 and game will not hang/freeze (talking about unmodified 1.1.31).
http://bugs.winehq.org/show_bug.cgi?id=20380
--- Comment #6 from Roderick Colenbrander thunderbird2k@gmail.com 2009-10-17 03:21:46 --- Try to add a log using +xrender,+winmm,+seh,+tid. I find it strange that you get crashes in the 2D rendering code while disabling sound fixes the issues. I would expect the bug is in the audio code then.
http://bugs.winehq.org/show_bug.cgi?id=20380
--- Comment #7 from Wylda wylda@volny.cz 2009-10-17 03:35:02 --- Created an attachment (id=24180) --> (http://bugs.winehq.org/attachment.cgi?id=24180) WINEDEBUG=+xrender,+winmm,+seh,+tid wine HEROES3.EXE
(In reply to comment #6)
Try to add a log using +xrender,+winmm,+seh,+tid.
Here you are... This one is lucky, because Segmentation fault occured very soon. Please see attached log. Thank you for your interest.
@audio> i know, i know but maybe it correlates somehow...
http://bugs.winehq.org/show_bug.cgi?id=20380
--- Comment #8 from Roderick Colenbrander thunderbird2k@gmail.com 2009-10-17 03:50:15 --- (In reply to comment #7)
Created an attachment (id=24180)
--> (http://bugs.winehq.org/attachment.cgi?id=24180) [details]
WINEDEBUG=+xrender,+winmm,+seh,+tid wine HEROES3.EXE
(In reply to comment #6)
Try to add a log using +xrender,+winmm,+seh,+tid.
Here you are... This one is lucky, because Segmentation fault occured very soon. Please see attached log. Thank you for your interest.
@audio> i know, i know but maybe it correlates somehow...
The log is mixed with exceptions and xrender stuff but I can't see anything useful in it. I'm not sure what other debug channels would be useful as I'm not convinced in what area the bug is.
Roderick
http://bugs.winehq.org/show_bug.cgi?id=20380
--- Comment #9 from Wylda wylda@volny.cz 2009-10-17 07:30:55 --- Created an attachment (id=24194) --> (http://bugs.winehq.org/attachment.cgi?id=24194) small and relevant (hopefully) part of WINEDEBUG=+all
OK, another trace this time +all. I know that developers don't like to see it, but it's cca 210 lines and the problematic one "err:seh" is on line 199. Could you have a quick look Roderick and sugest whose fault it is, when not DIB? Thank you.
http://bugs.winehq.org/show_bug.cgi?id=20380
Ken Sharp kennybobs@o2.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Heroes of Might and Magic |Heroes of Might and Magic |III hangs with |III hangs |err:seh:setup_exception_rec | |ord nested exception on | |signal stack |
http://bugs.winehq.org/show_bug.cgi?id=20380
Cùran debian@carbon-project.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |debian@carbon-project.org
--- Comment #10 from Cùran debian@carbon-project.org 2009-10-18 04:45:56 --- As the platform is set to »PC-x86-64 Linux«, I'd like to add, that I can reproduce this on a 32 bit system too. So maybe it would be best set to something more generic?
http://bugs.winehq.org/show_bug.cgi?id=20380
--- Comment #11 from Wylda wylda@volny.cz 2009-10-18 19:45:37 ---
(In reply to comment #8)
The log is mixed with exceptions and xrender stuff
Xrender is not quite right, because if do "debug all", then that exception occurs behind IWineD3DBaseSurfaceImpl_LockRect, to be precise i see hundreds of:
... ...
0009:trace:d3d_surface:IWineD3DBaseSurfaceImpl_LockRect returning memory@0x1b3027c, pitch(1600)
0009:trace:seh:raise_exception code=c0000005 flags=0 addr=0x7deb0606 ip=7deb0606 tid=0009
... ...
I'm not convinced in what area the bug is.
Now i'm 100% sure that your patch broke our game :-/ I did regresion test again and i compared the console output.
Result: Right before your patch was merged, there are no such errors. And when i setup git tree to your patch, hundreds of these exception begins to occur, till the game freeze or crash. It would be nice, if you could make another revision of your patch or consider revert for next version.
@Comment #10> i'm also running 32bit version.
http://bugs.winehq.org/show_bug.cgi?id=20380
--- Comment #12 from Roderick Colenbrander thunderbird2k@gmail.com 2009-10-19 03:30:00 --- I have just tested the demo on latest GIT and on my system I'm not seeing any issues. It works fine using sound. BTW I'm using ATI which at this point uses the generic Xorg software Xrender.
Could you also try to download the demo and see if that one works: http://www.5star-shareware.com/Games/RPG/might-magic3.html
http://bugs.winehq.org/show_bug.cgi?id=20380
--- Comment #13 from Cùran debian@carbon-project.org 2009-10-19 04:00:13 --- (In reply to comment 12)
Dear Roderick, even though the demo and the version I'm using normally (Heroes of Might and Magic III Complete [0]) aren't really comparable, I still can reproduce the bug with the demo. It fails with the following line:
err:seh:setup_exception_record nested exception on signal stack in thread 0009 eip 7bc6e430 esp 7ffdbc7c stack 0x232000-0x330000
For the record: I'm using (for this game) Debian testing on an 1.5 GHz Athlon, with an ATI R300 GPU (radeon driver 6.12.3/Mesa 7.6) and a 2.6.31.3 kernel. Desktop environment is KDE.
Kind regards, Kai
[0] http://appdb.winehq.org/objectManager.php?sClass=version&iId=2628
http://bugs.winehq.org/show_bug.cgi?id=20380
--- Comment #14 from Roderick Colenbrander thunderbird2k@gmail.com 2009-10-19 04:34:07 --- What Wine version are you using? Could you retry using latest GIT?
http://bugs.winehq.org/show_bug.cgi?id=20380
--- Comment #15 from Cùran debian@carbon-project.org 2009-10-19 05:02:08 --- (In reply to comment #14)
Wine is 1.1.31 (thought that was clear, as the bug is reported against that version), installed/built from [0]. Latest Git will take some time, but I can try, unless somebody else is faster. ;)
[0] http://mentors.debian.net/cgi-bin/sponsor-pkglist?action=details;package=win...
http://bugs.winehq.org/show_bug.cgi?id=20380
--- Comment #16 from Wylda wylda@volny.cz 2009-10-19 05:43:33 --- (In reply to comment #15)
...unless somebody else is faster. ;)
I will gladly test it, when i will be back at home - cca 8hours from now.
http://bugs.winehq.org/show_bug.cgi?id=20380
--- Comment #17 from Wylda wylda@volny.cz 2009-10-19 11:44:57 ---
Ok tested with latest git, but i have bad news:
1. HOMAM 3 still freezes
2. Graphics looks ugly now - not the game itself, but videos (ie. intro) looks like it has only half resolution. Big pixels and glitches sometimes. For example sun, should be all yellow and now it has big black points in it.
So now there are two regressions :-/
http://bugs.winehq.org/show_bug.cgi?id=20380
--- Comment #18 from Roderick Colenbrander thunderbird2k@gmail.com 2009-10-19 12:03:43 --- So the crash is over in latest GIT for you? If possible could you try a different display driver? E.g. catalyst 9.3 which still supports your card OR perhaps 'exa' can be disabled so that you use software xrender. I fear that the issue you are seeing now is a driver bug. Can some people using the nvidia drivers try as well? Their XRender implementation is quite decent.
Roderick
http://bugs.winehq.org/show_bug.cgi?id=20380
--- Comment #19 from Roderick Colenbrander thunderbird2k@gmail.com 2009-10-19 12:08:00 --- Err, I forgot that you (Wylda) are using Nvidia (somehow thought you were using ATI). Could you try to add the line: Option "RenderAccel" "0" in the screen / device section of your xorg.conf in order to disable hardware accelerated XRender. This way the Nvidia driver should fall back to software. I wonder if the issue still occurs then.
http://bugs.winehq.org/show_bug.cgi?id=20380
--- Comment #20 from Wylda wylda@volny.cz 2009-10-19 13:32:16 --- Roderick, (In reply to comment #18)
So the crash is over in latest GIT for you?
Hi Roderick, this is misunderstanding. Game still crashes with current git and still produces STATUS_ACCESS_VIOLATION (ie. 0xC0000005) after trace:d3d_surface:IWineD3DBaseSurfaceImpl_LockRect
When i change xorg.conf to:
Section "Device" Identifier "Device0" Driver "nvidia" VendorName "NVIDIA Corporation" Option "RenderAccel" "0" EndSection
and use latest git, game still crashes, in other words changing xorg.conf did NOT help and using latest git also did NOT help.
PS: i take back what i wrote in comment #17 about ugly graphics. Video quality is probably setup by detected speed.
http://bugs.winehq.org/show_bug.cgi?id=20380
--- Comment #21 from Henri Verbeet hverbeet@gmail.com 2009-10-20 05:31:46 --- (In reply to comment #20)
still produces STATUS_ACCESS_VIOLATION (ie. 0xC0000005) after trace:d3d_surface:IWineD3DBaseSurfaceImpl_LockRect
That's probably just the memory protection on the dibsection, shouldn't be a problem.
http://bugs.winehq.org/show_bug.cgi?id=20380
Wylda wylda@volny.cz changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |hverbeet@gmail.com
--- Comment #22 from Wylda wylda@volny.cz 2009-10-20 08:27:57 --- (In reply to comment #21)
That's probably just the memory protection on the dibsection, shouldn't be a problem.
Hi Henri, there is something missing in your answer ;) For what or for whom it should not be a problem? I'm an ordinary user and this is invincible problem for me. Program freeze or crashes with segfault and i can't do nothing to make it run with current git or 1.1.31.
http://bugs.winehq.org/show_bug.cgi?id=20380
--- Comment #23 from Henri Verbeet hverbeet@gmail.com 2009-10-20 08:41:52 --- (In reply to comment #22)
Hi Henri, there is something missing in your answer ;) For what or for whom it should not be a problem? I'm an ordinary user and this is invincible problem for me. Program freeze or crashes with segfault and i can't do nothing to make it run with current git or 1.1.31.
I mean that those are most likely unrelated to the crash. You say the program crashes, is there a backtrace?
http://bugs.winehq.org/show_bug.cgi?id=20380
--- Comment #24 from Wylda wylda@volny.cz 2009-10-20 09:05:28 --- (In reply to comment #23)
I mean that those are most likely unrelated to the crash.
OK, but that would make sense (to me), if that memory protection was a feature added by commit "Add support for 16-bit/32-bit DIB sections", because these (hundred) "seh:raise_exception" began to occur after merging this dib section patch.
You say the program crashes, is there a backtrace?
Unfortunately no. After merging dib section patch, program
* Freeze (usualy with repetitive sound of that moment)
or
* end up within text console with Segmentation fault (i call this as crash) and only sign of error is "err:seh:setup_exception_record nested exception on signal stack in thread 0009 eip..."
http://bugs.winehq.org/show_bug.cgi?id=20380
--- Comment #25 from Wylda wylda@volny.cz 2009-10-20 14:34:16 --- Created an attachment (id=24251) --> (http://bugs.winehq.org/attachment.cgi?id=24251) winedbg info
I found info about backtraces (http://wiki.winehq.org/Backtraces) so in hope, that it should show something useful i gave it a try. When the game froze with repetitive sound, winedbg show nothing (is that correct?). I had to go to the terminal window, from which the game was run and press Ctrl+C. After that, terminal with winedbg finally vomit something (attached).
http://bugs.winehq.org/show_bug.cgi?id=20380
--- Comment #26 from Vitaliy Margolen vitaliy@kievinfo.com 2009-10-20 23:01:14 --- I have the same problem here. Getting a useful backtrace is some-what challanging. This is a ddraw app that keeps getting DIB section access segfault on each element drawn. And when the crash happens the whole thread is gone with it's stack... On top of that crash happens after 1..10 minutes of game-play.
And I do confirm that reverting 6b875318 patch on current git does fix the problem.
http://bugs.winehq.org/show_bug.cgi?id=20380
--- Comment #27 from Wylda wylda@volny.cz 2009-10-21 01:53:35 --- (In reply to comment #26)
On top of that crash happens after 1..10 minutes of game-play.
OK, my way how to get a crash ten time faster is following... Start a new scenario or load a game. Let the Hero exhaust his energy, so moving cross is not green but brown. Then choose on _numeric_pad_ one key 1..9 in direction where is _no_obstacle_ and keep the key pressed. This will cause quick redraw of brown cross. Usually in 10sec game is dead. This is for 95%.
So if you hit unlucky 5% and you start 11th sec add moving mouse symbol over hero so it will change its symbol and also redraw very quickly.
Of course, sound must be ON in winecfg. Otherwise it does not crash... Strange for ddraw problem :-/
And I do confirm that reverting 6b875318 patch on current git does fix the problem.
Good to here i have an ally :-)
http://bugs.winehq.org/show_bug.cgi?id=20380
Damjan Jovanovic damjan.jov@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |damjan.jov@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=20380
--- Comment #28 from Rico kgbricola@web.de 2009-10-21 06:39:03 --- Created an attachment (id=24265) --> (http://bugs.winehq.org/attachment.cgi?id=24265) homm3 debug session
Attached is a log from a homm3 debug session.
For me it looks like the exceptions happen in IWineD3DBaseSurfaceImpl_Blt on an access to dbuf (e.g. memcpy(dbuf, sbuf, width); - ~line 1240 in surface_base.c). It could also happen on other accesses to dbuf in IWineD3DBaseSurfaceImpl_Blt.
The exception doesn't happen all the time, I guess only when dbuf is a dib section which is created/filled by X11DRV_XRender_SetPhysBitmapDepth() (Any idea how to check that?). If I comment the if(!X11DRV_XRender_SetPhysBitmapDepth()) in dib.c then no exceptions are thrown. The game runs fine with these exceptions and disabled sound. My guess is that the combination of the exceptions and the "sound bug" let the game crash. One alone let the game run fine.
http://bugs.winehq.org/show_bug.cgi?id=20380
--- Comment #29 from Cùran debian@carbon-project.org 2009-10-21 06:42:56 --- (In reply to comment #26)
On top of that crash happens after 1..10 minutes of game-play.
I can speed that up: just hit Esc and/or Q a few times while the 3DO logo and intro is shown. Fails with the same error. (And again: disabling the sound with winecfg prevents the crash.)
@Wylda: Thanks for doing the Git tests, wasn't in reach of a fast access line to the net. So it would have taken me ages to get the Git checked out. ;)
http://bugs.winehq.org/show_bug.cgi?id=20380
--- Comment #30 from Roderick Colenbrander thunderbird2k@gmail.com 2009-10-24 13:00:15 --- The bug likely occurs only for dibsections. I'll give a short summary of what the patch changed and perhaps were to look for the issue.
Most of the time your Xserver runs at 24-bit. One limitation of X is that it doesn't allow you to render e.g. 16-bit data to a 24-bit window. Windows allows this. When a program wants to use this depth (e.g. for dibsections) we perform depth conversion. This means that we render at 24-bit and when a programs reads the data back we convert 24-bit back to 16-bit.
I suspect that Homm3 is using a depth of 16-bit. Internally wined3d then uses 16-bit dibsections for the rendering. During a Blt in wined3d we call gdi functions like BitBlt to render the surface to the screen.
The XRender extension allows depth conversion, so using that we can blit 16-bit data to a 24-bit Window which isn't possible using plain X11. The patch which broke Homm3 allows dibsections to be created in 16-bit (and other depths) without having to do any depth conversion in software (that happens in dib.c / dib_convert.c).
It is hard to say where the problem is but I guess that when using the depth conversion code we were performing some locking and that right now we are trying to access the data from two places at the same time or so. Figuring what is wrong is hard though it could be in wined3d, winex11.drv/dib.c bitmap.c or xrender.c.
So basically I think that the XRender code is good but that it uncovered some new bug.
Roderick
http://bugs.winehq.org/show_bug.cgi?id=20380
--- Comment #31 from Cùran debian@carbon-project.org 2009-10-25 12:40:14 --- Probably obvious to devs after Roderick's statement in comment #30 Anyway, I can confirm this with Wine 1.1.32.
http://bugs.winehq.org/show_bug.cgi?id=20380
--- Comment #32 from Wylda wylda@volny.cz 2009-10-28 10:05:40 --- (In reply to comment #30)
The bug likely occurs only for dibsections. I'll give a short summary of what the patch changed and perhaps were to look for the issue.
Hi Roderick, thank you for that summary.
It is hard to say where the problem is but I guess that when using the depth conversion code...
OK, this led me to the idea of confirming your guess. So game still crashes with current git (wine-1.1.32-119-g07c321b), but if i change xorg.conf and setup 16bit depth for xwindow, then the game does not freeze... Switching back to 24bit and X restart, game freeze/crashes and following duo comes up in log:
0009:trace:d3d_surface:IWineD3DBaseSurfaceImpl_LockRect
0009:trace:seh:raise_exception code=c0000005
Makes sense to you or are you closer to the solution now?
http://bugs.winehq.org/show_bug.cgi?id=20380
--- Comment #33 from Roderick Colenbrander thunderbird2k@gmail.com 2009-10-28 13:29:07 --- I haven't had time to look at the issue and neither have I seen the issue on this system, so I can only assist a bit from the sidelines. I would recommend to look at winex11.drv/dib.c and perhaps the xrender code but I think that the xrender code itself is correct. What the code roughly does is check what color depths are available when a DIBSection is created and later on, xrender is used for blitting and font drawing. I think the issue is somewhere in the dib code.
You could try to run the game in synchronous X11 mode, issues can be easier to debug in there. If you use WINEDEBUG=+synchronous you use this mode, it can be combined with the other debug channels as well. Hopefully it helps debugging but usage of it might also 'fix' the issue.
Roderick
http://bugs.winehq.org/show_bug.cgi?id=20380
Timothy Madden terminatorul@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |terminatorul@gmail.com
--- Comment #34 from Timothy Madden terminatorul@gmail.com 2009-11-08 13:08:07 --- Can someone please still look into this ?
I get this on 1.1.32
http://bugs.winehq.org/show_bug.cgi?id=20380
Yuri Chudnovsky frank@fqc.org.ua changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |frank@fqc.org.ua
--- Comment #35 from Yuri Chudnovsky frank@fqc.org.ua 2009-11-11 10:53:51 --- Confirm hangups. 1.1.32~winehq0~ubuntu~9.04-0ubuntu1, err:seh:setup_exception_record nested exception on signal stack in thread 0009 eip 7bc6fec0 esp 7ffdbc7c stack 0x232000-0x330000
http://bugs.winehq.org/show_bug.cgi?id=20380
Sir Anthony sergant_ant@list.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sergant_ant@list.ru
--- Comment #36 from Sir Anthony sergant_ant@list.ru 2009-11-17 07:40:56 --- Confirm this bug. wine-1.1.33 slackware 13(sbo slackbuild) game freeze with error err:seh:setup_exception_record nested exception on signal stack in thread 0009 eip 7efbe510 esp 7ffdbc7c stack 0x242000-0x340000
http://bugs.winehq.org/show_bug.cgi?id=20380
Lubos Kolouch kolcon@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |kolcon@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=20380
--- Comment #37 from Wylda wylda@volny.cz 2009-12-04 20:17:06 ---
Still not fixed in 1.1.34.
http://bugs.winehq.org/show_bug.cgi?id=20380
Vitaliy Margolen vitaliy@kievinfo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |megatog615@gmail.com
--- Comment #38 from Vitaliy Margolen vitaliy@kievinfo.com 2009-12-07 09:00:23 --- *** Bug 20931 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=20380
--- Comment #39 from Roderick Colenbrander thunderbird2k@gmail.com 2009-12-11 13:04:44 --- Created an attachment (id=25170) --> (http://bugs.winehq.org/attachment.cgi?id=25170) Possible fix
This patch may fix issues some people are seeing due to my xrender work. The bugs aren't the xrender code itself. Various games seem to use the stack pointer as an extra register (at least populous does and some of the apps which have moved to this bug as well). Due to this the memory trapping code on the dibsections won't work. In ddraw we present a dibsection to the apps and this causes the issues. For some reason this issue didn't occur before my changes, so likely a different codepath in Wine is entered. Let me know if this works.
http://bugs.winehq.org/show_bug.cgi?id=20380
--- Comment #40 from Wylda wylda@volny.cz 2009-12-11 14:48:57 --- (In reply to comment #39)
.... Let me know if this works.
Hi Roderick, unfortunately this patch does not help here. I just got under patched wine-1.1.34-309-g9352509 following error message:
err:seh:setup_exception_record nested exception on signal stack in thread 0009 eip 7bc7856d esp 7ffdbc3c stack 0x242000-0x340000
http://bugs.winehq.org/show_bug.cgi?id=20380
--- Comment #41 from Wylda wylda@volny.cz 2009-12-11 15:10:22 --- Created an attachment (id=25172) --> (http://bugs.winehq.org/attachment.cgi?id=25172) Heroes 3 run under winedbg
In desperate hope, that it could help somehow... Roderick, could you take a look at attached backtraces? Since your patch was merged, when i run H3 under winedbg it crashes with every new screen refresh - few of those crashes are attached. So there is an intro movie and when i want to see next movie frame, i have to write "pass" in the console (game was run: wine winedbg HEROES3.EXE). It paints one movie frame and crash again...
Before your patch (wine-1.1.30) i could write just 1x "cont" and 1x "pass" and game went fine without crashes and backtraces. Makes some sense?
http://bugs.winehq.org/show_bug.cgi?id=20380
--- Comment #42 from Cùran debian@carbon-project.org 2009-12-11 16:45:42 --- (In reply to comment #39)
.... Let me know if this works.
No, still crashes.
Additionally to what Wylda reported in comment #40 and comment #41 I like to point out, that the proposed patch generates new warnings in surface_base.c (the following is from the build log of a pbuilder run for the i386 binary packages): gcc -m32 -c -I../../../dlls/wined3d -I. -I../../../include -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wstrict-prototypes -Wwrite-strings -Wtype-limits -Wpointer-arith -O2 -g -o surface_base.o ../../../dlls/wined3d/surface_base.c ../../../dlls/wined3d/surface_base.c: In function 'IWineD3DBaseSurfaceImpl_LockRect': ../../../dlls/wined3d/surface_base.c:1847: warning: pointer of type 'void *' used in arithmetic ../../../dlls/wined3d/surface_base.c:1847: warning: pointer of type 'void *' used in arithmetic ../../../dlls/wined3d/surface_base.c:1852: warning: pointer of type 'void *' used in arithmetic ../../../dlls/wined3d/surface_base.c:1853: warning: pointer of type 'void *' used in arithmetic
If somebody should be interested: you can find the source package and binary packages for i386 and amd64 for Debian at http://dev.carbon-project.org/debian/wine-unstable/, which I'll try to keep up-to-date in case new patches are proposed.
Kind regards, Kai
http://bugs.winehq.org/show_bug.cgi?id=20380
Roderick Colenbrander thunderbird2k@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #25170|0 |1 is obsolete| |
http://bugs.winehq.org/show_bug.cgi?id=20380
--- Comment #43 from Roderick Colenbrander thunderbird2k@gmail.com 2009-12-13 08:12:51 --- Created an attachment (id=25190) --> (http://bugs.winehq.org/attachment.cgi?id=25190) Possible fix2
I have redesigned the patch. At some point I saw the same crash in memcpy (it occured in the LockRect inside surface_gdi.c) in an app I was testing. Perhaps this version works better. I don't know if it will fix homm3 though. Not all 'regressions' have the same cause.
http://bugs.winehq.org/show_bug.cgi?id=20380
--- Comment #44 from Wylda wylda@volny.cz 2009-12-13 09:30:55 --- (In reply to comment #43)
I have redesigned the patch. At some point I saw the same crash in memcpy (it occured in the LockRect inside surface_gdi.c) in an app I was testing. Perhaps this version works better. I don't know if it will fix homm3 though. Not all 'regressions' have the same cause.
Unfotunately for HEROES3 nothing has changed. Still crashes even with applied fix2:
err:seh:setup_exception_record nested exception on signal stack in thread 0009 eip 7bc7856d esp 7ffdbc3c stack 0x242000-0x340000
...also running under winedbg still crashes with each intro frame on memcpy.
http://bugs.winehq.org/show_bug.cgi?id=20380
--- Comment #45 from Roderick Colenbrander thunderbird2k@gmail.com 2009-12-13 10:54:14 --- Created an attachment (id=25192) --> (http://bugs.winehq.org/attachment.cgi?id=25192) populous 3 fix
This is a hacky fix for populous3 (which is also fixed by the other patch). If the issue in homm3 is similar this patch should work for sure. It just makes sure the app won't see the memory protections wine sets on dibsections. In homm3 I have never been able to reproduce the bug.
http://bugs.winehq.org/show_bug.cgi?id=20380
--- Comment #46 from Cùran debian@carbon-project.org 2009-12-13 11:22:32 --- (In reply to comment #43.)
Though the compiler warnings are gone, I can still reproduce the bug with the second patch (attachment #25190).
The build for the third patch (attachment #25192) is running. Will report back ASAP.
http://bugs.winehq.org/show_bug.cgi?id=20380
--- Comment #47 from Wylda wylda@volny.cz 2009-12-13 11:33:08 --- Created an attachment (id=25193) --> (http://bugs.winehq.org/attachment.cgi?id=25193) console log with winedbg
(In reply to comment #45)
It just makes sure the app won't see the memory protections wine sets on dibsections. In homm3 I have never been able to reproduce the bug.
Neither fix3 helped. Still crashes... BUT backtraces are different!
http://bugs.winehq.org/show_bug.cgi?id=20380
--- Comment #48 from Roderick Colenbrander thunderbird2k@gmail.com 2009-12-13 11:38:20 --- Created an attachment (id=25194) --> (http://bugs.winehq.org/attachment.cgi?id=25194) Updated hack with some more debug info
Try this patch. It adds an ERR line which prints the pointers.
http://bugs.winehq.org/show_bug.cgi?id=20380
--- Comment #49 from Wylda wylda@volny.cz 2009-12-13 12:00:12 --- Created an attachment (id=25195) --> (http://bugs.winehq.org/attachment.cgi?id=25195) console output with fix #4
(In reply to comment #48)
Updated hack with some more debug info. Try this patch. It adds an ERR line which prints the pointers.
Attached.
http://bugs.winehq.org/show_bug.cgi?id=20380
--- Comment #50 from Wylda wylda@volny.cz 2009-12-13 12:05:24 --- Created an attachment (id=25196) --> (http://bugs.winehq.org/attachment.cgi?id=25196) console output with fix #4 with wylda's addon
(In reply to comment #49)
Created an attachment (id=25195)
--> (http://bugs.winehq.org/attachment.cgi?id=25195) [details]
console output with fix #4
(In reply to comment #48)
Updated hack with some more debug info. Try this patch. It adds an ERR line which prints the pointers.
Attached.
Hmmm... I'm "Hello Word!" programmer, but i guess, that there is missing %p. Redone with %p.
http://bugs.winehq.org/show_bug.cgi?id=20380
--- Comment #51 from Roderick Colenbrander thunderbird2k@gmail.com 2009-12-13 12:53:58 --- Yeah I missed a 'p'. What I would be interested in is the output of that ERR line around the crash. Right now it is not useful. I expect to see a null pointer around the crash.
http://bugs.winehq.org/show_bug.cgi?id=20380
--- Comment #52 from Wylda wylda@volny.cz 2009-12-13 13:09:09 --- Created an attachment (id=25197) --> (http://bugs.winehq.org/attachment.cgi?id=25197) console output with fix #4 & with wylda's addon & crashed Hereoes 3
(In reply to comment #51)
I expect to see a null pointer around the crash.
Roger that, so here you are...
http://bugs.winehq.org/show_bug.cgi?id=20380
--- Comment #53 from Wylda wylda@volny.cz 2009-12-13 13:14:06 ---
Roderic would it be helpful, if i give you:
a) access to my machine (ssh, vpn whatever)
b) my version of Heroes 3 (legally owned)
Or suggest c) alternative yourself...
http://bugs.winehq.org/show_bug.cgi?id=20380
Plague 4plague@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |4plague@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=20380
Gustaw Smolarczyk wielkiegie@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |wielkiegie@gmail.com
--- Comment #54 from Gustaw Smolarczyk wielkiegie@gmail.com 2009-12-26 14:29:59 --- I can also reproduce this bug. I am using R600 GPU with OSS experimental drivers (everything, including XServer, from git masters). Is there any way I can help improving the situation? I'm a bit experienced programmer and I've already beaten one wine bug (#10610), but it took me a day :). Maybe some hints or something like that how can I help? I'll hopefully find some time to accomplish the task.
Could you remind me what is the direct cause of error (null access, weird library client behaviour) and where should I look for bad code? You said something about locking that's not done in some places as one of the reason of crash, didn't you?
http://bugs.winehq.org/show_bug.cgi?id=20380
--- Comment #55 from Roderick Colenbrander thunderbird2k@gmail.com 2009-12-27 10:43:01 --- (In reply to comment #54)
I can also reproduce this bug. I am using R600 GPU with OSS experimental drivers (everything, including XServer, from git masters). Is there any way I can help improving the situation? I'm a bit experienced programmer and I've already beaten one wine bug (#10610), but it took me a day :). Maybe some hints or something like that how can I help? I'll hopefully find some time to accomplish the task.
Could you remind me what is the direct cause of error (null access, weird library client behaviour) and where should I look for bad code? You said something about locking that's not done in some places as one of the reason of crash, didn't you?
To be honest since I haven't been able to reproduce the bug (I don't understand anything about the game either) I'm not sure where it is. Another game has a similar problem and it is a bit 'timing' related (perhaps some threading issue). I suspect that the issue is triggered by BitBlt from x11_copy_to_screen in wined3d. The bug is likely somewhere in the dibsection code which is mostly in dlls/winex11.drv/dib.c / bitblt.c / xrender.c.
The issue is very hard to debug because we perform memory access tricks throughout all dibsection code.
http://bugs.winehq.org/show_bug.cgi?id=20380
felipezacani@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |felipezacani@gmail.com
--- Comment #56 from felipezacani@gmail.com 2009-12-30 20:55:20 --- I can confirm everything testing with NOX, the other game affected by this bug. I can share a piece of info that might help: NOX offers the option to play using either 8 or 16 bit for gfx. With 16bit, the problem still occurs (wine .35). Switching to 8 bit kills the problem (and looks fugly, IMHO).
http://bugs.winehq.org/show_bug.cgi?id=20380
Damjan Jovanovic damjan.jov@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- URL| |http://www.5star-shareware. | |com/Games/RPG/might-magic3. | |html
http://bugs.winehq.org/show_bug.cgi?id=20380
Vitaliy Margolen vitaliy@kievinfo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |anigel@gmx.fr
--- Comment #57 from Vitaliy Margolen vitaliy@kievinfo.com 2010-01-17 21:16:08 --- *** Bug 21398 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=20380
Evengard evengard@trioptimum.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |evengard@trioptimum.com
--- Comment #58 from Evengard evengard@trioptimum.com 2010-01-19 23:42:00 --- Confirming same error with NoX game. Exact error is: err:seh:setup_exception_record nested exception on signal stack in thread 0009 eip 7bc6fd90 esp 7ffdbc7c stack 0x232000-0x330000
http://bugs.winehq.org/show_bug.cgi?id=20380
NickNill dmbohdan@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dmbohdan@gmail.com
--- Comment #59 from NickNill dmbohdan@gmail.com 2010-01-20 15:52:02 --- confirming of this issue.
err:seh:setup_exception_record nested exception on signal stack in thread 001a eip 7efb2e20 esp 7ffdbc7c stack 0x2912000-0x2b10000
http://bugs.winehq.org/show_bug.cgi?id=20380
--- Comment #60 from NickNill dmbohdan@gmail.com 2010-01-20 15:53:36 --- sorry, i forgot to say that wine version is 1.1.36
http://bugs.winehq.org/show_bug.cgi?id=20380
--- Comment #61 from Cùran debian@carbon-project.org 2010-01-28 03:58:00 --- I can confirm this bug is still present in 1.1.37. The output looks like the one posted by Wylda in attachment 25197 (with the patch from attachment 25194 applied).
http://bugs.winehq.org/show_bug.cgi?id=20380
f.v.j@hotmail.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |f.v.j@hotmail.fr
--- Comment #62 from f.v.j@hotmail.fr 2010-02-04 08:43:57 --- This bug also affects the game Pharaoh with Cleopatra extension (see http://appdb.winehq.org/objectManager.php?sClass=version&iId=6754) with the last update of Wine (1.1.37) proposed by Ubuntu 8.10.
Here what's in the terminal to see when it crashes:
err:seh:setup_exception_record nested exception on signal stack in thread 0019 eip 7bc72450 esp 7ffdbc7c stack 0x232000-0x330000
I can play with DefaultDepth 16 in xorg.conf, but the mouse cursor is ugly (and pink!!), what is not the case in 24 bit (but then the game is crashing)!
Both problems were not there with the Wine version I was using before, but I didn't looked which one it was before the update, sorry...
Tell me if there is something I can do to help.
Greetings from France, Fred
http://bugs.winehq.org/show_bug.cgi?id=20380
--- Comment #63 from f.v.j@hotmail.fr 2010-02-04 14:47:50 --- I've just noticed that if I try to play Pharaoh in NT4.0 compatibility mode with 24 bit depth, the game plays just fine, but with no sound (and no ugly pink cursor!), so it could really be sound related.
But if I try, as in comment 1, to check it with all sound drivers disabled in winecfg, the game crash really quickly and there is a backtrace in the console that I'm attaching with...
So I hope it can help, even if this not about the same game...
Fred
http://bugs.winehq.org/show_bug.cgi?id=20380
--- Comment #64 from f.v.j@hotmail.fr 2010-02-04 14:51:07 --- Created an attachment (id=26054) --> (http://bugs.winehq.org/attachment.cgi?id=26054) crash log and backtrace of Pharaoh - no sound drivers checked in winecfg
http://bugs.winehq.org/show_bug.cgi?id=20380
X-admiral admiralxw@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |admiralxw@gmail.com
--- Comment #65 from X-admiral admiralxw@gmail.com 2010-02-07 14:41:10 --- Confirming error with Might & Magic VI: Mandate of Heaven.
err:seh:setup_exception_record nested exception on signal stack in thread 001f eip 7bc6f090 esp 7ffdbc7c stack 0x242000-0x340000
Turn off audio in winecfg and everything is fine...
Tested in Wine 1.1.32, 1.1.38.
http://bugs.winehq.org/show_bug.cgi?id=20380
--- Comment #66 from Michael Builov mbuilov@gmail.com 2010-02-08 00:16:11 --- Created an attachment (id=26120) --> (http://bugs.winehq.org/attachment.cgi?id=26120) trace with WINEDEBUG=+all
Hello, seems i found where the bug is. Yes, it's access violation when writing to read-only DIB image. (look for the accesses to address 0x1dd0000 in attachment)
in short, the we have:
---> create DIB image to render screen to 0009:trace:bitmap:CreateDIBSection format (800,-600), planes 1, bpp 16, size 960000, RGB ---> then render to our DIB image 0009:trace:bitblt:BitBlt hdcSrc=0x714 0,0 -> hdcDest=0x5cc 0,0 800x600 rop=cc0020 0009:trace:bitblt:X11DRV_StretchBlt vissrc=0,0-800,600 visdst=0,0-800,600 0009:trace:bitmap:X11DRV_DIB_Lock Locking 0x710 from thread 0009 0009:trace:bitmap:X11DRV_DIB_Coerce GdiMod requested in status AppMod 0009:trace:bitmap:X11DRV_DIB_DoProtectDIBSection Changed protection from 4 to 2 ---> DIB image is read-only X11DRV_DIB_DoUpdateDIBSection(); 0009:trace:bitmap:X11DRV_DIB_DoCopyDIBSection Copying from DIB bits to Pixmap 0009:trace:bitmap:X11DRV_DIB_DoProtectDIBSection Changed protection from 2 to 1 ---> and here we have not-accessible DIB image 0009:trace:bitmap:X11DRV_DIB_Unlock Unlocking in status GdiMod 0009:trace:bitmap:X11DRV_DIB_DoProtectDIBSection Changed protection from 1 to 2 ---> but now DIB image only read-only! ---> and when we try to write 0009:trace:ddraw:IDirectDrawSurfaceImpl_Blt (0x1792d8)->(0x339ec4,0x1a71e8,0x339f98,1008000,(nil)) 0009:trace:d3d_surface:IWineD3DBaseSurfaceImpl_LockRect (0x1793d8) : rect@0x339c24 flags(00000000), output lockedRect@0x339c0c, memory@0x1dd0000 ---> we get SIGSEGV (address 01e54fe8 is within range 0x1dd0000-0x1ebb000) 0009:trace:seh:raise_exception code=c0000005 flags=0 addr=0x7ddacaf1 ip=7ddacaf1 tid=0009 0009:trace:seh:raise_exception info[0]=00000001 0009:trace:seh:raise_exception info[1]=01e54fe8 ---> in exception handler we try to restore access flags for read/write 0009:trace:bitmap:X11DRV_DIB_Coerce AppMod requested in status InSync 0009:trace:bitmap:X11DRV_DIB_DoProtectDIBSection Changed protection from 2 to 4 ---> ok, now DIB has r/w-access
This sequence (rw->r->no->r->seh->rw) is repeated again and again generating a log of exceptions and at some moment the program hangs. Disabling audio something helps, maybe because there is no additional threads created for audio processing, but access-violations don't disappear :)
http://bugs.winehq.org/show_bug.cgi?id=20380
--- Comment #67 from Michael Builov mbuilov@gmail.com 2010-02-08 00:21:26 --- Created an attachment (id=26121) --> (http://bugs.winehq.org/attachment.cgi?id=26121) patch
I've created a small patch for wine-1.1.38/dlls/winex11.drv/dib.c - see attachment. This patch fixes access flags for DIB image and greatly reduces number of exceptions - so it looks like my HOMM3 works fine.
http://bugs.winehq.org/show_bug.cgi?id=20380
--- Comment #68 from Roderick Colenbrander thunderbird2k@gmail.com 2010-02-08 05:57:19 --- (In reply to comment #67)
Created an attachment (id=26121)
--> (http://bugs.winehq.org/attachment.cgi?id=26121) [details]
patch
I've created a small patch for wine-1.1.38/dlls/winex11.drv/dib.c - see attachment. This patch fixes access flags for DIB image and greatly reduces number of exceptions - so it looks like my HOMM3 works fine.
(In reply to comment #66)
Created an attachment (id=26120)
--> (http://bugs.winehq.org/attachment.cgi?id=26120) [details]
trace with WINEDEBUG=+all
Hello, seems i found where the bug is. Yes, it's access violation when writing to read-only DIB image. (look for the accesses to address 0x1dd0000 in attachment)
in short, the we have:
---> create DIB image to render screen to 0009:trace:bitmap:CreateDIBSection format (800,-600), planes 1, bpp 16, size 960000, RGB ---> then render to our DIB image 0009:trace:bitblt:BitBlt hdcSrc=0x714 0,0 -> hdcDest=0x5cc 0,0 800x600 rop=cc0020 0009:trace:bitblt:X11DRV_StretchBlt vissrc=0,0-800,600 visdst=0,0-800,600 0009:trace:bitmap:X11DRV_DIB_Lock Locking 0x710 from thread 0009 0009:trace:bitmap:X11DRV_DIB_Coerce GdiMod requested in status AppMod 0009:trace:bitmap:X11DRV_DIB_DoProtectDIBSection Changed protection from 4 to 2 ---> DIB image is read-only X11DRV_DIB_DoUpdateDIBSection(); 0009:trace:bitmap:X11DRV_DIB_DoCopyDIBSection Copying from DIB bits to Pixmap 0009:trace:bitmap:X11DRV_DIB_DoProtectDIBSection Changed protection from 2 to 1 ---> and here we have not-accessible DIB image 0009:trace:bitmap:X11DRV_DIB_Unlock Unlocking in status GdiMod 0009:trace:bitmap:X11DRV_DIB_DoProtectDIBSection Changed protection from 1 to 2 ---> but now DIB image only read-only! ---> and when we try to write 0009:trace:ddraw:IDirectDrawSurfaceImpl_Blt (0x1792d8)->(0x339ec4,0x1a71e8,0x339f98,1008000,(nil)) 0009:trace:d3d_surface:IWineD3DBaseSurfaceImpl_LockRect (0x1793d8) : rect@0x339c24 flags(00000000), output lockedRect@0x339c0c, memory@0x1dd0000 ---> we get SIGSEGV (address 01e54fe8 is within range 0x1dd0000-0x1ebb000) 0009:trace:seh:raise_exception code=c0000005 flags=0 addr=0x7ddacaf1 ip=7ddacaf1 tid=0009 0009:trace:seh:raise_exception info[0]=00000001 0009:trace:seh:raise_exception info[1]=01e54fe8 ---> in exception handler we try to restore access flags for read/write 0009:trace:bitmap:X11DRV_DIB_Coerce AppMod requested in status InSync 0009:trace:bitmap:X11DRV_DIB_DoProtectDIBSection Changed protection from 2 to 4 ---> ok, now DIB has r/w-access
This sequence (rw->r->no->r->seh->rw) is repeated again and again generating a log of exceptions and at some moment the program hangs. Disabling audio something helps, maybe because there is no additional threads created for audio processing, but access-violations don't disappear :)
This is the way the DIBSection code is supposed to work. The problem is that the content of a DIBSection needs to be around on the X11 side but programs also have to be able to access the data from a pointer. In order to synchronize both copies there is all this memory protection magic.
In case of a Blt an exception is triggered when the memory copy isn't the latest revision of the image. This is not a problem.
Games which also give issues are ones which use Lock instead of Blt. In such cases we present the DIBSection memory directly to the app. Some programs (at least Populous) directly mess with the stack registers which prevents the memory protection code from recovering from the exception. This is very bad and we consider these apps broken (a DIB engine would fix this OR we shouldn't export the DIBSection memory directly to the app OR prevent the exception from occuring).
The code which I changed in Wine is related to the DIBSection code. Homm3 uses 16-bit and before we had to convert this 16-bit data to 24-bit on each upload (this would likely trigger the memory protection code as well). Due to my xrender work this conversion is not needed. Some code is different now (so perhaps somewhere I forgot to call some dib memory protection related code) or my code was fully correct but uncovered a new bug (I mean that when using the depth conversion, some code 'by accident' disarms the memory protections before they are presented to the app).
Based on what I described above, you might understand that the patch which you proposed is not a correct solution since this is how the DIBSection code should behave. The huge amount of exceptions which occurs is what makes the issue very hard to debug in combination with the fact that for some apps the stack gets corrupted which makes it very hard to find what code triggered the bug.
In case of Homm3 I would recommend to figure out first if the bug is not a result of Homm3 calling Lock/Unlock directly.
Roderick
http://bugs.winehq.org/show_bug.cgi?id=20380
--- Comment #69 from Michael Builov mbuilov@gmail.com 2010-02-09 20:52:18 --- Created an attachment (id=26172) --> (http://bugs.winehq.org/attachment.cgi?id=26172) patch
(In reply to comment #68) Great thanks for explanations. Now i see - this is correct behavior and not a bug. But i think that generating a lot of exceptions is not a very good idea. At least in places where we may avoid access violations - IWineD3DBaseSurfaceImpl_Blt() is the case for Homm3. The first patch wasn't quite correct (it will degrade performance) but after applying it the game works :) Here the second patch - to avoid exceptions in IWineD3DBaseSurfaceImpl_Blt(). And again, though there likely a bug in Homm3 (which i will try to find), the game works.
http://bugs.winehq.org/show_bug.cgi?id=20380
--- Comment #70 from Roderick Colenbrander thunderbird2k@gmail.com 2010-02-10 05:05:36 --- (In reply to comment #69)
Created an attachment (id=26172)
--> (http://bugs.winehq.org/attachment.cgi?id=26172) [details]
patch
(In reply to comment #68) Great thanks for explanations. Now i see - this is correct behavior and not a bug. But i think that generating a lot of exceptions is not a very good idea. At least in places where we may avoid access violations - IWineD3DBaseSurfaceImpl_Blt() is the case for Homm3. The first patch wasn't quite correct (it will degrade performance) but after applying it the game works :) Here the second patch - to avoid exceptions in IWineD3DBaseSurfaceImpl_Blt(). And again, though there likely a bug in Homm3 (which i will try to find), the game works.
You have to figure out why SurfaceImpl_Blt doesn't like the dibsection exceptions. It is the way the majority of all windows apps perform rendering using GDI. WineD3D is in this sense just a basic GDI app and basically the Blt call stalls until the exception has been resolved. Later on in x11_copy_to_screen we use GDI BitBlt to draw to the window.
This bug is very, very tricky. Personally I'm not convinced that SurfaceImpl_Blt is wrong. Have you investigated whether Homm3 isn't calling Lock directly? In that case we would directly expose the dibsection its memory to the game (some games have buggy code which messes up the exception handling).
Myself I think the issue is something somehow timing related. Perhaps somewhere the winex11_tsx11_lock code is missing or so.
Roderick
http://bugs.winehq.org/show_bug.cgi?id=20380
Michael Builov mbuilov@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mbuilov@gmail.com
--- Comment #71 from Michael Builov mbuilov@gmail.com 2010-02-12 19:57:22 --- finally, i found that the bug is in... ntdll.dll.so :) It's because SIGUSR1 is not blocked in SIGSEGV handler. I have attached gdb to Heroes3.exe and set two breakpoints: one at start of usr1_handler (breakpoint 1), other - at start of segv_handler (breakpoint 5) in dlls/ntdll/signal_i386.c. Then i setup breakpoints to not stop, just to print registers and backtrace.
And just before i get record in log "0009:err:seh:setup_exception_record nested exception on signal stack in thread 0009 eip 7efb5800 esp 7ffdbc7c stack 0x242000-0x340000 0009: *killed* exit_code=0"
i see in debugger
Breakpoint 5, 0x7efb4e40 in ?? () eax 0xb 11 ecx 0x7ffdbd0c 2147335436 edx 0x7ffdbc8c 2147335308 ebx 0x7df8bc00 2113453056 esp 0x7ffdbc7c 0x7ffdbc7c ebp 0x329db0 0x329db0 esi 0x1821d10 25304336 edi 0x1731d10 24321296 eip 0x7efb4e40 0x7efb4e40 eflags 0x200216 [ PF AF IF ID ] cs 0x23 35 ss 0x2b 43 ds 0x2b 43 es 0x2b 43 fs 0x63 99 gs 0x6b 107 #0 0x7efb4e40 in ?? () #1 <signal handler called> #2 0xf7549a4c in ?? () #3 0x7df379e7 in ?? () #4 0x01731d10 in ?? () #5 0x01821d10 in ?? () #6 0x000001f4 in ?? () #7 0x00000000 in ?? ()
Breakpoint 1, 0x7efb5800 in ?? () eax 0xa 10 ecx 0x7ffdbd0c 2147335436 edx 0x7ffdbc8c 2147335308 ebx 0x7df8bc00 2113453056 esp 0x7ffdbc7c 0x7ffdbc7c ebp 0x329db0 0x329db0 esi 0x1821d10 25304336 edi 0x1731d10 24321296 eip 0x7efb5800 0x7efb5800 eflags 0x200216 [ PF AF IF ID ] cs 0x23 35 ss 0x2b 43 ds 0x2b 43 es 0x2b 43 fs 0x63 99 gs 0x6b 107 #0 0x7efb5800 in ?? () #1 <signal handler called> #2 0x7efb47e0 in ?? () #3 0xdeadbabe in ?? () #4 0x00329c3c in ?? () #5 0x00329970 in ?? () #6 0x0001003f in ?? () #7 0x00000000 in ?? ()
Breakpoint 5, 0x7efb4e40 in ?? () eax 0xb 11 ecx 0x7ffdbbfc 2147335164 edx 0x7ffdbb7c 2147335036 ebx 0x7df8bc00 2113453056 esp 0x7ffdbb6c 0x7ffdbb6c ebp 0x329d00 0x329d00 esi 0x18b0880 25888896 edi 0x17c0880 24905856 eip 0x7efb4e40 0x7efb4e40 eflags 0x200212 [ AF IF ID ] cs 0x23 35 ss 0x2b 43 ds 0x2b 43 es 0x2b 43 fs 0x63 99 gs 0x6b 107 #0 0x7efb4e40 in ?? () #1 <signal handler called> #2 0x7efb5800 in ?? () #3 <signal handler called> #4 0xf7549a4c in ?? () #5 0x7df379e7 in ?? () #6 0x017c0880 in ?? () #7 0x018b0880 in ?? () #8 0x00000458 in ?? () #9 0x00000000 in ?? () ^C Program exited with code 01. (gdb)
Here first executed segv_handler, which changes registers, esp - one of them. Next called usr1_handler, which interrupts segv_handler - you may see 0xdeadbabe in it's backtrace. First instruction of usr1_handler is "push ebp" - which tries to store ebp to stack, but stack pointer esp now invalid. This "push" generates another SIGSEGV - segv_handler called again and we get "nested exception on signal stack".
http://bugs.winehq.org/show_bug.cgi?id=20380
--- Comment #72 from Michael Builov mbuilov@gmail.com 2010-02-12 20:13:39 --- "stack pointer esp now invalid" - may be i'm wrong, but "push ebp" at start of usr1_handler definitely generates SIGSEGV.
http://bugs.winehq.org/show_bug.cgi?id=20380
--- Comment #73 from Roderick Colenbrander thunderbird2k@gmail.com 2010-02-13 04:45:22 --- (In reply to comment #72)
"stack pointer esp now invalid" - may be i'm wrong, but "push ebp" at start of usr1_handler definitely generates SIGSEGV.
I'm not an assembly guru bt this sounds very similar as the issue in Populous. In that case the game used Lock directly and it played with the stack pointer internally which messed up our own logic.
You might be able to get a nicer result using winedbg if you disable 'first chance exceptions' (this are the DIBSection segfaults). See http://wiki.winehq.org/Backtraces.
What mostly interests me is where the calls originate from. Is it from Wine itself or from the game?
http://bugs.winehq.org/show_bug.cgi?id=20380
--- Comment #74 from Michael Builov mbuilov@gmail.com 2010-02-13 13:30:49 --- Created an attachment (id=26243) --> (http://bugs.winehq.org/attachment.cgi?id=26243) source code of test program
(In reply to comment #73) The calls from wine. I don't see any direct Lock called from Homm3.
In the game there are two threads: one thread draws via bitblt (which segfaults), other thread - a timer, which suspends first thread sending him SIGUSR1. It is segv_handler from ntdll.dll.so who messes up with registers saving and then restoring context of faulting thread. "nested exception" occurs when timer thread suspends first thread while it is in segv_handler.
To fix the bug it's needed to block SIGUSR1 in segv_handler, which is normally done at signal handler installation - man sigaction, see sa_mask. In wine signal handlers installed in wine-1.1.38/dlls/ntdll/signal_i386.c, in function signal_init_process(). But setting sa_mask is not enough, if threads created by pthread_create() then pthread_kill() should be used to send signals, not just kill(), otherwise signals may not be blocked correctly.
I've attached source code of program to test signal handling. The program may run on x86 or x86_64. - to test pthread_kill(), compile the program by "gcc -DUSE_PTHREAD_KILL sig_test.c -lpthread -o sigtest" - to test kill() - by "gcc sig_test.c -lpthread -o sigtest"
After running ./sigtest you will see that kill() works incorrectly and pthread_kill() is fine.
http://bugs.winehq.org/show_bug.cgi?id=20380
--- Comment #75 from Michael Builov mbuilov@gmail.com 2010-02-13 17:27:44 --- may be i'm wrong, but threads in wine created via pthread_create() in wine-1.1.38/dlls/ntdll/thread.c:RtlCreateUserThread(), but signals sent via kill() in wine-1.1.38/server/ptrace.c:send_thread_signal(). This is incorrect, signals should be sent via pthread_kill().
http://bugs.winehq.org/show_bug.cgi?id=20380
--- Comment #76 from Michael Builov mbuilov@gmail.com 2010-02-13 20:03:47 --- (In reply to comment #74) sorry, i made errors in my test program (sig_test.c) Instead of getpid() and kill() i had to use gettid() and tkill(). Here they are:
#include <sys/syscall.h> typedef int tid_t;
static tid_t gettid(void) { tid_t tid = (tid_t)syscall(SYS_gettid); return tid; }
static int tkill(tid_t tid, int sig) { int err = syscall(SYS_tkill, tid, sig); return err; }
With gettid() and tkill() the test completed successfully.
So send_thread_signal() in wine-1.1.38/server/ptrace.c should work properly. And so may be i was wrong about "segv_handler was interrupted by usr1_handler". But backtrace of faulted usr1_handler looks very strange:
#0 0x7efb5800 in ?? () #1 <signal handler called> #2 0x7efb47e0 in ?? () #3 0xdeadbabe in ?? () #4 0x00329c3c in ?? () #5 0x00329970 in ?? () #6 0x0001003f in ?? () #7 0x00000000 in ?? ()
i found that "0xdeadbabe" number used in wine-1.1.38/dlls/ntdll/signal_i386.c:setup_exception_record() so very likely that wine has corrupted the stack, not Homm3.
http://bugs.winehq.org/show_bug.cgi?id=20380
--- Comment #77 from Alexandre Julliard julliard@winehq.org 2010-02-14 02:57:37 --- This has been mentioned already, the stack corruption is most likely because some apps use the %esp register while manipulating dibs. There's nothing we can do about that. Whoever came up with that hack should be shot.
http://bugs.winehq.org/show_bug.cgi?id=20380
--- Comment #78 from Michael Builov mbuilov@gmail.com 2010-02-14 21:21:04 --- Created an attachment (id=26252) --> (http://bugs.winehq.org/attachment.cgi?id=26252) program to test signal handling
(In reply to comment #77) Ok, may be this is bug in linux kernel (at least in 2.6.32.6 x86_64)
Please try my test program. It emulates Homm3 behavior under wine: main thread (drawer) segfaults, other thread (timer) interrupts drawer. So main thread handles two signals: SIGSEGV and SIGUSR1. The test shows that sometimes we get "nested exception" - when SIGSEGV generated in SIGUSR1-handler (uc->uc_mcontext.gregs[REG_EIP] == &sigusr1_handler). But this can't be true because sigusr1_handler() does nothing (except "push %ebp" :)
I think in wine we have the same situation, setup_exception_record() in wine-1.1.38/dlls/ntdll:signal_i386.c detects this and kills Homm3.
to compile program "sig_test" type: gcc -m32 -g -o sig_test -lpthread sig_test2.c
http://bugs.winehq.org/show_bug.cgi?id=20380
--- Comment #79 from Cùran debian@carbon-project.org 2010-02-18 11:11:16 --- Created an attachment (id=26300) --> (http://bugs.winehq.org/attachment.cgi?id=26300) Register dump and bt with GDB
(In reply to comment #78) I've run the program and attached you'll find the GDB output for it. If you want me to run it with breakpoints, just tell me, where you want them.
Apart from that the output to stderr is 19999 times:
segfault at 8048ba8 (main_loop+d)
and somewhere in between:
main_tid: 5818, timer_tid: 5819 BUG! segmentation fault in sigusr1_handler()
I'm running a 2.6.32.8 kernel and Wine 1.1.38.
http://bugs.winehq.org/show_bug.cgi?id=20380
Cùran debian@carbon-project.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #26300|application/octet-stream |text/plain mime type| |
http://bugs.winehq.org/show_bug.cgi?id=20380
--- Comment #80 from Gustaw Smolarczyk wielkiegie@gmail.com 2010-02-19 11:05:55 --- I'm not familiar with signals and pthread, but I'll try to help somewhat :) I can easily reproduce this "BUG" on my machine. It looks like kernel delays a SIGSEGV handler. SIGUSR1 handler is called first but it's immediatly interrupted by SIGSEGV. I can't see any way how "push ebp" could generate SIGSEGV (no stack manipulation here), so it's for me the only explaination. By blocking SIGSEGV in SIGUSR1 sigaction the BUG disappears, but it's not the best way, I think. Is the SIGSEGV blocked in the whole handler? Or just pending SIGSEGVs are blocked for a while?
http://bugs.winehq.org/show_bug.cgi?id=20380
--- Comment #81 from Michael Builov mbuilov@gmail.com 2010-02-20 05:48:09 --- Created an attachment (id=26329) --> (http://bugs.winehq.org/attachment.cgi?id=26329) block SIGSEGV in sigusr1 handler
(In reply to comment #79) The test just shows that sometimes we have wrong process context (i.e. registers) in sigsegv handler. May be this is old linux kernel bug (i can reproduce it on 2.4-kernels also). But wine doesn't handle situations with incorrect context - it just kills the program.
(In reply to comment #80) Yes, after blocking SIGSEGV in sigusr1 handler - no bug - Homm3 works :) Here the patch.
http://bugs.winehq.org/show_bug.cgi?id=20380
--- Comment #82 from Cùran debian@carbon-project.org 2010-02-20 10:54:59 --- (In reply to comment #81) I can confirm, that this fixes the issue here too.
If anybody else want to try it out, I've built binary packages for Debian Sid (amd64 and i386), which are available from http://dev.carbon-project.org/debian/wine-unstable/.
http://bugs.winehq.org/show_bug.cgi?id=20380
--- Comment #83 from Evengard evengard@trioptimum.com 2010-02-20 14:48:58 --- (In reply to comment #82)
(In reply to comment #81) I can confirm, that this fixes the issue here too.
If anybody else want to try it out, I've built binary packages for Debian Sid (amd64 and i386), which are available from http://dev.carbon-project.org/debian/wine-unstable/.
Thank you, but an apt-get repository will be better...
This patch seems to fix the NoX crashes indeed.
http://bugs.winehq.org/show_bug.cgi?id=20380
Jörg Höhle hoehle@users.sourceforge.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |hoehle@users.sourceforge.ne | |t
--- Comment #84 from Jörg Höhle hoehle@users.sourceforge.net 2010-02-23 17:51:18 --- I would like to confirm the effectiveness of the patch attached to comment #81 w.r.t. Pharaoh v1.2 (German). Without it, wine-1.1.39 crashes within 1 minute after entering a level with: err:seh:setup_exception_record nested exception on signal stack in thread 0009 eip 7efbc800 esp 7ffdbc7c stack 0x232000-0x330000 Thanks to Fred from comment #62 for showing the relationship with this bug.
OTOH, PharaohDemo (English) does not suffer from the crash. Perhaps because it has no sound? (Neither does it produces sound on a native win95 machine.)
I'm using Intel i915 graphics in Ubuntu Intrepid with no PulseAudio (pactl exit) in a standard 24/32 bit X display and default settings in winecfg.
BTW, Pharaoh's mouse responsiveness is very low in current Wine, and you need to hold the mouse button for 1/2 second for the app to notice it. It worked beautifully in wine-1.0.1 and wine-1.1.18. But that's likely another issue.
http://bugs.winehq.org/show_bug.cgi?id=20380
Kari refic@psimerion.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |refic@psimerion.org
--- Comment #85 from Kari refic@psimerion.org 2010-02-24 11:05:46 --- I too would like to confirm the effectiveness of the patch attached to comment #81. It fixes a sudden freezing of a .NET 2.0 app "MJ12node" (see bug #21636). Not sure if it's sound related though because MJ12node does not produce any sound. I can also be totally wrong about this, but the patch fixes the problem anyway. Perhaps someone should investigate this.
http://bugs.winehq.org/show_bug.cgi?id=20380
--- Comment #86 from Roderick Colenbrander thunderbird2k@gmail.com 2010-02-24 11:41:04 --- I asked Alexandre about the signal patch and to him it looks like a potential kernel bug. Perhaps it would be useful if people could try the sample app on another OS like FreeBSD, Solaris or OSX. Even better would also be to try Homm3 on those operating systems, to see if it occurs there at all.
http://bugs.winehq.org/show_bug.cgi?id=20380
--- Comment #87 from Roderick Colenbrander thunderbird2k@gmail.com 2010-02-24 12:04:28 --- Just a short update. Alexandre tried the test app on OSX and there it works as expected. I'm going to ask another Wine developer to look into the issue in more detail and contact some kernel guys.
http://bugs.winehq.org/show_bug.cgi?id=20380
--- Comment #88 from Michael Builov mbuilov@gmail.com 2010-02-24 15:03:43 --- I've tried test app on solaris 9/sparc and solaris 10/i386 - no bugs.
(NOTE: under solaris i don't found pthread_spin_lock() - just comment those lines of code, also use REG_PC instead of REG_EIP/REG_RIP)
http://bugs.winehq.org/show_bug.cgi?id=20380
--- Comment #89 from Alexandre Julliard julliard@winehq.org 2010-02-25 05:04:45 --- Kernel bug filed at http://bugzilla.kernel.org/show_bug.cgi?id=15395.
http://bugs.winehq.org/show_bug.cgi?id=20380
--- Comment #90 from Alexandre Julliard julliard@winehq.org 2010-03-03 16:32:57 --- There's a kernel fix from Linus at http://bugzilla.kernel.org/show_bug.cgi?id=15395#c34. Could someone please give it a try?
http://bugs.winehq.org/show_bug.cgi?id=20380
--- Comment #91 from Wylda wylda@volny.cz 2010-03-06 09:01:31 --- Created an attachment (id=26640) --> (http://bugs.winehq.org/attachment.cgi?id=26640) patch for linux kernel 2.6.33
(In reply to comment #90)
There's a kernel fix from Linus at http://bugzilla.kernel.org/show_bug.cgi?id=15395#c34. Could someone please give it a try?
There is work around since linux kernel 2.6.33-git10 or you can use attached patch for stable kernel 2.6.33 (maybe even older).
But as i followed developer's discussion, the problem is, that wine (or the patch which caused regression??) relays on deterministic signals delivery, which never existed in linux (Linus: not a bug, but not all that well-defined behavior).
Big thank you goes to Michael Builov, who did the hard debugger job and discovered the signals relationship!
http://bugs.winehq.org/show_bug.cgi?id=20380
Dragos Petraru dragos.petraru@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dragos.petraru@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=20380
--- Comment #92 from Kari refic@psimerion.org 2010-04-17 01:58:02 --- Should 2.6.34-rc4 have the fix?
http://bugs.winehq.org/show_bug.cgi?id=20380
--- Comment #93 from Wylda wylda@volny.cz 2010-04-17 03:13:39 --- (In reply to comment #92)
Should 2.6.34-rc4 have the fix?
Yes, (if not modified or removed) since 2.6.33-git10, i.e. from nearest release (2.6.34-rc1) it should be included.
You can verify that by downloading the patch from comment #91:
patch -p1 --dry-run < linus_signal.patch
It should tell you something like already applied.
http://bugs.winehq.org/show_bug.cgi?id=20380
--- Comment #94 from Kari refic@psimerion.org 2010-04-17 03:23:10 --- "Reversed (or previously applied) patch detected!"
So I guess it's there. Interesting, it doesn't fix my problem in bug #21636 after all..
http://bugs.winehq.org/show_bug.cgi?id=20380
Vitaliy Margolen vitaliy@kievinfo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |vis@211.ru
--- Comment #95 from Vitaliy Margolen vitaliy@kievinfo.com 2010-04-18 10:49:09 --- *** Bug 22408 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=20380
Henri Verbeet hverbeet@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|hverbeet@gmail.com |
http://bugs.winehq.org/show_bug.cgi?id=20380
--- Comment #96 from Juan Lang juan_lang@yahoo.com 2010-04-19 11:46:30 --- Since this is a kernel bug, shouldn't this be marked invalid?
http://bugs.winehq.org/show_bug.cgi?id=20380
--- Comment #97 from Vitaliy Margolen vitaliy@kievinfo.com 2010-04-19 22:38:13 --- (In reply to comment #96)
Since this is a kernel bug, shouldn't this be marked invalid?
Yes, except it's being kept around to collect all duplicates.
http://bugs.winehq.org/show_bug.cgi?id=20380
Dmitry Timoshkov dmitry@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Heroes of Might and Magic |Heroes of Might and Magic |III hangs |III hangs (not a Wine bug)
http://bugs.winehq.org/show_bug.cgi?id=20380
qaridarium@googlemail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |qaridarium@googlemail.com
--- Comment #98 from qaridarium@googlemail.com 2010-05-18 00:59:57 --- i test heroes3 with an kernel 2.6.34 and wine version 1.1.43 works well :-) well done this bug is fixed in the kernel!
http://bugs.winehq.org/show_bug.cgi?id=20380
kmsiwiec@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |kmsiwiec@gmail.com
--- Comment #99 from kmsiwiec@gmail.com 2010-06-07 15:24:53 --- CPU: Intel Atom N270 RAM: 1.5 GB OS: Ubuntu Netbook 10.04 i686 Wine: 1.2rc2 (https://launchpad.net/~ubuntu-wine/+archive/ppa)
I updated to kernel 2.6.34, but the bug is still there.
On mainline kernel 2.6.34 (http://kernel.ubuntu.com/~kernel-ppa/mainline/) and either ALSA or OSS sound driver checked, within 5-25 mins of gameplay the game crashes (graphics hang, audio loops, forced quit needed) with the following dialog:
"The program heroes3 has encountered a serious problem and needs to close. We are sorry for the inconvenience. This can be caused by a problem in the program or a deficiency in Wine. [...]"
The associated console output is just:
wine: Unhandled page fault on write access to 0x00000902 at address 0x220076f1 (thread 0021), starting debugger... Killed
On backported kernel 2.6.34-5 (https://launchpad.net/~kernel-ppa/+archive/ppa) and ALSA sound driver checked, the crash dialog is instead:
"Internal errors - invalid parameters received"
http://bugs.winehq.org/show_bug.cgi?id=20380
--- Comment #100 from Evengard evengard@trioptimum.com 2010-06-12 14:44:51 --- Running NoX with Wine 1.1.46.1-2 (SuSE package on Arch), kernel 2.6.34 (Arch testing) - everything seems stable, no crashes so far.
http://bugs.winehq.org/show_bug.cgi?id=20380
Roderick Colenbrander thunderbird2k@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |geist1@sms.at
--- Comment #101 from Roderick Colenbrander thunderbird2k@gmail.com 2010-06-14 16:24:56 --- *** Bug 23152 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=20380
Roderick Colenbrander thunderbird2k@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |majorandras@freemail.hu
--- Comment #102 from Roderick Colenbrander thunderbird2k@gmail.com 2010-06-14 16:32:55 --- *** Bug 23032 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=20380
--- Comment #103 from Major András majorandras@freemail.hu 2010-06-23 03:10:51 --- I tested this bug with all kernel package from the Ubuntu Kernel Team 's PPA (https://launchpad.net/~kernel-ppa/+archive/ppa) and Pharaoh game:
2.6.34-4 2.6.34-5 2.6.35-1 2.6.35-2 2.6.35-3 2.6.35-4
All variants has same symptom, like Comment #99:
"Internal errors - invalid parameters received"
With the mainline kernel (v2.6.34-lucid) from http://kernel.ubuntu.com/~kernel-ppa/mainline/ everything works fine, but I tested it only 15 minutes.
It seems this bug is very kernel sensitive. Are you sure, that the solution is in the kernel ?
http://bugs.winehq.org/show_bug.cgi?id=20380
--- Comment #104 from Wylda wylda@volny.cz 2010-06-23 04:00:17 ---
"Internal errors - invalid parameters received"
This bug report was about: * "nested exception on signal stack in thread" * quite easily reproducible within seconds or few minutes * turnig the sounds off fixed the problem * fixed in kernel 2.6.34
I don't think you fullfil at least one of these points. And if you don't fullfil them all, then you are _probably_ in wrong bug report (there are others like bug 16683, use search or AppDB).
http://bugs.winehq.org/show_bug.cgi?id=20380
Wylda wylda@volny.cz changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords|regression |
http://bugs.winehq.org/show_bug.cgi?id=20380
Mr Nobody limited_choice@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |limited_choice@hotmail.com
--- Comment #105 from Mr Nobody limited_choice@hotmail.com 2010-07-12 03:16:44 --- Bug 22465 wrt Eufloria seems very much similar here. I've just installed a fresh 2.6.34 vanilla kernel build and it's stopped seemingly hitting the error;
err:seh:setup_exception_record nested exception on signal stack in thread 0009 eip 7efb2d50 esp 7ffdbc7c stack 0x242000-0x340000
In fact, it's behaving as it should without error, but I'll need check some more levels. This was against 1.2-rc5 ...
http://bugs.winehq.org/show_bug.cgi?id=20380
Miro Hroncok miro@hroncok.cz changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |miro@hroncok.cz
--- Comment #106 from Miro Hroncok miro@hroncok.cz 2010-07-18 18:46:37 --- Works fine with kernel 2.6.35-rc5, cannot report the bug.
http://bugs.winehq.org/show_bug.cgi?id=20380
--- Comment #107 from Reinhard Berger geist1@sms.at 2010-07-19 01:49:44 --- (In reply to comment #106)
Works fine with kernel 2.6.35-rc5, cannot report the bug.
Yes this BUG (if it is one ?) does not appear with 2.6.34/2.6.35 Kernels.
Unfortunaly the game still freezes sometimes.
See other bug 16683,
http://bugs.winehq.org/show_bug.cgi?id=20380
Wylda wylda@volny.cz changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |how2roll@live.com
--- Comment #108 from Wylda wylda@volny.cz 2010-09-01 05:00:12 CDT --- *** Bug 24231 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=20380
--- Comment #109 from Evengard evengard@trioptimum.com 2010-11-03 08:34:07 CDT --- Should be this bug closed? I don't see any problems with latest kernels.
http://bugs.winehq.org/show_bug.cgi?id=20380
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID
--- Comment #110 from Austin English austinenglish@gmail.com 2010-11-03 13:18:49 CDT --- Kernel bug, fixed for a while. Marking invalid.
http://bugs.winehq.org/show_bug.cgi?id=20380
Dmitry Timoshkov dmitry@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #111 from Dmitry Timoshkov dmitry@codeweavers.com 2010-11-04 00:33:03 CDT --- Closing invalid.
http://bugs.winehq.org/show_bug.cgi?id=20380
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |bourelom@mail.ru
--- Comment #112 from Austin English austinenglish@gmail.com 2011-04-23 14:21:18 CDT --- *** Bug 17347 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=20380
Wylda wylda@volny.cz changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |yanmcbe@gmail.com
--- Comment #113 from Wylda wylda@volny.cz 2011-06-27 10:17:13 CDT --- *** Bug 27619 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=20380
Fernando Martins fernando@cmartins.nl changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |fernando@cmartins.nl
--- Comment #114 from Fernando Martins fernando@cmartins.nl 2011-09-04 03:38:50 CDT --- I get a similar problem with Commandos 1, ie, symptoms and freeze, or seg fault, or sound loop. I am running kernel 2.6.32. The terminal output is:
fixme:win:EnumDisplayDevicesW ((null),0,0x32ecd0,0x00000000), stub! fixme:win:EnumDisplayDevicesW ((null),0,0x32ec00,0x00000000), stub! fixme:ddraw:ddraw7_WaitForVerticalBlank iface 0x13c1a8, flags 0x1, event (nil) stub! fixme:amstream:IAMMultiMediaStreamImpl_AddMediaStream (0x14b468/0x14b468)->(0x13c1b8,{a35ff56a-9fda-11d0-8fdf-00c04fd9189d},0,(nil)) partial stub! fixme:amstream:IAMMultiMediaStreamImpl_AddMediaStream (0x14b468/0x14b468)->((nil),{a35ff56b-9fda-11d0-8fdf-00c04fd9189d},1,(nil)) partial stub! fixme:amstream:IAMMultiMediaStreamImpl_Seek (0x14b468/0x14b468)->() stub! fixme:amstream:IAMMultiMediaStreamImpl_SetState (0x14b468/0x14b468)->() stub! fixme:amstream:IAMMultiMediaStreamImpl_SetState (0x14b468/0x14b468)->() stub! ALSA lib pcm_pulse.c:1008:(_snd_pcm_pulse_open) Unknown field handle_underrun fixme:alsa:AudioClient_GetMixFormat Don't know what to do with 8 channels, pretending there's only 2 channels ALSA lib pcm_pulse.c:1008:(_snd_pcm_pulse_open) Unknown field handle_underrun ALSA lib pcm_pulse.c:1008:(_snd_pcm_pulse_open) Unknown field handle_underrun ALSA lib pcm_pulse.c:1008:(_snd_pcm_pulse_open) Unknown field handle_underrun fixme:dsalsa:IDsDriverBufferImpl_SetVolumePan (0x14f7d8,0x14f660): stub fixme:amstream:IAMMultiMediaStreamImpl_AddMediaStream (0x14f6a0/0x14f6a0)->(0x13c1b8,{a35ff56a-9fda-11d0-8fdf-00c04fd9189d},0,(nil)) partial stub! fixme:amstream:IAMMultiMediaStreamImpl_AddMediaStream (0x14f6a0/0x14f6a0)->((nil),{a35ff56b-9fda-11d0-8fdf-00c04fd9189d},1,(nil)) partial stub! fixme:amstream:IAMMultiMediaStreamImpl_Seek (0x14f6a0/0x14f6a0)->() stub! fixme:amstream:IAMMultiMediaStreamImpl_SetState (0x14f6a0/0x14f6a0)->() stub! fixme:amstream:IAMMultiMediaStreamImpl_SetState (0x14f6a0/0x14f6a0)->() stub! fixme:dsalsa:IDsDriverBufferImpl_SetVolumePan (0x15afb0,0x15aef8): stub fixme:dsalsa:IDsDriverBufferImpl_SetVolumePan (0x159990,0x159890): stub err:seh:setup_exception_record nested exception on signal stack in thread 0009 eip 7bc732d0 esp 7ffdbc3c stack 0x232000-0x330000
Is this sufficient to confirm it is the same problem?
-
wine-bugs＠winehq.org