Community Packages

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#27645 - [lib32-mesa] 7.11.2-2 breaks Steam browser on Cayman card

Attached to Project: Community Packages
Opened by Michael Abbott (Araneidae) - Tuesday, 20 December 2011, 20:00 GMT
Last edited by Laurent Carlier (lordheavy) - Tuesday, 22 May 2012, 18:17 GMT
Task Type Bug Report
Category Packages: Multilib
Status Closed
Assigned To Florian Pritz (bluewind)
Laurent Carlier (lordheavy)
Architecture x86_64
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 7
Private No



After installing the lib32-mesa components (lib32-ati-dri, lib32-libgl, lib32-libglapi, lib32-mesa) with version 7.11.2-2, running the Steam client crashes in

Rolling back these components to version 7.11.2-1 eliminates this crash. Looking at the history for lib32-mesa it seems the only significant change is adding the patch

It is probably significant that I am using a Cayman (Radeon 6950) card, as the crash is in r600_dri.

Additional info:
* package version(s)
7.11.2-2 vs 7.11.2-1

* config and/or log files etc.

Steps to reproduce:

It is necessary to install wine and steam on a system with a Radeon 6950 with the Radeon ATI driver. After logging on to steam the browser crashes before displaying.
This task depends upon

Closed by  Laurent Carlier (lordheavy)
Tuesday, 22 May 2012, 18:17 GMT
Reason for closing:  Fixed
Additional comments about closing:  lib32-mesa-8.0.3-3
Comment by Florian Pritz (bluewind) - Wednesday, 21 December 2011, 14:25 GMT
Please provide a log file or some output containing the error.
Comment by Michael Abbott (Araneidae) - Wednesday, 21 December 2011, 16:05 GMT
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--
=>0 0x7cb72aa1 in (+0x143aa1) (0x00000000)
WineDbg starting on pid 0008

That's the entire backtrace, I'm afraid.
Comment by Michael Abbott (Araneidae) - Wednesday, 21 December 2011, 18:16 GMT
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
=>0 0x7cf2aaa1 in (+0x143aa1) (0x00000000)
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
ELF 7dc16000-7dc4c000 Deferred uxtheme<elf>
\-PE 7dc20000-7dc4c000 \ uxtheme
ELF 7dc4c000-7dc57000 Deferred
ELF 7dc91000-7dcba000 Deferred
ELF 7dcba000-7dce8000 Deferred
ELF 7dce8000-7dcf8000 Deferred
ELF 7dcf8000-7dd01000 Deferred
ELF 7dd01000-7dd09000 Deferred
ELF 7dd09000-7dd2d000 Deferred imm32<elf>
\-PE 7dd10000-7dd2d000 \ imm32
ELF 7dd2d000-7dddc000 Deferred winex11<elf>
\-PE 7dd40000-7dddc000 \ winex11
ELF 7dddc000-7ddec000 Deferred
ELF 7ddec000-7de01000 Deferred
ELF 7de01000-7de9d000 Deferred
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
ELF 7e5bc000-7e5d3000 Deferred
ELF 7e5d3000-7e5da000 Deferred
ELF 7e5da000-7e6b0000 Deferred opengl32<elf>
\-PE 7e5f0000-7e6b0000 \ opengl32
ELF 7e6b0000-7e6b9000 Deferred
ELF 7e6b9000-7e6be000 Deferred
ELF 7e6be000-7e6c1000 Deferred
ELF 7e6c1000-7e6ce000 Deferred
ELF 7e6ce000-7e6e6000 Deferred
ELF 7e6e6000-7e6f7000 Deferred
ELF 7e6f7000-7e82f000 Deferred
ELF 7e82f000-7e832000 Deferred
ELF 7e832000-7e837000 Deferred
ELF 7e837000-7e84a000 Deferred
ELF 7e84a000-7e860000 Deferred
ELF 7e860000-7e87b000 Deferred
ELF 7e965000-7e9bc000 Deferred
ELF 7e9bc000-7ea30000 Deferred
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
ELF 7efb8000-7efe6000 Deferred
ELF 7efe6000-7f000000 Deferred version<elf>
\-PE 7eff0000-7f000000 \ version
ELF f7493000-f7498000 Deferred
ELF f7498000-f7615000 Deferred
ELF f7615000-f7630000 Deferred
ELF f7640000-f7646000 Deferred
ELF f7646000-f7649000 Deferred
ELF f764a000-f778d000 Dwarf
ELF f778e000-f77af000 Deferred
ELF f77af000-f77b0000 Deferred [vdso].so
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
=>0 0x7cf2aaa1 in (+0x143aa1) (0x00000000)

Same backtrace, same location.
Comment by Laurent Carlier (lordheavy) - Thursday, 22 December 2011, 20:57 GMT
Can you try packages from this directory ?, they are built from a snapshot of mesa stable tree with llvm officials fixes.
Comment by Michael Abbott (Araneidae) - Thursday, 22 December 2011, 22:45 GMT
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.
Comment by Kamil Endruszkiewicz (dither) - Saturday, 24 December 2011, 15:05 GMT
I used packages Laurent Carlier provided and bug still persist.
Comment by Michael Abbott (Araneidae) - Tuesday, 27 December 2011, 13:08 GMT
Alas, can confirm Kamil's response. Tested FurMark again, generates same backtrace as before:

