Bug 765973

Summary: radeon[R300] X11 segfaults when starting Firefox/Chromium etc.
Product: [openSUSE] openSUSE 12.2 Reporter: Tobias Burnus <burnus>
Component: X.OrgAssignee: E-mail List <xorg-maintainer-bugs>
Status: RESOLVED FIXED QA Contact: E-mail List <xorg-maintainer-bugs>
Severity: Critical    
Priority: P3 - Medium CC: michel
Version: Factory   
Target Milestone: ---   
Hardware: Other   
OS: Other   
Whiteboard:
Found By: --- Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---
Attachments: Xorg.2.log.old

Description Tobias Burnus 2012-06-07 16:33:09 UTC
Created attachment 494010 [details]
Xorg.2.log.old

User-Agent:       Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20100101 Firefox/12.0

The problem occurs with Factory since a couple of days. It seems to be identical to the one reported at https://bugs.freedesktop.org/show_bug.cgi?id=29251 and mentioned at http://forums.opensuse.org/english/get-technical-help-here/pre-release-beta/475735-opensuse-12-2-beta1-released-5.html

One can login and open an xterm/shell like normal. However, seconds after starting Firefox,Chromium, LibreOffice or Thunderbird, X crashes.


With current Factory (x86-64), I get the following backtrace. That's with:
X.Org X Server 1.12.2, Release Date: 2012-05-29 and using a "Radeon X300 (RV370) 5B60 (PCIE)".

Program received signal SIGSEGV, Segmentation fault.
radeon_get_pixmap_bo (pPix=<optimized out>) at radeon_exa.c:600
600         return driver_priv->bo;
(gdb) p driver_priv
$1 = (struct radeon_exa_pixmap_priv *) 0x0

The whole function is:

596     struct radeon_bo *radeon_get_pixmap_bo(PixmapPtr pPix)
597     {
598         struct radeon_exa_pixmap_priv *driver_priv;
599         driver_priv = exaGetPixmapDriverPrivate(pPix);
600         return driver_priv->bo;
601     }

The pPix map, which is passed to radeon_get_pixmap_bo contains:

(gdb) p pPix
$3 = (struct _Pixmap *) 0x2669be0
(gdb) p *pPix
$4 = {drawable = {type = 1 '\001', class = 0 '\000', depth = 32 ' ', bitsPerPixel = 32 ' ', id = 0, x = 0, y = 0, width = 1, height = 1, pScreen = 0x1b61390, serialNumber = 8956}, devPrivates = 0x2669c20, refcnt = 1, devKind = 64, devPrivate = {ptr = 0x0, val = 0, uval = 0, fptr = 0}, screen_x = 0, screen_y = 0, usage_hint = 0}


In exaGetPixmapDriverPrivate

#0  radeon_get_pixmap_bo (pPix=<optimized out>) at radeon_exa.c:600
#1  0x00007fe096798e2b in RADEONSolidPixmap (pScreen=0x19a9390, solid=4279505682) at radeon_exa_shared.c:135
#2  0x00007fe09677e09c in R300PrepareCompositeMMIO (op=3, pSrcPicture=0x26b7840, pMaskPicture=0x20917b0, pDstPicture=0x20a8ff0, pSrc=0x0, pMask=0x1f047d0, 
    pDst=0x25e32e0) at radeon_exa_render.c:1536
#3  0x00007fe095576dbd in exaTryDriverCompositeRects (op=3 '\003', pSrc=0x26b7840, pMask=0x20917b0, pDst=0x20a8ff0, nrect=26, rects=0x7fff2a730c38)
    at exa_render.c:430
#4  0x00007fe09557779c in exaCompositeRects (op=3 '\003', pSrc=0x26b7840, pMask=0x20917b0, pDst=0x20a8ff0, nrect=26, rects=0x7fff2a730c38) at exa_render.c:581
#5  0x00007fe095575b45 in exaGlyphsToDst (buffer=0x7fff2a730c30, pDst=0x20a8ff0, pSrc=0x26b7840) at exa_glyphs.c:623
#6  exaGlyphs (op=3 '\003', pSrc=0x26b7840, pDst=0x20a8ff0, maskFormat=0x0, xSrc=56, ySrc=26, nlist=<optimized out>, list=<optimized out>, glyphs=0x7fff2a732b10)
    at exa_glyphs.c:824
#7  0x00000000004f661d in damageGlyphs (op=3 '\003', pSrc=0x26b7840, pDst=0x20a8ff0, maskFormat=0x0, xSrc=56, ySrc=26, nlist=1, list=0x7fff2a732610, 
    glyphs=0x7fff2a732a10) at damage.c:628
