Created attachment 24930 [details] xorg.conf Switching from console mode to X with Option SWCursor enabled, xorg dumps core. No problem without SWCursor. Problem is also mentioned in comment #14 here: https://bugs.freedesktop.org/show_bug.cgi?id=16865 Versions: xorg-server-1.6.0,1; xf86-video-ati-6.12.2; Radeon X1650 PCIE Platform: FreeBSD 7.2-PRERELEASE i386 gdb: (gdb) bt #0 0x34267e17 in kill () from /lib/libc.so.7 #1 0x34184357 in raise () from /lib/libthr.so.3 #2 0x3426698a in abort () from /lib/libc.so.7 #3 0x080bdd03 in ddxGiveUp () at xf86Init.c:1417 #4 0x080bdde0 in AbortDDX () at xf86Init.c:1462 #5 0x08168a1d in AbortServer () at log.c:407 #6 0x08168e18 in FatalError ( f=0x8224c5c "Caught signal %d. Server aborting\n") at log.c:532 #7 0x080da643 in xf86SigHandler (signo=11) at xf86Events.c:387 #8 <signal handler called> #9 0x0810d70f in xf86_reload_cursors (screen=0x34348180) at xf86Cursors.c:615 #10 0x344d70d0 in radeon_crtc_mode_commit (crtc=0x34308000) at radeon_crtc.c:288 #11 0x08107055 in xf86CrtcSetModeTransform (crtc=0x34308000, mode=0x343080bc, rotation=1, transform=0x0, x=0, y=0) at xf86Crtc.c:356 #12 0x0810b61c in xf86SetDesiredModes (scrn=0x34306800) at xf86Crtc.c:2497 #13 0x344a9469 in RADEONEnterVT (scrnIndex=0, flags=0) at radeon_driver.c:5663 #14 0x080f498a in xf86XVEnterVT (index=0, flags=0) at xf86xv.c:1228 #15 0x080e2455 in CMapEnterVT (index=0, flags=0) at xf86cmap.c:455 #16 0x080daca0 in xf86VTSwitch () at xf86Events.c:597 #17 0x080da445 in xf86Wakeup (blockData=0x0, err=-1, pReadmask=0x824f640) at xf86Events.c:295 #18 0x080931ab in WakeupHandler (result=-1, pReadmask=0x824f640) at dixutils.c:418 #19 0x08158c79 in WaitForSomething (pClientsReady=0x46d5d800) at WaitFor.c:231 #20 0x080858ef in Dispatch () at dispatch.c:367 #21 0x0806ba49 in main (argc=4, argv=0xbfbfeee0, envp=0xbfbfeef4) at main.c:397 (gdb) frame 9 #9 0x0810d70f in xf86_reload_cursors (screen=0x34348180) at xf86Cursors.c:615 615 if (!cursor_screen_priv->isUp) (gdb) p cursor_screen_priv->isUp Cannot access memory at address 0x4
Created attachment 24931 [details] Xorg.0.log.old
I'm seeing what looks like the same issue with xorg-server-1.6.1, xf86-video-nouveau from git (7597203b) and a software cursor: Backtrace: 0: X(xorg_backtrace+0x26) [0x4e7466] 1: X(xf86SigHandler+0x39) [0x46eb49] 2: /lib/libc.so.6 [0x7fcafad16b70] 3: X(xf86_reload_cursors+0x45) [0x4a5985] 4: /usr/lib/xorg/modules/drivers//nouveau_drv.so [0x7fcaf9977ac5] 5: X(xf86CrtcSetModeTransform+0x47d) [0x4a481d] 6: X(xf86SetSingleMode+0x12f) [0x4a49df] 7: X(xf86SwitchMode+0x11b) [0x47695b] 8: X(VidModeSwitchMode+0x6f) [0x47332f] 9: /usr/lib/xorg/modules/extensions//libextmod.so [0x7fcafa431bda] 10: X(Dispatch+0x364) [0x446da4] 11: X(main+0x3bd) [0x42cc9d] 12: /lib/libc.so.6(__libc_start_main+0xe6) [0x7fcafad02ff6] 13: X [0x42c129] Fatal server error: Caught signal 11. Server aborting Like Mr. Block, I'm seeing a NULL cursor_screen_priv at xf86Cursors.c:615. Judging from the comment at xf86Cursors.c:614, I tried tweaking the code to simply return when cursor_screen_priv is NULL and this seems to resolve the problem for me. If I use a hardware cursor, then I don't experience this crash, so presumably cursor_screen_priv is not NULL in this case. Anyway, I tracked down the change to the following git commit: commit 0b8f8b24f718820a72ebdc52423c2e6a44e848c5 Author: Stuart Bennett <sb476@cam.ac.uk> Date: Tue Dec 2 22:52:53 2008 -0800 xf86Cursors: xf86_reload_cursors shouldn't unconditionally show hwcursor (#14820) Also, no need to call ShowCursor when SetCursorPosition already does it Based on a previous patch by Maarten Maathuis Signed-off-by: Keith Packard <keithp@keithp.com> Please let me know if there's anything else I can do to help. Thanks, -Ted
This is the same bug as #21535, debian bug #507916, etc. The fix is trivial, just needs a NULL check...
Let's mark as dupe of #21535 then, thanks. *** This bug has been marked as a duplicate of bug 21535 ***
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.