Bug#776800: X server crashes when switching to another user
On 02/27/2015 02:55 PM, Richard B. Kreckel wrote: I've observed that most of these X server crashes have a stack backtrace that looks like this: #0 0x7fde06264107 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 0x7fde062654e8 in __GI_abort () at abort.c:89 #2 0x7fde089e49e1 in OsAbort () at ../../os/utils.c:1361 #3 0x7fde0883f86e in ddxGiveUp (error=EXIT_ERR_ABORT) at ../../../../hw/xfree86/common/xf86Init.c:1088 #4 0x7fde0883f996 in AbortDDX (error=EXIT_ERR_ABORT) at ../../../../hw/xfree86/common/xf86Init.c:1132 #5 0x7fde089ee370 in AbortServer () at ../../os/log.c:783 #6 0x7fde089ee8b1 in FatalError (f=0x7fde08a1de68 "Caught signal %d (%s). Server aborting\n") at ../../os/log.c:924 #7 0x7fde089e1653 in OsSigHandler (signo=11, sip=0x7fff53cb6530, unused=0x7fff53cb6400) at ../../os/osinit.c:147 #8 #9 0x7fde0889cd87 in xf86CursorSetCursor (pDev=0x7fde0a9bb260, pScreen=0x7fde0a8d2110, pCurs=0x7fde0ac7b280, x=772, y=596) at ../../../../hw/xfree86/ramdac/xf86Cursor.c:332 #10 0x7fde0889c9e6 in xf86CursorEnableDisableFBAccess (pScrn=0x7fde0a894420, enable=1) at ../../../../hw/xfree86/ramdac/xf86Cursor.c:232 #11 0x7fde00be4ef2 in ?? () from /usr/lib/xorg/modules/drivers/nvidia_drv.so #12 0x7fde00bdc791 in ?? () from /usr/lib/xorg/modules/drivers/nvidia_drv.so #13 0x7fde0883afdb in xf86VTEnter () at ../../../../hw/xfree86/common/xf86Events.c:581 #14 0x7fde0883b0c8 in xf86VTSwitch () at ../../../../hw/xfree86/common/xf86Events.c:633 #15 0x7fde0883a5ad in xf86Wakeup (blockData=0x0, err=-1, pReadmask=0x7fde08c85500 ) at ../../../../hw/xfree86/common/xf86Events.c:291 #16 0x7fde087e5d0e in WakeupHandler (result=-1, pReadmask=0x7fde08c85500 ) at ../../dix/dixutils.c:423 #17 0x7fde089d70f0 in WaitForSomething (pClientsReady=0x7fde0abc4dd0) at ../../os/WaitFor.c:229 #18 0x7fde087d5edd in Dispatch () at ../../dix/dispatch.c:361 #19 0x7fde087e4f70 in dix_main (argc=14, argv=0x7fff53cb6ef8, envp=0x7fff53cb6f70) at ../../dix/main.c:296 #20 0x7fde087c5fc8 in main (argc=14, argv=0x7fff53cb6ef8, envp=0x7fff53cb6f70) at ../../dix/stubmain.c:34 I don't know what the closed-source nvidia_drv.so does in #11 and #12. But in #10 I applied the appended brute-force patch to see what happens and, lo and behold, no crashes after a hundred times switching user and two days of doing normal work! This patch may introduce a small memory leak - I don't know. But the machine doesn't freeze any more! @Aaron: Do you still think this is a bug in Xorg? Almost certainly, yes. The NVIDIA calls are part of the EnableDisableFBAccess wrap chain. The NVIDIA driver doesn't do a whole lot with the cursor during that path. Especially since the NVIDIA driver is just calling down to the wrapped xf86CursorEnableDisableFBAccess rather than doing anything with the cursor code directly. -- Aaron -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54f0f6e2.50...@nvidia.com
Re: non-MIT files in xf86-video-nv
Julien Cristau wrote: On Sun, Jun 15, 2008 at 10:33:16 +, Joerg Jaspert wrote: > Hi Maintainer, > > rejected, there is a license issue to clarify before this can enter > main. The files nv_cursor.c, nv_setup.c, nv_local.h, nv_hw.c, nv_exa.c, > nv_dac.c and nv_dac.c contain a license header that > is not DFSG free (only allows use, but no redistribution, modification, > etc). Probably just an oversight on upstreams (well, nvidias) side, but > still nothing we can ship. > The same seems to apply to the xserver-xorg-video-nv package, which is where these files come from. Aaron, do you know if it would be possible to get them relicensed under a more MIT-like license, rather than the current more restrictive one? The COPYING file for xf86-video-nv doesn't actually carry the license from e.g. src/nv_setup.c. Hi Julien, I'm pretty sure "license to use this code in individual and commercial software" was intended to include redistribution and modification. That said, the point is moot because I just replaced all of these with the stock MIT X11 boilerplate from the COPYING file. See commit 2fdcda8. -- Aaron --- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. --- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
