[Lucid] Option NoTrapSignals ignored when debugging xserver

Bug #532845 reported by TJ
22
This bug affects 4 people
Affects Status Importance Assigned to Milestone
xorg-server (Ubuntu)
Invalid
Undecided
Unassigned

Bug Description

In trying to debug the Lucid xserver crash-on-first-session-start issues. I have installed "xserver-xorg-dbgsym" in the hope that the backtrace of "/usr/bin/X" would reveal more detail via a core dump instead of the "Xorg.0.log" report:

-----
Backtrace:
0: /usr/bin/X (xorg_backtrace+0x3b) [0x80e880b]
1: /usr/bin/X (0x8048000+0x61aed) [0x80a9aed]
2: (vdso) (__kernel_rt_sigreturn+0x0) [0xc06410]
3: /usr/bin/X (0x8048000+0x2a190) [0x8072190]
4: /usr/bin/X (0x8048000+0x1ed3a) [0x8066d3a]
5: /lib/tls/i686/cmov/libc.so.6 (__libc_start_main+0xe6) [0x25fbd6]
6: /usr/bin/X (0x8048000+0x1e921) [0x8066921]

Caught signal 3 (Quit). Server aborting
-----

I added the NoTrapSignals option to xorg.conf as detailed at

 https://wiki.ubuntu.com/DebuggingProgramCrash#The%20Xorg%20server

----- /etc/X11/xorg.conf fragment -----
Section "ServerFlags"
        Option "NoTrapSignals" "true"
EndSection
-----

But on restarting the PC and encountering the bug the signal is still caught by the xserver. The xorg.0.log shows the option is recognised:

-----
...
(==) Using config file: "/etc/X11/xorg.conf"
(==) ServerLayout "Default Layout"
(**) |-->Screen "Default Screen" (0)
(**) | |-->Monitor "LCD Panel 1024x768"
(**) | |-->Device "Intel Corporation 82815 CGC"
(**) Option "NoTrapSignals" "true"
...
Backtrace:
0: /usr/bin/X (xorg_backtrace+0x3b) [0x80e880b]
1: /usr/bin/X (0x8048000+0x61aed) [0x80a9aed]
2: (vdso) (__kernel_rt_sigreturn+0x0) [0xc06410]
3: /usr/bin/X (0x8048000+0x2a190) [0x8072190]
4: /usr/bin/X (0x8048000+0x1ed3a) [0x8066d3a]
5: /lib/tls/i686/cmov/libc.so.6 (__libc_start_main+0xe6) [0x25fbd6]
6: /usr/bin/X (0x8048000+0x1e921) [0x8066921]

Caught signal 3 (Quit). Server aborting
-----

The debug symbols are installed:

ls -l /usr/lib/debug/usr/bin/
ls -l /usr/lib/debug/usr/bin/
total 6404
-rw-r--r-- 1 root root 17289 2010-03-02 17:00 cvt
-rw-r--r-- 1 root root 11387 2010-03-02 17:00 gtf
-rwxr-xr-x 1 root root 10911 2010-03-04 04:13 X
-rw-r--r-- 1 root root 6510542 2010-03-02 17:00 Xorg

Revision history for this message
Bryce Harrington (bryce) wrote :

Hi intuitivenipple,

Please attach the output of `lspci -vvnn` and `dmesg`, and attach your /var/log/Xorg.0.log (and maybe Xorg.0.log.old) file from after reproducing this issue. If you're using a custom /etc/X11/xorg.conf please attach that as well.

[This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]

tags: added: needs-xorglog
tags: added: needs-lspci-vvnn
Changed in xorg-server (Ubuntu):
status: New → Incomplete
Revision history for this message
Oliver Gerlich (ogerlich) wrote :

Same problem here: X crashes (apparently reproducably) when using Lucid Netbook Edition 2D, entering password to unlock keyring, and pressing Enter. But Xorg.0.log.old only shows its tiny backtrace and "Caught signal 3 (Quit). Server aborting", rather than triggering Apport.

I have added the NoTrapSignals config option but it doesn't make a difference. Does that option not apply for signal 3?

Revision history for this message
Oliver Gerlich (ogerlich) wrote :
Revision history for this message
Oliver Gerlich (ogerlich) wrote :
Revision history for this message
Oliver Gerlich (ogerlich) wrote :
Revision history for this message
Oliver Gerlich (ogerlich) wrote :
Revision history for this message
Bryce Harrington (bryce) wrote :

@ogerlich - thanks for providing that info, but we would like to see it from the original reporter. We may want to send this bug report upstream, but upstream has a hard and fast rule that logs from someone other than the original reporter are not acceptable. The reason for that is that quite often with X.org bug reports, two people may *think* they have the same issue based on commonality of symptoms and/or hardware, but in truth they have separate issues and mixing the report and the files can cause the developers some confusion.

If this bug report seems not to be getting attention, I would encourage you to file a new bug report with this data, and simply reference this bug report in your bug description.

Changed in xorg-server (Ubuntu):
status: Incomplete → New
status: New → Incomplete
Bryce Harrington (bryce)
tags: added: lucid
Revision history for this message
Bryce Harrington (bryce) wrote :

We're closing this bug since it is has been some time with no response from the original reporter. However, if the issue still exists please feel free to reopen with the requested information. Also, if you could, please test against the latest development version of Ubuntu, since this confirms the bug is one we may be able to pass upstream for help.

Changed in xorg-server (Ubuntu):
status: Incomplete → Invalid
Revision history for this message
Dmitriy Geels (dmig) wrote :

I tried to get Xorg core dump with no success. Looks like, that option NoTrapSignals has no effect.

Revision history for this message
Dmitriy Geels (dmig) wrote :

I found out, what prevents gdm/Xorg from creating core dump: soft core limit is set to 0 for these processes.

Revision history for this message
Uwe Geuder (ubuntulp-ugeuder) wrote :

In the current version xserver-xorg-core 2:1.7.6-2ubuntu7 Option NoTrapSignals works correctly.
I use Kubuntu and I have created a file /usr/lib/X11/xorg.conf.d/01-server.conf to give the option (but there are of course many other possible places)

In /var/log/Xorg.0.log you can see the difference when the server crashes. By default there is a backtrace, with the NoTrapSignals there is none.

Also in gdb you can see the difference. After a SEGV you can continue without the option (the handlers will be run and then Xorg will exit). With NoTrapSignal you cannot continue after a SEGV, the process has already been terminated.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.