Please post your xorg log and your xorg.conf
The best thing you could do is to log in from a remote SSH and do backtrace on
the X process after a crash. Then post it here. 

Created attachment 5059 [details]
Logfile of a crashed X

Created attachment 5060 [details]
/etc/X11/xorg.conf of the installation in question

(In reply to comment #1)
> Please post your xorg log and your xorg.conf
> The best thing you could do is to log in from a remote SSH and do backtrace on
> the X process after a crash. Then post it here. 

Erik, 
please see the files that I have attached.

As for the backtrace, can you tell me shortly how can I do this?
(SSH is no problem).

Thanks,
Mario

Just as additional information I found out:

It appears that the problem is somehow related to my favourite window manager
Enlightenment (in particular e16-0.16.8.1 that I've build without special 
options). Normally I'm using the Gnome desktop with Enlightenment.
Just for testing, I switched to KDE with the standard KDE WM and there was 
not a single problem over a couple of days. Then I set up KDE to use 
Enlightenment, and the problem was there again.
I'm not very deep into the relations between the window manager and X itself,
but I think in case the window manager is faulty then X should not cause 
segmentation faults. But perhaps this is wrong.

It is also interesting to note that the problem is coming seamingly out of 
nothing. I.e. once a "critical" application (such as xfig) has been startet,
one can leave the system untouched and then it crashes after some 
(nondeterministic) time. So neither the mousepointer is moved, nor a key is 
pressed, and nor the "critical" application is active in terms of changing 
the content of a window. 

Mario 

A remote backtrace is performed by remotely logging in to your problem computer.
Find out which pid the X process has
Fire up gdb.
Attach gdb to the X process by issuing the command gdb> attach <PID>
Wait for the error to happen.
type "bt", post this error here.

Good luck!

Ok, here is the result of the gdb backtrace:

Program received signal SIGSEGV, Segmentation fault.
0x080c5997 in dixDestroyPixmap ()
(gdb) bt
#0  0x080c5997 in dixDestroyPixmap ()
#1  0x080c5bfb in ProcFreePixmap ()
#2  0x080cab6e in Dispatch ()
#3  0x080d7d47 in main ()
(gdb)

So the problem is somewhere in dixDestroyPixmap()

Mario

Hmmhm, it seems I have the same problem:

Backtrace:
0: /usr/bin/X11/X(xf86SigHandler+0x88) [0x8089898]
1: [0xffffe420]
2: /usr/X11R6/lib/modules/libfb.so(fbTile+0x8c) [0xb7cd489c]
3: /usr/X11R6/lib/modules/libfb.so(fbFill+0x2b3) [0xb7cccca3]
4: /usr/X11R6/lib/modules/libfb.so(fbPolyFillRect+0x1f1) [0xb7ccd201]
5: /usr/X11R6/lib/modules/libxaa.so [0xb7c67f9e]
6: /usr/bin/X11/X [0x8171d07]
7: /usr/bin/X11/X(ProcPolyFillRectangle+0x181) [0x80c5f81]
8: /usr/bin/X11/X(Dispatch+0x15e) [0x80c9a7e]
9: /usr/bin/X11/X(main+0x415) [0x80d6785]
10: /lib/tls/libc.so.6(__libc_start_main+0xd0) [0xb7e28eb0]
11: /usr/bin/X11/X [0x8070131]

I cannot predict when does it occures exactly... sometimes...
I use Debian/testing (and do partial update almost daily)
My WM is Ion3, I already removed many modules from loading, these left:
freetype, record and type1.

Ehhmhm,

Igor Bogomazov

Igor, could you also please perform a remote backtrace?

Igors snapshot from the Xorg.0.log is looking really similar to mine.
There are various coincidences but also differences.

Meanwhile I could isolate the problem further and it seems to appear only
in junction with the Enlightenment DR16 window manager (versions 0.16.8.1
and 0.16.8.2). With other window managers (including Enlightenment DR17) I 
have not seen it. This Ion3 WM I have not tried yet.

I have risen the problem also in the Enlightenment community. So far, the 
consensus is that this is not a bug of Enlightenment - it just triggers the
bug somehow.

As for this dixDestroyPixmap(), there is not much to find:

int
dixDestroyPixmap(pointer value, XID pid)
{
    PixmapPtr pPixmap = (PixmapPtr)value;
    return (*pPixmap->drawable.pScreen->DestroyPixmap)(pPixmap);
}

(xc/programs/Xserver/dix/dispatch.c)

I'm not sure whether the gdb is capable of backtracing
such function pointer and the segmentation fault happens somewhere
inside the function behind the pointer, or whether it happens really 
here due to a wrong funcion pointer.

Regards,
Mario

  

Marking broken (status null/blank) bugs in xorg with no activity in a long time as fixed. Please reopen if you think it's necessary, but first do a search if a similar bug report is already filed and in a NEW/ASSIGNED state. These bugs do not currently show in most search results as they do not have any status.

Sorry for this janitorial spam, you know where to send hate mails to when your inbox gets full of bugs you're subscribed to.