| Summary: | Crash when X is running as non-root and switching quickly between vt's | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | xorg | Reporter: | Laurent Bigonville <bigon> | ||||||||
| Component: | Server/General | Assignee: | Xorg Project Team <xorg-team> | ||||||||
| Status: | RESOLVED MOVED | QA Contact: | Xorg Project Team <xorg-team> | ||||||||
| Severity: | normal | ||||||||||
| Priority: | medium | CC: | bpaterni, jwrdegoede, prahal, psychon | ||||||||
| Version: | 7.7 (2012.06) | ||||||||||
| Hardware: | Other | ||||||||||
| OS: | All | ||||||||||
| Whiteboard: | |||||||||||
| i915 platform: | i915 features: | ||||||||||
| Attachments: |
|
||||||||||
This looks like problem outside of Xorg. AFAICT when running as non-root, Xorg relies on something else (logind?) to re-enable DRM master capability when switching back to Xorg, but apparently that's not happening in this case for some reason. Hi, What I see in the log is: One successfull switch away and switch back to the X VT. Another successfull switch away and switch back to the X VT, but while X is still re-initializing systemd-logind decides that X is not the session with the focus and revokes the Xservers access to the devices *without* waiting for the Xserver to release the VT. Not sure what is going on here. You are talking about a cli session, I assume you mean a standard linux text-console? If that is the case then on logout you should just get a getty again, and not automatically switch to another console. I've the feeling this has something to do with how Debian has hooked things up, esp. since this is the first time I hear about such an issue. Have you filed a bug for this in Debian's bug tracker ? Regards, Hans It's possible that in this log I've been able to switch back and forth. I'm able to reproduce this with startx, so it seems that it's ruling out gdm here. Weird part is that it seems to only happen when I'm switching on vt1 while the Xserver is running on vt2. If I login on a text console on vt3 it's not happening... And I'm definitely only able to reproduce this on my desktop with a radeon card. Laptop with nvidia (nouveau) is working fine. xserver-xorg-video-radeon 1:7.6.1-1 xserver-xorg-core 2:1.17.3-2 Created attachment 120204 [details]
backtrace
I actually have been able to crash the server
OK, so when logging out of the tty, I was switched back to the X server because of the clear_console(1) utility that was called in the .bash_logout file (clear_console seems to be a debianism) If I'm removing the call to clear_console and then manually switching back to the vt where the Xserver is running is working fine (In reply to Laurent Bigonville from comment #5) > OK, so when logging out of the tty, I was switched back to the X server > because of the clear_console(1) utility that was called in the .bash_logout > file (clear_console seems to be a debianism) > > If I'm removing the call to clear_console and then manually switching back > to the vt where the Xserver is running is working fine Does this clear_console utility happen to be suid root ? If it is and it is mucking with vts instead of letting systemd-logind manage things, then things not working is hardly surprising. Well it's actually not suid root The code of the utility can be found at https://sources.debian.net/src/bash/4.3-14/debian/clear_console.c/ I actually can reproduce this with chvt: 1) login with gdm, the server is spawned on vt2 2) switch to vt1 3) login as the same user on vt1 4) run chvt 2; chvt 1 Same result Created attachment 121092 [details] xorg.log with crash backtrace -- intel hardware Hi, coming to this bug from https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=805605 In reproducing this bug, there seems to be a time-based component to getting X into a 'frozen' state. If there is a delay between step 4's chvt's, then all is fine after the second switch: ... 4. chvt 1; sleep 1; chvt 2 In my case, Laurent's procedure above is modified to (less gdm): 1. startx on tty1 2. switch to tty2 3. login 4. chvt 1; chvt2 Furthermore, when following the above to get into a 'frozen' X state (less `sleep 1`), it is not enough to produce an Xorg.log crash backtrace in my case. Instead, the crash does not happen until I 'switch' to the vt on which the frozen X is living. vt1 in the above example. Only then is a backtrace logged to the Xorg.log which should be attached. *note: this is using intel hardware. Try to disable $HOME/.bash_logout script call to clear_console -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/xserver/issues/492. |
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.
Created attachment 120194 [details] Xorg logs Hi, On Debian unstable, with X server running as !root, the following actions lead to the lockup/crash of the server: 1) login with gdm, the server is spawned on vt2 2) switch to vt1 3) login as an other user 4) logout (ctrl-D) At this time, the vt is automatically switched to vt2 and the server stops responding and/or crash As you can see in the logs, the radeon driver complains that it cannot access the device, so I'm not sure it's a general X issue or a problem with the driver. The weird part is that I can switch from vt back to the X session without trouble as long as I don't exit the cli one