Bug 505823 - xserver crash with gimp
Summary: xserver crash with gimp
Keywords:
Status: CLOSED DUPLICATE of bug 504300
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-server
Version: rawhide
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Adam Jackson
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 505413 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-06-14 06:34 UTC by Alexey Kuznetsov
Modified: 2018-04-11 11:19 UTC (History)
7 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2009-07-04 19:49:58 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Xorg.0.log (116.36 KB, text/plain)
2009-06-14 06:34 UTC, Alexey Kuznetsov
no flags Details
X crash log when clicking in the Gimp (175.38 KB, text/plain)
2009-06-16 07:14 UTC, Richard Schwarting
no flags Details
Xorg.conf (2.45 KB, text/plain)
2009-06-16 07:18 UTC, Richard Schwarting
no flags Details
gdb backtrace from the gimp when crashing Xephyr (3.10 KB, text/plain)
2009-06-16 08:58 UTC, Richard Schwarting
no flags Details
gdb session with a crashing Xephyr (8.99 KB, text/plain)
2009-06-16 09:42 UTC, Richard Schwarting
no flags Details
Strace of Gimp process on click and crash (126.04 KB, text/plain)
2009-06-30 19:51 UTC, Hiran Arias
no flags Details
xsession-erros on click and crash (6.41 KB, text/plain)
2009-06-30 19:52 UTC, Hiran Arias
no flags Details

Description Alexey Kuznetsov 2009-06-14 06:34:07 UTC
Created attachment 347802 [details]
Xorg.0.log