#8  0x00000000004ef806 in ProcRenderCompositeGlyphs (client=0x20b56b0) at render.c:1389
#9  0x00000000004388a1 in Dispatch () at dispatch.c:428
#10 0x0000000000427965 in main (argc=6, argv=0x7fff2a733408, envp=<optimized out>) at main.c:288

Reproducible: Always
Comment 1 Tobias Burnus 2012-06-07 17:16:53 UTC
Given that the crash happens after RADEONSolidPixmap, the last change is a likely culprit. It also would fit time wise. Though at a glance of a complete stranger to the code, the code looks innocent; possibly, it is correct and one of the removed RADEON_FALLBACK reveals an old bug. (Or it could be a red herring.)


* Wed May 16 2012 idonmez@suse.com
- Add upstream patches to accelerate solid pictures, fixes color
  corruption problems with new cairo.

https://build.opensuse.org/package/rdiff?linkrev=base&package=xf86-video-ati&project=openSUSE%3AFactory&rev=2
Comment 2 Tobias Burnus 2012-06-07 17:52:50 UTC
> https://build.opensuse.org/package/rdiff?linkrev=base&package=xf86-video-ati&project=openSUSE%3AFactory&rev=2

"All theory, dear friend, is grey, but the golden tree of life springs ever green."

I (ab)used OSB to create a package without those four patches - and without them, X11 doesn't crash any more!
Comment 3 Stefan Dirsch 2012-06-08 08:53:30 UTC
Hmm. Since patches are already upstream, disabling them won't help much when the next driver is available.
Comment 4 Michel Dänzer 2012-06-08 10:35:04 UTC
Fixed upstream, see https://bugs.freedesktop.org/show_bug.cgi?id=49182 .
Comment 5 Stefan Dirsch 2012-06-08 11:53:21 UTC
Hmm. So you've booted with option "nomodeset"?
Comment 6 Tobias Burnus 2012-06-08 12:09:04 UTC
(In reply to comment #4 of Michel Dänzer)
> Fixed upstream, see https://bugs.freedesktop.org/show_bug.cgi?id=49182 .

Michael: Thanks for digging; I assume that you refer to the following patch / commit:
http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=6bda7ceda645e838723883d133d614def1511d16


(In reply to comment #5 of Stefan Dirsch)
> Hmm. So you've booted with option "nomodeset"?

Indeed, I must have set it at some point when it didn't work without.

If it makes sense, I can test with the patch and nomodeset - and/or without nomodeset using the patched or unpatched Factory rpm.
Comment 7 Stefan Dirsch 2012-06-08 13:22:36 UTC
Ok. I've added the patch to obs://X11:XOrg/xf86-video-intel and did a SR to openSUSE:Factory. Closing as fixed.
Comment 8 Michel Dänzer 2012-06-08 13:54:15 UTC
(In reply to comment #6)
> Michael: Thanks for digging; I assume that you refer to the following patch /
> commit:
> http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=6bda7ceda645e838723883d133d614def1511d16

Yes, but beware that this commit alone will result in rendering corruption with UMS. That was fixed in commit b0b7d8d26fd107df342b5c87b0a38e5bb08101a9.
Comment 9 Bernhard Wiedemann 2012-06-08 14:00:33 UTC
This is an autogenerated message for OBS integration:
This bug (765973) was mentioned in
https://build.opensuse.org/request/show/124218 Factory / xf86-video-ati
Comment 10 Stefan Dirsch 2012-06-08 14:16:38 UTC
(In reply to comment #8)
> (In reply to comment #6)
> > Michael: Thanks for digging; I assume that you refer to the following patch /
> > commit:
> > http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=6bda7ceda645e838723883d133d614def1511d16
> 
> Yes, but beware that this commit alone will result in rendering corruption with
> UMS. That was fixed in commit b0b7d8d26fd107df342b5c87b0a38e5bb08101a9.

==> reopen
Comment 11 Stefan Dirsch 2012-06-08 15:06:01 UTC
(In reply to comment #10)
> > Yes, but beware that this commit alone will result in rendering corruption with
> > UMS. That was fixed in commit b0b7d8d26fd107df342b5c87b0a38e5bb08101a9.

Added this patch now as well.
Comment 12 Bernhard Wiedemann 2012-06-08 16:00:16 UTC
This is an autogenerated message for OBS integration:
This bug (765973) was mentioned in
https://build.opensuse.org/request/show/124244 Factory / xf86-video-ati