Bug 30131

Hi,

Can this bug be reproduced with the demo?
http://www.gamershell.com/download_17978.shtml

It seems to be working for me with git master and Wine 1.2.


System environment:
-- system architecture: 32-bit
-- Linux distribution: Debian unstable
-- GPU: RV570
-- Model: Asus EAX1950Pro 256MB
-- Display connector: DVI
-- xf86-video-ati: e9928fe036e9382fd7bc353f3f05531445f08977
-- xserver: 1.8.99.904 (1.9.0 RC 5)
-- mesa: 3ad3cbfb120efa74e77f838d9fd3f1212dd0e47b
-- drm: 23287f05cf2443ddf9e028e29beb5bd30979c6cf
-- kernel: 2.6.35

Created attachment 38655 [details]
crash log

The demo crashes the xorg server.
mesa is at git version 5ea092117fb607a5776f52d251f976c5691575c8

What's your GPU?

It's a X1400 in a T60 notebook.

Martin, is this still an issue with current Mesa git and latest wine?

Created attachment 41378 [details]
wine output

Unfortunately this is still a problem with the latest mesa git.

The game should not crash the X server. If it does, you are probably using indirect rendering, which might happen with 32-bit apps on x86_64 systems. Indirect rendering is buggy, slow, contains only a subset of features r300g offers, and gets very little testing AFAIK. So please make sure the game uses direct rendering. I should mention that using a 32-bit system may help.

Hello Marek,

(In reply to comment #7)
> The game should not crash the X server.
It doesn't crash the X server. The game tries to start but it will crash right before it is supposed to switch to the graphical full screen mode.

> indirect rendering, which might happen with 32-bit apps on x86_64 systems.
The system is a 32 bit system

> Indirect rendering is buggy, slow, contains only a subset of features r300g
> offers, and gets very little testing AFAIK. So please make sure the game uses
> direct rendering. I should mention that using a 32-bit system may help.
Where can I check what type of rendering I'm using. Should it be mentioned in the Xorg.log? I'm not at the system right now so I can't look.

Then you are most probably using direct rendering. Could you possibly obtain a backtrace (i.e. call stack) of the crash?

(In reply to comment #9)
> Then you are most probably using direct rendering. Could you possibly obtain a
> backtrace (i.e. call stack) of the crash?

I've tried to switch on wine_d3d, x11drv, x11settings, xrandr, xrender and xvidmode debug channels in wine, but the resulting log file doesn't seem to give any hints about the error (if you're interested I can upload the log file).

Are there any other debug settings which I can turn on, which could help you identifying the cause of the crash?

> Are there any other debug settings which I can turn on, which could help you
> identifying the cause of the crash?

You may find some useful info about obtaining backtraces with Wine here:
http://wiki.winehq.org/Backtraces

Is this issue still present with the current Mesa master branch?

I've compiled mesa from git today and the error is still the same.

Too bad there's nothing I can do without the backtrace.

(In reply to comment #14)
> Too bad there's nothing I can do without the backtrace.

Sorry, I overlooked your comment about using winedebug. Here is the output from winedebug:

Wine-dbg>set $BreakOnFirstChance=0 
Wine-dbg>cont
fixme:imm:ImmDisableTextFrameService Stub
fixme:thread:SetThreadIdealProcessor (0x9c): stub
fixme:thread:SetThreadIdealProcessor (0x134): stub
fixme:thread:SetThreadIdealProcessor (0x138): stub
fixme:d3d9:D3DPERF_GetStatus (void) : stub
fixme:win:EnumDisplayDevicesW ((null),0,0x335e878,0x00000000), stub!
wine: cannot find L"C:\\windows\\system32\\ShaderAssetBuilder.exe"
fixme:font:WineEngAddFontResourceEx Ignoring flags 30
fixme:dsalsa:IDsDriverBufferImpl_SetVolumePan (0x159690,0x15e158): stub
fixme:faultrep:ReportFault 0x335efd4 0x0 stub
err:mmtime:TIME_MMTimeStop Timer still active?!
Process of pid=002f has terminated

I've found my copy of C&C3 so I thought I'll try to reproduce this. However I don't get any crash at startup. I get a crash when switching desktops or alt-tabing from game, but backtrace doesn't show any signs of a driver crash, so this is probably some unrelated Wine or C&C3 crash.

Martin, here is what I found when looking into this that you may find useful. IMHO you aren't getting backtrace because the crash is happening in some other process. You need to start the game, switch to terminal, start winedbg, list process, attach to the right one (probably cnc3game.dat or some other) and trigger the crash. Hopefully you will get some backtrace then.

Hi Marek,

thanks a lot for your effort in investigating the problem! I can't attach winedebug because the game crashes right after the splash screen that means that the game is loading for a few seconds before it crashes. I've tried to list the processes during the startup but haven't seen cnc3game.dat in the process list. I'm going to install the game into a clean WINEPREFIX to see what happens then.

I've created a new wine bottle and installed the game there. I've also disabled sounds with winecfg as suggested in the wine appDB. Now the game loads just after the splash screen. After the splash screen the game goes to full screen mode but the screen contents is gabled.

I've uploaded my PKGBUILD here: http://aur.pastebin.com/Y7bzfPdV

The commented lines is the configuration I was using before and below is my current configuration for mesa. Marek, can you post your configuration options for mesa so that I can compare if you're using different compile options?

I've also tried to compile mesa with the classic r300 driver and the game doesn't work either (behaviour is exactly the same as with the gallium driver). If I remember correctly the game was running with the classic driver although there were some heavy artifacts in the game appearing. So probably I'm missing something else...

I'll try again with the original packages from my distro and then report back.

Ok, it works with the packages from my distro. Still I have no idea what went wrong. I will play a little bit more with mesa and see if I stumble on anything useful on why this wasn't working...

I've found the culprit for the problem and reopened the bug because of this. Perhaps it's worth opening a new bug or report a bug for gcc. The problem is the following:
-I'm running Archlinux 32 Bit
-When I use "-mfpmath=sse" as an option for my CFLAGS and CXXFLAGS the game will crash. Only exception is when I select a processor type which doesn't support SSE as "-march" option. "-mmmx", "-msse", "-msse2" and "-msse3" have no influence on the behaviour (I'm not sure if those options are only valid when used in conjunction with some other option?)

I guess it should be filed as a gcc bug. Does any other version of gcc work with the switch?

(In reply to comment #20)
> -When I use "-mfpmath=sse" as an option ...

This flag is not going to make anything faster. Don't use it. (Citation: I'm a Gentoo developer.)

Ok, so obviously this doesn't seem to be a mesa bug. So I think this bug report can be closed.