cp /usr/bin/Xorg /usr/bin/Xorg.debug
valgrind /usr/bin/Xorg.debug
hit ctrl-c
seem spew like 

==3706== Invalid read of size 8
==3706==    at 0x4C4080: xf86CrtcCloseScreen (xf86Crtc.c:755)
==3706==    by 0x4E2EA7: CursorCloseScreen (cursor.c:205)
==3706==    by 0x531BD1: AnimCurCloseScreen (animcur.c:106)
==3706==    by 0x47CCDD: main (main.c:348)
==3706==  Address 0x5926410 is 64 bytes inside a block of size 78 free'd
==3706==    at 0x4A063F0: free (vg_replace_malloc.c:446)
==3706==    by 0x51A79F: RRProviderDestroyResource (rrprovider.c:394)
==3706==    by 0x45A972: doFreeResource (resource.c:873)
==3706==    by 0x45AA2A: FreeClientResources (resource.c:1139)
==3706==    by 0x45AAD8: FreeAllResources (resource.c:1154)
==3706==    by 0x47CC03: main (main.c:318)

This can randomly cause the X server to crash instead of exiting cleanly, and it will not correctly reset the VT etc. If you are using startx it can really break things.

I think this should be a blocker, and I have a patch ready to go.

+++ This bug was initially created as a clone of Bug #891140 +++

In Fedora 18 beta, any logout (quit, exit, etc) from any WM (kwin, fvwm, fluxbox, etc) that booted initially into the multi-user target, does NOT restore the drivers for the keyboard, mouse, or screen. (A boot to the graphical target does not exhibit this behavior.)

However, the system IS running without errors, as can be seen from the logs in /var dir after reboot OR by writing a simple bash script that launches X, waits, kills X, & then restarts X without a "hitch".

This has never occurred in prior versions (17, 16, ...).

Is this an xserver (v1.13) bug or a systemd function that was not properly executed?

--- Additional comment from Bill Nottingham on 2013-01-02 13:31:12 EST ---

What do you mean by 'restore the drivers for the keyboard, mouse or screen'? 

Are you on a blank tty1 (does <alt>-F1, <alt>-F2, etc. find other ttys)?

--- Additional comment from Guido on 2013-01-02 13:51:37 EST ---

(In reply to comment #1)
> What do you mean by 'restore the drivers for the keyboard, mouse or screen'?

If I run a simple background bash script (... &) that appends some text to /var/log/messages every few seconds, I can see after a manual reboot that the system IS running at all times. 
 
> Are you on a blank tty1 (does <alt>-F1, <alt>-F2, etc. find other ttys)?

After a Xorg logout, tty1,... is blank except for a frozen cursor in the upper left corner. <Alt F1,...> do NOT find other ttys. I cannot find a single responsive key except for the power button.

Hence I conclude that the drivers for console screen (VT), keyboard, & mouse are not reloaded when X quits.

An hour ago I loaded up a gnome desktop environment, that exhibited the same behavior as all previous WM tests. On gnome-session launch, there was a pop window that stated "Xorg killed by signal 6 (SIGABRT)". Aside from this notification, gnome seemed fine until I logged out.

F17 uses xserver v1.12 without issues; F18b uses v1.13.1. Of course, the kernel is different, too.

--- Additional comment from Guido on 2013-01-02 15:46:40 EST ---

Try this bash script, xkillx.sh, shown below.

From a console tty, run it.

It launches a X GUI (any WM will do, kde, gnome ,fvwm) that functions properly for 30 sec. It then kills xinit (X) to leave a dead keyboard, mouse, & blank screen. After another 15 sec, it starts X again (xinit) & everything is behaving correctly. Look at var/log/messages & you will see no errors (except from the deliberate kill.)

--- Additional comment from Guido on 2013-01-02 15:47:37 EST ---

Created attachment 671690 [details]
test bash script xkillx.sh

--- Additional comment from Lennart Poettering on 2013-01-03 13:47:01 EST ---

systemd is not involved in this. This is between X and the kernel. Reassigning.

Guide, which graphics driver are you using?

--- Additional comment from Guido on 2013-01-03 14:02:31 EST ---

(In reply to comment #5)
> systemd is not involved in this. This is between X and the kernel.
> Reassigning.
> 
> Guido, which graphics driver are you using?

Intel i965.

evdev is loaded to catch key & mouse events.

Below I attach the latest Xorg log.

--- Additional comment from Guido on 2013-01-03 14:04:57 EST ---

Created attachment 672155 [details]
Xorg log

When evdev, etc unloads, it seems that the console drivers do not reload.

--- Additional comment from Guido on 2013-01-07 11:33:29 EST ---

I started X with startx, instead of xinit, & got some useful debug info on the failures after quitting X. Echoed to the screen was the following:

    dispatch.c : 3944

    DetachOutputGPU

    Assertion `slave->isGPU' failed

Then there is a frozen screen, dead keyboard & mouse.

I did a web search & found this error recently, December 2012, reported on both Xorg & FreeDesktop bug sites for xserver v1.3.99.

This is an important bug that needs to be fixed by Xorg before Fedora 18 is finally released. It affects X with any WM that does not use a GDM.

--- Additional comment from Michal Schmidt on 2013-01-07 12:07:07 EST ---

(In reply to comment #8)
> I did a web search & found this error recently, December 2012, reported on
> both Xorg & FreeDesktop bug sites for xserver v1.3.99.

Could you provide the relevant URLs?

--- Additional comment from Guido on 2013-01-07 12:32:16 EST ---

See

<https://bugs.freedesktop.org/show_bug.cgi?id=58174>

Someone needs to get the Xorg Xserver maintainer to address this bug ASAP.

--- Additional comment from Guido on 2013-01-07 16:27:09 EST ---

Last line of Xorg log for v1.12.3
    Server terminated successfully (0). Closing log file.

Last line of Xorg log for v1.13.1
    X: dispatch.c:3944: DetachOutputGPU: Assertion `slave->isGPU' failed.

Attached below are full session X logs of 1.12.3 & 1.13.1.

--- Additional comment from Guido on 2013-01-07 16:28:59 EST ---

Created attachment 674354 [details]
X log v 1.12.3 (a functioning X server)

--- Additional comment from Guido on 2013-01-07 16:30:13 EST ---

Created attachment 674355 [details]
X log v 1.13.1 (a defective X server)

--- Additional comment from Dave Airlie on 2013-01-08 22:58:40 EST ---

can you run a server under valgrind and get the trace?

it looks like a use after free or some other memory corruption alright

--- Additional comment from Fedora Update System on 2013-01-08 22:59:35 EST ---

xorg-x11-server-1.13.1-4.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/xorg-x11-server-1.13.1-4.fc18