run gimp
create new empty image
select "Paintbruh" and make one click on image - sever crash :(((

Comment 1 Alexey Kuznetsov 2009-06-14 07:26:55 UTC
can be related only to -intel driver

Comment 2 Richard Schwarting 2009-06-16 07:08:53 UTC
Bug 505413 had this happen on radeonhd as well, so I don't think it's only intel specific.

Comment 3 Richard Schwarting 2009-06-16 07:14:40 UTC
Created attachment 348050 [details]
X crash log when clicking in the Gimp

Here you are.  

My system is this:
IBM Thinkpad X41t tablet
Fedora 11 (upgraded from Fedora 10, so not a fresh install)
Dual-head setup (with a minimally edited xorg.conf file, to be uploaded)

Video card data from lspci -vv: 

00:02.0 VGA compatible controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 03) (prog-if 00 [VGA controller])
        Subsystem: IBM Device 0582
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0
        Interrupt: pin A routed to IRQ 16
        Region 0: Memory at a0080000 (32-bit, non-prefetchable) [size=512K]
        Region 1: I/O ports at 1800 [size=8]
        Region 2: Memory at c0000000 (32-bit, prefetchable) [size=256M]
        Region 3: Memory at a0000000 (32-bit, non-prefetchable) [size=256K]
        Expansion ROM at <unassigned> [disabled]
        Capabilities: [d0] Power Management version 2
                Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
        Kernel driver in use: i915
        Kernel modules: i915

Comment 4 Richard Schwarting 2009-06-16 07:18:05 UTC
Created attachment 348051 [details]
Xorg.conf

I generated this using Xorg -configure so I could spec the second monitor and have an extended display (instead of mirrored) for GDM. 

OH!  And I also do not have Desktop Effects enabled, if that matters.

If there's anything else I can do, please let me know.

Comment 5 Alexey Kuznetsov 2009-06-16 07:21:38 UTC
i dont have desktop effects enabled

Comment 6 Nils Philippsen 2009-06-16 08:30:57 UTC
*** Bug 505413 has been marked as a duplicate of this bug. ***

Comment 7 Richard Schwarting 2009-06-16 08:58:08 UTC
Created attachment 348064 [details]
gdb backtrace from the gimp when crashing Xephyr

I've just run the Gimp in Xephyr and it crashes Xephyr as well.  I got a backtrace for both the Gimp and for Xephyr.  Here they are.

Comment 8 Richard Schwarting 2009-06-16 08:59:30 UTC
Er, my Xephyr backtrace actually kind of sucks:
#0  0x00000000 in ?? ()
#1  0x0808ca9d in GrabDevice ()
#2  0x08192831 in ProcXGrabDevice ()
#3  0x0818f1c3 in ?? ()
#4  0x080adcd7 in Dispatch ()
#5  0x080936e5 in main ()

I'll try to do better.

Comment 9 Richard Schwarting 2009-06-16 09:14:39 UTC
(gdb) bt
#0  0x00000000 in ?? ()
#1  0x0808ca9d in GrabDevice (client=0x929e6d0, dev=0x9290828, this_mode=1, other_mode=1, grabWindow=2097481, 
    ownerEvents=0, ctime=1960921, mask=264, 
    status=0xbfdfeff4 "\200>&\bH\360\337\277\256\242\21\b\204>&\b\30\360\337\277", coreGrab=0) at events.c:4692
#2  0x08192831 in ProcXGrabDevice (client=0x929e6d0) at grabdev.c:131
#3  0x0818f1c3 in ProcIDispatch (client=0xbfdfeea0) at extinit.c:349
#4  0x080adcd7 in Dispatch () at dispatch.c:437
#5  0x080936e5 in main (argc=2, argv=0xbfdff1c4, envp=0xbfdff1d0) at main.c:397

I didn't have rpm-devel installed anymore, apparently, so gdb couldn't tell me what packages I needed to debuginfo-install.  Fixed that, so here we are from a second run.

Comment 10 Richard Schwarting 2009-06-16 09:42:07 UTC
Created attachment 348070 [details]
gdb session with a crashing Xephyr

Here's a session of mine in gdb with my Xephyr process, with a breakpoint in GrabDevice, which seems to be the function in which Xephyr crashes.

I'll note that it seems to crash on me at source line 
|| 4692		(*grabInfo->ActivateGrab)(dev, &tempGrab, time, FALSE);

I'll note this source line
|| 4633	    GrabInfoPtr grabInfo = &dev->deviceGrab;
where grabInfo is set.  I cannot inspect it via gdb for some reason, though I can inspect &dev->deviceGrab

Anyway, running gdb again after the above log, I now note this:
|| (gdb) print *(&dev->deviceGrab)
|| $3 = {grabTime = {months = 0, milliseconds = 3120501}, fromPassiveGrab = 0, implicitGrab = 0, activeGrab = {next = 0x0, resource = 0, device = 0x0, window = 0x0, ownerEvents = 0, keyboardMode = 0, pointerMode = 0, coreGrab = 0, coreMods = 0, type = 0 '\0', modifiersDetail = {exact = 0, pMask = 0x0}, modifierDevice = 0x0, detail = {exact = 0, pMask = 0x0}, confineTo = 0x0, cursor = 0x0, eventMask = 0, deviceMask = 0, genericMasks = 0x0}, grab = 0x0, activatingKey = 0 '\0', ActivateGrab = 0, DeactivateGrab = 0, sync = {frozen = 0, state = 0, other = 0x0, event = 0x0, evcount = 0}}

So, yah, 
+ grabInfo = &dev->deviceGrab
+ *grabInfo = *(&dev->deviceGrab)
++ has ActivateGrab as a member whose value = 0
+ grabInfo is (GrabInfoRec *) or GrabInfoPtr, so
++ *grabInfo is just GrabInfoRec
+ line 4692 tries to dereference a GrabInfoRec, via "(*grabInfo)", and then access ActivateGrab.  This will fail!
||  (gdb) print *(&dev->deviceGrab)->ActivateGrab
||  Cannot access memory at address 0x0

Comment 11 Venkatesh Krishnamurthi 2009-06-27 07:46:15 UTC
I don't know if this adds much information but I encountered a similar crash with the nv and nouveau drivers on a nVidia G72 (GeForce 7300 SE). The workaround, as described in bug 489776, was to remove the xorg.conf file and let the X server use its default settings.

Comment 12 Hiran Arias 2009-06-30 19:32:47 UTC
I have changed the drivers from radeonhd to the radeon (xorg-x11-drv-ati) and have the same results. Composite is disabled and off-course Desktop Effects is also disabled.

Comment 13 Hiran Arias 2009-06-30 19:51:18 UTC
Created attachment 350017 [details]
Strace of Gimp process on click and crash

Comment 14 Hiran Arias 2009-06-30 19:52:27 UTC
Created attachment 350018 [details]
xsession-erros on click and crash

Comment 15 Hiran Arias 2009-07-01 15:57:52 UTC
Just upgraded gimp to version 2.6.6 from testing, same results X crash on click

Comment 16 Henrique Martins 2009-07-04 17:59:26 UTC
Should this be merged with bug 504300?  Seems to the the same problem, or at least the same symptoms.

Comment 17 Matěj Cepl 2009-07-04 19:49:58 UTC
(In reply to comment #16)
> Should this be merged with bug 504300?  Seems to the the same problem, or at
> least the same symptoms.  

yes, looks so. Thanks for catching this.

*** This bug has been marked as a duplicate of bug 504300 ***


Note You need to log in before you can comment on or make changes to this bug.