| Summary: | Some fonts corrupted and X crashes (occasionally). | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | xorg | Reporter: | David Ronis <David.Ronis> | ||||||||
| Component: | Server/Acceleration/EXA | Assignee: | Xorg Project Team <xorg-team> | ||||||||
| Status: | RESOLVED FIXED | QA Contact: | Xorg Project Team <xorg-team> | ||||||||
| Severity: | critical | ||||||||||
| Priority: | medium | CC: | adf.lists, madman2003, simon.thum | ||||||||
| Version: | git | ||||||||||
| Hardware: | Other | ||||||||||
| OS: | All | ||||||||||
| Whiteboard: | |||||||||||
| i915 platform: | i915 features: | ||||||||||
| Attachments: |
|
||||||||||
|
Description
David Ronis
2009-11-29 09:46:22 UTC
Actually, make that the radeon driver. Created attachment 31553 [details]
Screenshot
Look at the window borders and/or menu bar. The text is garbled.
I'd be interested in seeing that backtrace with pixman symbols. Thanks, I don't know how to trigger the crash other than randomly at startup, and, in any event, a core file isn't left behind. Any suggestions how to get gdb to run from the get-go? Dropping a core file should be the right way to do this. I've also been having other issues with pixman (I think) and was able to get a detailed backtrace for it. Have a look at bug 25270. One more thing: any reason why Xorg is reporting such a meager backtrace? gdb's contains much more information (and all the key modules have been built with symbols). (In reply to comment #4) > I don't know how to trigger the crash other than randomly at startup, and, in > any event, a core file isn't left behind. Option "NoTrapSignals" may help. > One more thing: any reason why Xorg is reporting such a meager backtrace? AFAIK it's a limitation of the glibc backtrace facility. Asuming you have xserver commits 342f3689d17256c92cbfee079d24501d27aa1153, a54c23fe647cb4d610d871094193ae5959606008 and 99d88ef69d5f7dbf99ca605eceb92f42230a89f4, at least the visual corruption might be a regression of one of those. Would be great if you could confirm that and isolate the one which caused the problem. Two things: 1. Option "NoTrapSignals" doesn't result in a core file. 2. Reverting all 3 commits "fixes" the problem. I will try to narrow down which commit is responsible in a day or so. On Mon, Nov 30, 2009 at 09:42:39PM -0800, bugzilla-daemon@freedesktop.org wrote: > 1. Option "NoTrapSignals" doesn't result in a core file. To get core dumps you'll have to do two things: first, make sure you're running it from a root shell -- not with sudo, not running a suid binary as a user -- and secondly, run 'ulimit -c unlimited'. Maarten, any ideas so far what could be up? Maybe the last change doesn't mix well with classic drivers after all? Isolating it to a single commit would be nice. One (maybe unrelated) thing i saw is that exaModifyPixmapHeader_classic() doesn't pin a pixmap, which seems very odd. > --- Comment #7 from Daniel Stone <daniel@fooishbar.org> 2009-11-30 22:17:48 PST ---
> On Mon, Nov 30, 2009 at 09:42:39PM -0800, bugzilla-daemon@freedesktop.org
> wrote:
> > 1. Option "NoTrapSignals" doesn't result in a core file.
>
> To get core dumps you'll have to do two things: first, make sure you're
> running it from a root shell -- not with sudo, not running a suid binary
> as a user -- and secondly, run 'ulimit -c unlimited'.
The -core command line switch does all of that, iirc.
*** Bug 25372 has been marked as a duplicate of this bug. *** Maarten, looks like it's indeed commit 99d88ef69d5f7dbf99ca605eceb92f42230a89f4 which triggered it. Was there any problem or something in particular this change was supposed to address? It was supposed to address the odd situation (this doesn't mean bug) in which you prepare access, but do not have the right pitch set. It made sense to restrict to one place related to fallbacks and one for acceleration. I can make something else, but i do wonder why this is causing problems (in the worst case i would expect it to be redundant) Do you know if the problem is caused in acceleration or fallback code? (In reply to comment #13) > Do you know if the problem is caused in acceleration or fallback code? Not sure. Maarten, I see two basic ways forward: * You work with the bug submitters to fix the problem quickly. or * You submit a patch to revert this change on master. If you want to submit a similar change again, you have it tested by the bug submitters first to make sure it doesn't break again. Created attachment 31634 [details] [review] revert problematic changes Created attachment 31635 [details] [review] redo one change I was able to reproduce myself as well (forgot this driver still had a classic mode). Any serious hunting will have to wait a bit, until the weekend maybe. (In reply to comment #17) > Created an attachment (id=31635) [details] > redo a one change > It's working OK for me with the two patches. The git master with the 2 patches seem to work, although I did get some new crashes in mesa/drm applications. This may be a compiler issue, as I had some ICE's in building mesa at high levels of optimization. *** Bug 25397 has been marked as a duplicate of this bug. *** The fix has finally landed on xserver master. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.