=>0 0x7cde9aa1 in (+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.
Comment by h (Cdh) - Tuesday, 27 December 2011, 14:53 GMT
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:

Would be nice if we could narrow it down a bit, so here is a demo of warcraft 3 that is affected: (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.
Comment by Laurent Carlier (lordheavy) - Thursday, 29 December 2011, 22:28 GMT
@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 ?
Comment by Michael Abbott (Araneidae) - Thursday, 29 December 2011, 22:49 GMT
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?
Comment by Laurent Carlier (lordheavy) - Thursday, 29 December 2011, 23:01 GMT
dmesg output should be enough
Comment by Michael Abbott (Araneidae) - Friday, 30 December 2011, 10:10 GMT
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:

=>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.
   crash (6.6 KiB)
   normal (0.9 KiB)
Comment by Michael Abbott (Araneidae) - Friday, 30 December 2011, 10:13 GMT
> 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.
Comment by h (Cdh) - Friday, 30 December 2011, 10:48 GMT
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:
=>0 0x7c7cbd89 in (+0x145d89) (0x00000000)

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).
Comment by Laurent Carlier (lordheavy) - Thursday, 05 January 2012, 18:00 GMT
Currently filled a bug upstream

I don't know currently if it's a problem in llvm or mesa...
Comment by Alexander F Rødseth (xyproto) (trontonic) - Friday, 13 January 2012, 15:26 GMT
Upstream seems to wait for a reply:
Comment by Filip Szczepański (FreeFull) - Wednesday, 08 February 2012, 17:35 GMT
This only seems to happen when the lib32-mesa packages are compiled with -O2, with -O1 no crash happens.
Comment by Michael Abbott (Araneidae) - Friday, 10 February 2012, 20:52 GMT
Sigh. Version 7.11.2-3 also crashes, in the same way:

Running FurMark generates the attached backtrace. Again we have

=>0 0x7cd54b41 in (+0x143b41) (0x00000000)
Comment by Peter Kraus (PetoKraus) - Wednesday, 29 February 2012, 21:38 GMT
Happens with Starcraft 2 too, as described here: and here:

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.
Comment by idostyle (idostyle) - Thursday, 08 March 2012, 22:45 GMT
x86_64 r300g
wine 1.3.37-1 1.4rc6-1
World of Warcraft

apitrace log file (
backtrace (glretrace):
Comment by Daniel (Barbrady) - Tuesday, 13 March 2012, 22:52 GMT
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.
Comment by Michael Abbott (Araneidae) - Thursday, 15 March 2012, 14:26 GMT
Possibly worth recording that the backtrace from running FurMark with mesa-8.0.1-2 is a little bit longer, so may contain information:

=>0 0x7ccedddc in (+0x145ddc) (0x00000000)
1 0x7cf0a1f6 in (+0x3621f5) (0x7ca54cd0)
2 0x7cce017d in (+0x13817c) (0x7ca54cd0)
3 0x7cd21eb8 in (+0x179eb7) (0x00000001)
4 0x7cd0e0cd in (+0x1660cc) (0x7ca86220)
5 0x7ccdc849 in (+0x134848) (0x00000000)
6 0x7ccdc997 in (+0x134996) (0x7c8f9978)
7 0x7ccdc9cf in (+0x1349ce) (0x7c8f9978)
8 0x7e994996 in (+0x40995) (0x7c8f9978)
9 0x7e96c241 in (+0x18240) (0x00000000)
10 0x7e96ca85 glXCreateContext+0x84() in (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?
Comment by Peter Kraus (PetoKraus) - Thursday, 22 March 2012, 15:20 GMT
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.
Comment by Felipe Contreras (felipec) - Sunday, 25 March 2012, 14:19 GMT
I confirm what Peter Kraus said; after building with -O1 Starcrat II works fine -- only lib32-ati-dri needs to be updated... Weird.
Comment by Laurent Carlier (lordheavy) - Sunday, 20 May 2012, 23:11 GMT
I guess this bug is related to lib32-llvm that don't expose the correct platform during runtime.

Please try the packages available here:
Comment by Michael Abbott (Araneidae) - Monday, 21 May 2012, 17:37 GMT

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
=>0 0x7cb78aff in (+0x155aff) (0x00000000)
1 0x7cd935c4 in (+0x3705c3) (0x7c901690)
2 0x7cb6b20d in (+0x14820c) (0x7dba41b8)
3 0x7cbac360 in (+0x18935f) (0x7d885440)
4 0x7cb9870a in (+0x175709) (0x7d885440)
5 0x7cb67509 in (+0x144508) (0x00000000)
6 0x7cb67677 in (+0x144676) (0x00000000)
7 0x7cb676af in (+0x1446ae) (0x00000000)
8 0x7e98cbde in (+0x3fbdd) (0x00000000)
9 0x7e965229 in (+0x18228) (0x00000021)
10 0x7e965a85 glXCreateContext+0x84() in (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.
Comment by Laurent Carlier (lordheavy) - Monday, 21 May 2012, 20:39 GMT
Can you try now with -3 version ? Now O1 is forced for CFLAGS and CXXFLAGS
It works now for my E450 CPU/GPU.
Comment by Michael Abbott (Araneidae) - Tuesday, 22 May 2012, 17:46 GMT
> 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 (broken host architecture tuple). I'll test it some more, but this is very promising.
Comment by Laurent Carlier (lordheavy) - Tuesday, 22 May 2012, 18:17 GMT
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/