https://bugs.freedesktop.org/show_bug.cgi?id=99055
--- Comment #20 from Kenneth Graunke ---
(In reply to Eero Tamminen from comment #17)
> (In reply to Kenneth Graunke from comment #15)
> > Renaming the binaries or editing scripts installed with the game is liable
> > to break when new updates fo
https://bugs.freedesktop.org/show_bug.cgi?id=99055
--- Comment #19 from Eero Tamminen ---
There are also few other libraries which too old versions can cause problems.
E.g. some X ones, if you're using DRI3. Could you attach the list of libraries
used by your game?
You can find out the DRI ver
https://bugs.freedesktop.org/show_bug.cgi?id=99055
--- Comment #18 from Etienne Bruines ---
It turns out to be using this library (and nothing that shipped with it) :
/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.22
The libraries in use are all part of the distro.
--
You are receiving this mail b
https://bugs.freedesktop.org/show_bug.cgi?id=99055
--- Comment #17 from Eero Tamminen ---
(In reply to Kenneth Graunke from comment #15)
> Renaming the binaries or editing scripts installed with the game is liable
> to break when new updates for the game comes out, because Steam will
> overwrite
https://bugs.freedesktop.org/show_bug.cgi?id=99055
--- Comment #16 from Michel Dänzer ---
Setting LD_PRELOAD when launching Steam has worked for every game I've tried so
far. YMMV.
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug._
https://bugs.freedesktop.org/show_bug.cgi?id=99055
--- Comment #15 from Kenneth Graunke ---
(In reply to Eero Tamminen from comment #14)
> It's harder to guarantee that the environment variable gets always passed to
> the game, better just to rename the offending binary to be sure.
It's really e
https://bugs.freedesktop.org/show_bug.cgi?id=99055
--- Comment #14 from Eero Tamminen ---
(In reply to Michel Dänzer from comment #13)
> Note that it's not really necessary to remove anything from the Steam
> directory; one can force using the system libraries via the LD_PRELOAD
> environment var
https://bugs.freedesktop.org/show_bug.cgi?id=99055
--- Comment #13 from Michel Dänzer ---
Note that it's not really necessary to remove anything from the Steam
directory; one can force using the system libraries via the LD_PRELOAD
environment variable, e.g.
LD_PRELOAD='/usr/$LIB/libstdc++.so.6':
https://bugs.freedesktop.org/show_bug.cgi?id=99055
Eero Tamminen changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=99055
--- Comment #11 from Michel Dänzer ---
(In reply to Etienne Bruines from comment #8)
> The issue was introduced after updating all package, among which most likely
> glibc ones. However, I was unable to find any glibc package on my computer.
The
https://bugs.freedesktop.org/show_bug.cgi?id=99055
--- Comment #10 from Etienne Bruines ---
> Do you mean that the freeze happens also with latest Mesa, it just takes a
> bit more time?
The freeze also happens, it just takes a bit more time, yes. Meaning: a while
it's running like it should, an
https://bugs.freedesktop.org/show_bug.cgi?id=99055
--- Comment #9 from Eero Tamminen ---
(In reply to Etienne Bruines from comment #8)
> However, it was brought to my attention that this issue wasn't fixed, just
> delayed a bit :-(
> This time it lasted 45 minutes before freezing.
Do you mean
https://bugs.freedesktop.org/show_bug.cgi?id=99055
Etienne Bruines changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://bugs.freedesktop.org/show_bug.cgi?id=99055
--- Comment #7 from Eero Tamminen ---
(In reply to Etienne Bruines from comment #5)
> Created attachment 128433 [details]
> Backtrace upon crash
If that's the whole backtrace command output, deadlock doesn't seem be be in
Mesa, at least in the F
https://bugs.freedesktop.org/show_bug.cgi?id=99055
Etienne Bruines changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=99055
--- Comment #5 from Etienne Bruines ---
Created attachment 128433
--> https://bugs.freedesktop.org/attachment.cgi?id=128433&action=edit
Backtrace upon crash
--
You are receiving this mail because:
You are the assignee for the bug.
You are the
https://bugs.freedesktop.org/show_bug.cgi?id=99055
--- Comment #4 from Etienne Bruines ---
@Eero Tamminen:
I have attached gdb. Upon crashing, one of these two errors was shown in gdb:
# This is the first error
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
0x7f
https://bugs.freedesktop.org/show_bug.cgi?id=99055
Eero Tamminen changed:
What|Removed |Added
CC||eero.t.tammi...@intel.com
--
You are re
https://bugs.freedesktop.org/show_bug.cgi?id=99055
--- Comment #3 from Eero Tamminen ---
Could you attach to the game process with GDB:
sudo gdb PATH PID
(PID is the game process ID. PATH is path to the game binary:
ls -l /proc/PID/exe
)
And attach here backtrace for all the threads:
(gdb
https://bugs.freedesktop.org/show_bug.cgi?id=99055
--- Comment #2 from Timothy Arceri ---
(In reply to Etienne Bruines from comment #0)
>
> I'd be happy to provide any additional information.
The most helpful thing you could do is build mesa from source and bisect the
commit that introduces the
https://bugs.freedesktop.org/show_bug.cgi?id=99055
--- Comment #1 from Etienne Bruines ---
Update: apitrace did not magically fix it, but it did delay the symptom by a
few hours.
--
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
https://bugs.freedesktop.org/show_bug.cgi?id=99055
Bug ID: 99055
Summary: Games hang / freeze completely
Product: Mesa
Version: 13.0
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Severity: major
22 matches
Mail list logo
