[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#776800: marked as done (X server crashes when switching to another user)

Your message dated Tue, 10 Jan 2017 16:19:24 +0100
with message-id <20170110151924.GA16843@localhost.localdomain>
and subject line Re: Bug#776800: X server crashes when switching to another user
has caused the Debian Bug report #776800,
regarding X server crashes when switching to another user
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
776800: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776800
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: xorg-server
Version: 2:1.16.2.901-1
Severity: important

I have a couple of Debian/jessie machines configured to be used by
serveral users in turns.  They are using the "log in as another user"
feature of Gnome, while other are staying logged in. In about 1 out of
15 cases, X freezes for good after a user has entered the password.
When X freezes, the screen remains black and only the mouse pointer is
visible but cannot be moved. Attaching to the frozen process using gdb
reveals that the hang is occurring because the X server crashed in a
call to malloc(), and the server's crash handler calls the driver's
LeaveVT function, which tries to allocate memory, which hangs trying to
take a malloc lock which is already held.

I should add here that the machines are all equipped with several types
of nVIDIA cards and run the proprietory driver. After contacting Aaron
Plattner of nVIDIA, he convinced me that the crashing path comes from a
path that does not involve the NVIDIA driver.

In order to track down the crashing call, I replaced /usr/bin/Xorg with
a script like this:

#!/bin/bash
ulimit -c unlimited
export MALLOC_CHECK_=2
exec /usr/bin/Xorg.testing "$@"

As expected, switching users makes X crash now instead of freezing.

And this is the stack backtrace of a core dump:

Core was generated by `/usr/bin/Xorg.testing :1 -novtswitch -background
none -noreset -verbose 3 -auth'.
Program terminated with signal SIGABRT, Aborted.
#0  0x00007fd92080e107 in __GI_raise (sig=sig@entry=6) at
../npt/sysdeps/unix/sysv/linux/raise.c:56
56      ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  0x00007fd92080e107 in __GI_raise (sig=sig@entry=6) at
../npt/sysdeps/unix/sysv/linux/raise.c:56
#1  0x00007fd92080f4e8 in __GI_abort () at abort.c:89
#2  0x00007fd920851850 in malloc_printerr (action=<optimized out>,
str=0x7fd92093ad1e "free(): invalid pointer", ptr=<optimized out>) at
malloc.c:5000
#3  0x00007fd922b2edc7 in FreeCursor (value=0x7fd9238d9fd0,
cid=cid@entry=0) at ../../dix/cursor.c:128
#4  0x00007fd922bbf988 in xf86CursorSetCursor (pDev=0x7fd9235f4b10,
pScreen=0x7fd92350b9c0, pCurs=0x7fd9238d50c0, x=685, y=591) at
../../../../hw/xfree86/ramdac/xf86Cursor.c:327
#5  0x00007fd922c85e2b in miPointerUpdateSprite (pDev=0x7fd9235f4b10) at
../../mi/mipointer.c:442
#6  0x00007fd922c8607e in miPointerDisplayCursor (pDev=0x7fd9235f4b10,
pScreen=0x7fd92350b9c0, pCursor=0x7fd9238d50c0) at ../../mi/mipointer.c:194
#7  0x00007fd922bcdef9 in CursorDisplayCursor
(pDev=pDev@entry=0x7fd9235f4b10, pScreen=pScreen@entry=0x7fd92350b9c0,
pCursor=0x7fd9238d50c0) at ../../xfixes/cursor.c:150
#8  0x00007fd922bcdff6 in CursorFreeHideCount (data=<optimized out>,
id=<optimized out>) at ../../xfixes/cursor.c:974
#9  0x00007fd922b5e1e2 in doFreeResource (res=0x7fd9238d2310, skip=0) at
../../dix/resource.c:873
#10 0x00007fd922b5ed2b in FreeResource (id=1094745046,
skipDeleteFuncType=skipDeleteFuncType@entry=0) at ../../dix/resource.c:903
#11 0x00007fd922bceebf in ProcXFixesShowCursor (client=0x7fd923859bd0)
at ../../xfixes/cursor.c:931
#12 0x00007fd922b3b0c7 in Dispatch () at ../../dix/dispatch.c:432
#13 0x00007fd922b3f266 in dix_main (argc=14, argv=0x7fff220c2138,
envp=<optimized out>) at ../../dix/main.c:296
#14 0x00007fd9207fab45 in __libc_start_main (main=0x7fd922b295c0 <main>,
argc=14, argv=0x7fff220c2138, init=<optimized out>, fini=<optimized
out>, rtld_fini=<optimized out>, stack_end=0x7fff220c2128) at
libc-start.c:287
#15 0x00007fd922b295ee in _start ()

  -rbk.
-- 
  .''`.  Richard B. Kreckel
 : :' :  <kreckel@debian.org>
 `. `'   <kreckel@ginac.de>
   `-    <http://www.ginac.de/~kreckel/>

--- End Message ---
--- Begin Message --- 
Glad to hear that your bug is resolved!

Thanks,
Andreas

On Sun, Dec 25, 2016 at 08:07:38PM +0100, Richard B. Kreckel wrote:
> As of stretch, with the nvidia-driver 375.20 and Xorg 1.19 this problem
> has disappeared.

Attachment: signature.asc
Description: Digital signature


--- End Message ---
Reply to: