Arch Linux

Please provide a log file or some output containing the error.

Unfortunately, there is no error message. I do have a dump file left behind by steam which winedbg allows me to interrogate, with the following result:


$ winedbg crash_steam.exe_20111220183508_2.dmp
WineDbg starting on minidump on pid 0008
Steam.exe was running on #4 Intel Pentium Pro/II or AMD Athlon (42.7) CPUs on Windows XP (2600)
Register dump:
CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b
EIP:7cb72aa1 ESP:0033c878 EBP:00000000 EFLAGS:00010202( R- -- I - - - )
EAX:7bbed4d8 EBX:7d7ddff4 ECX:00000001 EDX:7bbed4d8
ESI:7bb8f440 EDI:7bbed4d8
Stack dump:
0x0033c878: 7bbed4d8 0003c000 00008092 ffffffff
0x0033c888: 00000000 7bb2dfa8 00000002 00000000
0x0033c898: 7bbe8650 7bbe8838 47000000 00000000
0x0033c8a8: 00000000 7c6e40f3 00000000 00000002
0x0033c8b8: 00000000 00000028 7cd8d83b 7d7ddff4
0x0033c8c8: 00000000 00000000 00000002 00000010
000c: sel=0067 base=00000000 limit=00000000 32-bit r--
Backtrace:
=>0 0x7cb72aa1 in r600_dri.so (+0x143aa1) (0x00000000)
WineDbg starting on pid 0008
Wine-dbg>

That's the entire backtrace, I'm afraid.

Ok, I can offer a slightly easier test.

Running FurMark (still needs wine, but it's a small download) crashes immediately with lib32-mesa 7.11.2-2 installed:


wine: Unhandled page fault on read access to 0xffffffff at address 0x7cf2aaa1 (thread 0009), starting debugger...
Unhandled exception: page fault on read access to 0xffffffff in 32-bit code (0x7cf2aaa1).
Register dump:
CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b
EIP:7cf2aaa1 ESP:0033de7c EBP:00000000 EFLAGS:00210202( R- -- I - - - )
EAX:7c8fce98 EBX:7db95ff4 ECX:00000001 EDX:7c8fce98
ESI:7ca52958 EDI:7c8fce98
Stack dump:
0x0033de7c: 7c8fce98 0003c000 00008092 ffffffff
0x0033de8c: 00000000 7ca414d0 00000002 00000000
0x0033de9c: 7c8fcc38 7c8fce20 47000000 00000000
0x0033deac: 00000000 7cbe40f3 00000000 00000002
0x0033debc: 00000000 00000028 7d14583b 7db95ff4
0x0033decc: 00000000 00000000 00000002 00000010
Backtrace:
=>0 0x7cf2aaa1 in r600_dri.so (+0x143aa1) (0x00000000)
0x7cf2aaa1:
Modules:
Module Address Debug info Name (87 modules)
PE 400000- 79b000 Deferred furmark
PE 7a0000- 985000 Deferred freeimage
PE 10000000-10228000 Deferred core3d
ELF 7b800000-7b9c4000 Deferred kernel32<elf>
\-PE 7b810000-7b9c4000 \ kernel32
ELF 7bc00000-7bcd2000 Deferred ntdll<elf>
\-PE 7bc10000-7bcd2000 \ ntdll
ELF 7bf00000-7bf04000 Deferred <wine-loader>
ELF 7cde7000-7dc16000 Dwarf r600_dri.so
ELF 7dc16000-7dc4c000 Deferred uxtheme<elf>
\-PE 7dc20000-7dc4c000 \ uxtheme
ELF 7dc4c000-7dc57000 Deferred libxcursor.so.1
ELF 7dc91000-7dcba000 Deferred libexpat.so.1
ELF 7dcba000-7dce8000 Deferred libfontconfig.so.1
ELF 7dce8000-7dcf8000 Deferred libxi.so.6
ELF 7dcf8000-7dd01000 Deferred libxrandr.so.2
ELF 7dd01000-7dd09000 Deferred libxrender.so.1
ELF 7dd09000-7dd2d000 Deferred imm32<elf>
\-PE 7dd10000-7dd2d000 \ imm32
ELF 7dd2d000-7dddc000 Deferred winex11<elf>
\-PE 7dd40000-7dddc000 \ winex11
ELF 7dddc000-7ddec000 Deferred libbz2.so.1.0
ELF 7ddec000-7de01000 Deferred libz.so.1
ELF 7de01000-7de9d000 Deferred libfreetype.so.6
ELF 7de9d000-7ded1000 Deferred ws2_32<elf>
\-PE 7dea0000-7ded1000 \ ws2_32
ELF 7ded1000-7df43000 Deferred shlwapi<elf>
\-PE 7dee0000-7df43000 \ shlwapi
ELF 7df43000-7e16e000 Deferred shell32<elf>
\-PE 7df50000-7e16e000 \ shell32
ELF 7e16e000-7e19a000 Deferred msvfw32<elf>
\-PE 7e170000-7e19a000 \ msvfw32
ELF 7e19a000-7e1bd000 Deferred iphlpapi<elf>
\-PE 7e1a0000-7e1bd000 \ iphlpapi
ELF 7e1bd000-7e302000 Deferred wined3d<elf>
\-PE 7e1d0000-7e302000 \ wined3d
ELF 7e302000-7e33f000 Deferred d3d9<elf>
\-PE 7e310000-7e33f000 \ d3d9
ELF 7e33f000-7e369000 Deferred msacm32<elf>
\-PE 7e340000-7e369000 \ msacm32
ELF 7e369000-7e3e6000 Deferred rpcrt4<elf>
\-PE 7e370000-7e3e6000 \ rpcrt4
ELF 7e3e6000-7e50d000 Deferred ole32<elf>
\-PE 7e400000-7e50d000 \ ole32
ELF 7e50d000-7e5b6000 Deferred winmm<elf>
\-PE 7e510000-7e5b6000 \ winmm
ELF 7e5b6000-7e5bc000 Deferred libuuid.so.1
ELF 7e5bc000-7e5d3000 Deferred libice.so.6
ELF 7e5d3000-7e5da000 Deferred libsm.so.6
ELF 7e5da000-7e6b0000 Deferred opengl32<elf>
\-PE 7e5f0000-7e6b0000 \ opengl32
ELF 7e6b0000-7e6b9000 Deferred librt.so.1
ELF 7e6b9000-7e6be000 Deferred libxdmcp.so.6
ELF 7e6be000-7e6c1000 Deferred libxau.so.6
ELF 7e6c1000-7e6ce000 Deferred libdrm.so.2
ELF 7e6ce000-7e6e6000 Deferred libxcb.so.1
ELF 7e6e6000-7e6f7000 Deferred libxcb-glx.so.0
ELF 7e6f7000-7e82f000 Deferred libx11.so.6
ELF 7e82f000-7e832000 Deferred libx11-xcb.so.1
ELF 7e832000-7e837000 Deferred libxxf86vm.so.1
ELF 7e837000-7e84a000 Deferred libxext.so.6
ELF 7e84a000-7e860000 Deferred libglapi.so.0
ELF 7e860000-7e87b000 Deferred libgcc_s.so.1
ELF 7e965000-7e9bc000 Deferred libgl.so.1
ELF 7e9bc000-7ea30000 Deferred libglu.so.1
ELF 7ea4a000-7ea62000 Deferred glu32<elf>
\-PE 7ea50000-7ea62000 \ glu32
ELF 7ea62000-7eb2a000 Deferred gdi32<elf>
\-PE 7ea70000-7eb2a000 \ gdi32
ELF 7eb2a000-7ec7c000 Deferred user32<elf>
\-PE 7eb40000-7ec7c000 \ user32
ELF 7ec7c000-7ed7d000 Deferred comctl32<elf>
\-PE 7ec80000-7ed7d000 \ comctl32
ELF 7ed7d000-7ede6000 Deferred advapi32<elf>
\-PE 7ed90000-7ede6000 \ advapi32
ELF 7efab000-7efb8000 Deferred libnss_files.so.2
ELF 7efb8000-7efe6000 Deferred libm.so.6
ELF 7efe6000-7f000000 Deferred version<elf>
\-PE 7eff0000-7f000000 \ version
ELF f7493000-f7498000 Deferred libdl.so.2
ELF f7498000-f7615000 Deferred libc.so.6
ELF f7615000-f7630000 Deferred libpthread.so.0
ELF f7640000-f7646000 Deferred libxfixes.so.3
ELF f7646000-f7649000 Deferred libxdamage.so.1
ELF f764a000-f778d000 Dwarf libwine.so.1
ELF f778e000-f77af000 Deferred ld-linux.so.2
ELF f77af000-f77b0000 Deferred [vdso].so
Threads:
process tid prio (all id:s are in hex)
00000008 (D) C:\FurMark_1.9.1\FurMark.exe
00000009 0 <==
0000000e services.exe
0000001e 0
0000001d 0
00000018 0
00000017 0
00000015 0
00000010 0
0000000f 0
00000012 winedevice.exe
00000019 0
00000014 0
00000013 0
0000001a plugplay.exe
0000001f 0
0000001c 0
0000001b 0
00000020 explorer.exe
00000021 0
Backtrace:
=>0 0x7cf2aaa1 in r600_dri.so (+0x143aa1) (0x00000000)


Same backtrace, same location.

Can you try packages from this directory ?, they are built from a snapshot of mesa stable tree with llvm officials fixes.

http://pkgbuild.com/~lcarlier/lib32-mesa-test/

It being that time of year, this'll have to wait until next week, but should be able to give that a shot Tuesday with luck.

I used packages Laurent Carlier provided and bug still persist.

Alas, can confirm Kamil's response. Tested FurMark again, generates same backtrace as before:

...
=>0 0x7cde9aa1 in r600_dri.so (+0x143aa1) (0x00000000)

I installed lib32-ati-dri-7.11.2-3-x86_64.pkg.tar.xz, lib32-libgl-7.11.2-3-x86_64.pkg.tar.xz, lib32-libglapi-7.11.2-3-x86_64.pkg.tar.xz, lib32-mesa-7.11.2-3-x86_64.pkg.tar.xz.

My problems with lib32 mesa git also have begun since llvm 3.0: I cannot start trackmania nations or warcraft 3 in wine anymore.
HD 6550 mobile.

Before llvm 3.0 (don't know if llvm 3.0 is the cause, it's just that it started at that time) it worked fine. Here is a lib32 mesa git build that works for me:
http://spiralinear.org/perry3d/x86_64/lib32-mesa-full-20111206-1-x86_64.pkg.tar.xz

Would be nice if we could narrow it down a bit, so here is a demo of warcraft 3 that is affected: http://www.fileplanet.com/117491/110000/fileinfo/Warcraft-3:-Reign-of-Chaos-Demo (should be started with -opengl).

Furmark won't work for me either.

But here is the curious thing: warcraft 3 and furmark work fine when using wine with WINEDEBUG=+all, though it is really slow of course.

@Araneidae , dither , Cdh

I've uploaded new packages (beware, same name!), but with debugging symbol added, please try if it can provide a better trace.
Also, nothing useful in the kernel log ?

Again, that time of year, will look on Tuesday. Didn't think to look in the logs. Any logs in particular, or just `dmesg` and /var/log/messages?

dmesg output should be enough

Turns out I have an hour this morning. Well, that was different. The first libraries you gave me crash in FurMark before even bringing up the initial window where you select the action, but the newest batch didn't crash until I tried to actually run the benchmark. Unfortunately the backtrace is even less illuminating than before:

Backtrace:
=>0 0x7db5f0d3 (0x00ece009)
1 0x2c7ad43e (0xf400ece0)

I've attached a complete transcript in "crash", and for comparison (because normal wine is fairly noisy) the output from a successful run in "normal".

For reference, the actual test I'm running is: run FurMark in wine, select windowed (not full screen) at reasonable resolution (1280x1024) and run "Benchmark (no preset)".

I'm afraid there's nothing at all (after the startup messages) in dmesg or any other log file in /var/log.

For what it's worth, I'm not restarting X after changing Mesa libraries. For completeness will try that now.

> For what it's worth, I'm not restarting X after changing Mesa libraries. For completeness will try that now.

No, not the slightest difference.

Well, for me it is still crashing before even bringing up the main window:

$ wine FurMark.exe
fixme:heap:HeapSetInformation (nil) 1 (nil) 0
fixme:win:EnumDisplayDevicesW ((null),0,0x32eaf0,0x00000000), stub!
err:wgl:X11DRV_wglGetPixelFormatAttribivARB (0x3d8): unexpected iPixelFormat(0) vs nFormats(175), returns FALSE
wine: Unhandled page fault on read access to 0xffffffff at address 0x7c7cbd89 (thread 0009), starting debugger...
Unhandled exception: page fault on read access to 0xffffffff in 32-bit code (0x7c7cbd89).

Read access to 0xffffffff? Seems broken.

Backtrace is still not good:
Backtrace:
=>0 0x7c7cbd89 in r600_dri.so (+0x145d89) (0x00000000)

Still...
This is crashing exactly the same:
WINEDEBUG=+all wine FurMark.exe &> /dev/null
While this brings up the main window fine:
WINEDEBUG=+all wine FurMark.exe &> winedebug.txt
(But on actually running the benchmark it crashes too).

Currently filled a bug upstream
https://bugs.freedesktop.org/show_bug.cgi?id=44466

I don't know currently if it's a problem in llvm or mesa...

Upstream seems to wait for a reply: https://bugs.freedesktop.org/show_bug.cgi?id=44466

This only seems to happen when the lib32-mesa packages are compiled with -O2, with -O1 no crash happens.

Sigh. Version 7.11.2-3 also crashes, in the same way:

Running FurMark generates the attached backtrace. Again we have

=>0 0x7cd54b41 in r600_dri.so (+0x143b41) (0x00000000)

Happens with Starcraft 2 too, as described here: https://bugs.archlinux.org/task/28527 and here: http://bugs.winehq.org/show_bug.cgi?id=29982


I can also confirm, that when rebuilding the same packages from ABS (in my case 8.0.1 as I'm using testing) with O1 level enabled instead of O2, the bug disappears.

lib32-mesa-8.0.1-1
x86_64 r300g
wine 1.3.37-1 1.4rc6-1
World of Warcraft

apitrace log file (https://github.com/apitrace/apitrace): http://46.182.19.135/Arch/wow.trace
backtrace (glretrace): https://gist.github.com/96c7d4ca92dd6523fce2

I am using ati 4350, and mesa 8.0 from stable repo (updated today) and I am continue experiencing this bug with wine + rail road tycoon 3 (not a steam game). It seems that all r600 ati cards are affected.

Possibly worth recording that the backtrace from running FurMark with mesa-8.0.1-2 is a little bit longer, so may contain information:


Backtrace:
=>0 0x7ccedddc in r600_dri.so (+0x145ddc) (0x00000000)
1 0x7cf0a1f6 in r600_dri.so (+0x3621f5) (0x7ca54cd0)
2 0x7cce017d in r600_dri.so (+0x13817c) (0x7ca54cd0)
3 0x7cd21eb8 in r600_dri.so (+0x179eb7) (0x00000001)
4 0x7cd0e0cd in r600_dri.so (+0x1660cc) (0x7ca86220)
5 0x7ccdc849 in r600_dri.so (+0x134848) (0x00000000)
6 0x7ccdc997 in r600_dri.so (+0x134996) (0x7c8f9978)
7 0x7ccdc9cf in r600_dri.so (+0x1349ce) (0x7c8f9978)
8 0x7e994996 in libgl.so.1 (+0x40995) (0x7c8f9978)
9 0x7e96c241 in libgl.so.1 (+0x18240) (0x00000000)
10 0x7e96ca85 glXCreateContext+0x84() in libgl.so.1 (0x0033eec0)
11 0x7dd4ad02 in winex11 (+0x2ad01) (0x0033eec0)
12 0x7dd4f4fa in winex11 (+0x2f4f9) (0x0033ef20)
13 0x7eadb6a2 wglCreateContext+0x61() in gdi32 (0x0033ef60)
14 0x7e63e97e in opengl32 (+0x6e97d) (0x0033ef80)
15 0x00434c77 in furmark (+0x34c76) (0x00400000)
16 0x00000003 (0x00905a4d)
17 0xfd3bfd3b (0xfd3bfd3b)

Any progress on this upstream?

Still not resolved in stock 8.0.2. After recompiling lib32-mesa-8.0.2 from ABS using -O1, 3D apps in wine work fine.

I confirm what Peter Kraus said; after building with -O1 Starcrat II works fine -- only lib32-ati-dri needs to be updated... Weird.

I guess this bug is related to lib32-llvm that don't expose the correct platform during runtime.

Please try the packages available here:
http://pkgbuild.com/~lcarlier/lib32-mesa-test/

Alas:


Unhandled exception: page fault on read access to 0xffffffff in 32-bit code (0x7cb78aff).
Register dump:
CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b
EIP:7cb78aff ESP:0033e968 EBP:00000000 EFLAGS:00210242( R- -- I Z- - - )
EAX:7dc628b0 EBX:7d8a2ff4 ECX:00000001 EDX:00000000
ESI:0033ea5c EDI:7dc628b0
Stack dump:
0x0033e968: 7dc628b0 0003c004 00008092 ffffffff
0x0033e978: 00000000 00000000 00028b70 0000aa00
0x0033e988: ffffffff 00000041 00000000 00000000
0x0033e998: 00000000 7cd90376 7c901820 7dc5ec60
0x0033e9a8: 00000000 00000000 00000000 00ffff00
0x0033e9b8: 00000000 00000000 00000002 00000010
Backtrace:
=>0 0x7cb78aff in r600_dri.so (+0x155aff) (0x00000000)
1 0x7cd935c4 in r600_dri.so (+0x3705c3) (0x7c901690)
2 0x7cb6b20d in r600_dri.so (+0x14820c) (0x7dba41b8)
3 0x7cbac360 in r600_dri.so (+0x18935f) (0x7d885440)
4 0x7cb9870a in r600_dri.so (+0x175709) (0x7d885440)
5 0x7cb67509 in r600_dri.so (+0x144508) (0x00000000)
6 0x7cb67677 in r600_dri.so (+0x144676) (0x00000000)
7 0x7cb676af in r600_dri.so (+0x1446ae) (0x00000000)
8 0x7e98cbde in libgl.so.1 (+0x3fbdd) (0x00000000)
9 0x7e965229 in libgl.so.1 (+0x18228) (0x00000021)
10 0x7e965a85 glXCreateContext+0x84() in libgl.so.1 (0x0033eec0)
11 0x7dcbdfe2 in winex11 (+0x2dfe1) (0x0033eec0)
12 0x7dcc25da in winex11 (+0x325d9) (0x0033ef20)
13 0x7ead7ab2 wglCreateContext+0x61() in gdi32 (0x0033ef60)
14 0x7e638fde in opengl32 (+0x68fdd) (0x0033ef80)
15 0x00434c77 in furmark (+0x34c76) (0x00400000)
16 0x00000003 (0x00905a4d)
17 0xfd3bfd3b (0xfd3bfd3b)

That's with lib32-{ati-dri,libgl,libglapi,libgles,mesa}-8.0.2-2-x86_64 installed.

Can you try now with -3 version ? Now O1 is forced for CFLAGS and CXXFLAGS
It works now for my E450 CPU/GPU.

http://pkgbuild.com/~lcarlier/lib32-mesa-test/

> Can you try now with -3 version?

Well, what can I say ... it works!

I'm a bit bemused about the relationship between setting optimisation to -O1 and the related task https://bugs.archlinux.org/task/29951 (broken host architecture tuple). I'll test it some more, but this is very promising.

The fact is there is two bugs, one in lib32-llvm (triplet bug), and another with an "unsupported" gcc flag.

I've pushed 8.0.3 in the repos with fixed lib32-llvm and O1 flag passed to gcc.

Now closing! \o/