kern/52096: pkgsrc/x11/xlockmore - xlock abort(3)

[paul%whooppee.com@localhost]

>Number:         52096
>Category:       kern
>Synopsis:       the xlock image from pkgsrc/x11/xlockmore fails
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Mar 21 01:40:00 +0000 2017
>Originator:     Paul Goyette
>Release:        NetBSD 7.99.59
>Organization:
+------------------+--------------------------+------------------------+
| Paul Goyette     | PGP Key fingerprint:     | E-mail addresses:      |
| (Retired)        | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com   |
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org |
+------------------+--------------------------+------------------------+
>Environment:
	
	
System: NetBSD speedy.whooppee.com 7.99.59 NetBSD 7.99.59 (SPEEDY 2017-02-15 11:46:59 UTC) #0: Wed Feb 15 12:39:29 UTC 2017 paul%speedy.whooppee.com@localhost:/build/netbsd-local/obj/amd64/sys/arch/amd64/compile/SPEEDY amd64
Architecture: x86_64
Machine: amd64
>Description:
(I have filed this under category 'kern' but that's probably wrong.  I
don't know what the correct category would be - we don't seem to have a
category for in-tree X.  Perhaps this is better suited for lib or bin?
Or even xsrc?  I'd appreciate it if someone could re-categorize this PR
appropriately!)

A default build of xlockmore fails with Radeon HD 3450 video card.  The
xlock image ends up calling abort(3) from many frames deep in library
calls.  The stack trace looks like this:

(gdb) target core xlock.core 
[New process 1]
Core was generated by `xlock'.
Program terminated with signal SIGABRT, Aborted.
#0  0x0000774a4143dd7a in _sys___sigprocmask14 () from /usr/lib/libc.so.12
(gdb) bt
#0  0x0000774a4143dd7a in _sys___sigprocmask14 () from /usr/lib/libc.so.12
#1  0x0000774a3cc094fb in pthread_sigmask () from /usr/lib/libpthread.so.1
#2  0x0000774a3d3c643e in radeon_drm_winsys_create ()
   from /usr/X11R7/lib/modules/dri/r600_dri.so
#3  0x0000774a3d0ba1ac in dd_create_screen ()
   from /usr/X11R7/lib/modules/dri/r600_dri.so
#4  0x0000774a3d0bbbee in ?? () from /usr/X11R7/lib/modules/dri/r600_dri.so
#5  0x0000774a3d0c4f01 in ?? () from /usr/X11R7/lib/modules/dri/r600_dri.so
#6  0x0000774a43458f6c in ?? () from /usr/X11R7/lib/libGL.so.2
#7  0x0000774a43451263 in __glXInitialize () from /usr/X11R7/lib/libGL.so.2
#8  0x0000774a434533df in ?? () from /usr/X11R7/lib/libGL.so.2
#9  0x0000774a4345350d in glXChooseVisual () from /usr/X11R7/lib/libGL.so.2
#10 0x000000000040f116 in ?? ()
#11 0x000000000040ec72 in ?? ()
#12 0x0000000000547c95 in ?? ()
#13 0x0000000000407f0b in ?? ()
#14 0x00007f7ec7203382 in _rtld () from /usr/libexec/ld.elf_so
#15 0x00007f7fff0d94d8 in ?? ()
#16 0x00007f7fff0d94fa in ?? ()
#17 0x00007f7fff0d9507 in ?? ()
#18 0x00007f7fff0d951f in ?? ()
#19 0x00007f7fff0d952a in ?? ()
#20 0x00007f7fff0d9537 in ?? ()
#21 0x00007f7fff0d9542 in ?? ()
#22 0x00007f7fff0d9554 in ?? ()
#23 0x00007f7fff0d956d in ?? ()
#24 0x00007f7fff0d957c in ?? ()
#25 0x00007f7fff0d959a in ?? ()
#26 0x00007f7fff0d95aa in ?? ()
#27 0x00007f7fff0d95b5 in ?? ()
#28 0x00007f7fff0d95c3 in ?? ()
#29 0x00007f7fff0d95d3 in ?? ()
#30 0x00007f7fff0d95db in ?? ()
#31 0x00007f7fff0d95e7 in ?? ()
#32 0x00007f7fff0d9600 in ?? ()
#33 0x00007f7fff0d960a in ?? ()
#34 0x00007f7fff0d9614 in ?? ()
#35 0x00007f7fff0d961f in ?? ()
#36 0x00007f7fff0d962c in ?? ()
#37 0x00007f7fff0d9658 in ?? ()
#38 0x00007f7fff0d9664 in ?? ()
#39 0x0000000000000000 in ?? ()
(gdb)

Running the xlock command via

	ktrace -i -tA xlock -mode maze

shows that all activity occurs within a single thread (lwp_id for every
record is equal to 1).  There are multiple ioctl() failures logged in the
kdump output, all of the form

  3003      1 xlock    CALL  ioctl(4,_IOWR('d',0x67,0x10),0x7f7fff0d8410)
  3003      1 xlock    GIO   fd 4 wrote 16 bytes
        000   18 00 00 00 00 00 00 00  20 52 f3 43 4a 77 00 00 .........R.CJw..
  3003      1 xlock    RET   ioctl -1 errno 22 Invalid argument

Unfortunately, the address argument 0x7f7fff0d8410 appears to be allocated
dynamically (the same address is used for other system calls), so dumping
its contents is not useful.

The above ioctl() might be a red herring, as after several failures - with
slightly different data values - we get the following successful calls to
the same ioctl():

  3003      1 xlock    CALL  ioctl(4,_IOWR('d',0x67,0x10),0x7f7fff0d8400)
  3003      1 xlock    GIO   fd 4 wrote 16 bytes
        000   00 00 00 00 00 00 00 00  44 d0 fb 43 4a 77 00 00 ........D..CJw..
  3003      1 xlock    GIO   fd 4 read 16 bytes
        000   00 00 00 00 00 00 00 00  44 d0 fb 43 4a 77 00 00 ........D..CJw..
  3003      1 xlock    RET   ioctl 0
  3003      1 xlock    CALL  ioctl(4,_IOWR('d',0x67,0x10),0x7f7fff0d8400)
  3003      1 xlock    GIO   fd 4 wrote 16 bytes
        000   06 00 00 00 00 00 00 00  fc 83 0d ff 7f 7f 00 00 ................
  3003      1 xlock    GIO   fd 4 read 16 bytes
        000   06 00 00 00 00 00 00 00  fc 83 0d ff 7f 7f 00 00 ................
  3003      1 xlock    RET   ioctl 0

(Note that the address of the "struct drm_radeon_info" passed to the
ioctl() calls is different here than in the earlier failing calls...)

With some (significant) assistance on irc, I was pointed at PR kern/49838
which had some similarities with this problem.  Even though that PR was
related to a kernel crash, and even though that PR has been fixed (and the
kernel crash is gone), the work-around suggested in that PR actually helps
with this current problem.

	
>How-To-Repeat:
1. Build xlockmore package from xsrc
2. Install on a system with Radeon HD 3450 video card
3. Execute 'xlock -mode maze'

	
>Fix:
Unknown
However, as a work-around, you can run

	env RADEON_THREAD=FALSE xlock -mode maze

	

>Unformatted: