ports/74265: XFree86 Version 4.4.0 with KDE 3.1 freezes up in death loop

[S. C. Sprong]

The following reply was made to PR ports/74265; it has been noted by GNATS.

From: "S. C. Sprong" <s.c.sprong at student.utwente.nl>
To: freebsd-gnats-submit at FreeBSD.org
Cc: ALeine <aleine at austrosearch.net>
Subject: Re: ports/74265: XFree86 Version 4.4.0 with KDE 3.1 freezes up in
 death loop
Date: Fri, 26 Nov 2004 19:35:09 +0100 (CET)

 I've got a similar problem, but with FreeBSD 5.3-STABLE (later
 than 16 Nov 2004) and xorg-6.7.0_1.
 
 After a random time period X's SmartScheduleTimer()
 (../xc/programs/Xserver/os/utils.c)
 that is attached to the SIGALRM, is caught in an endless loop.
 
 It appears to be triggered by large amounts of scrolling in an
 xterm (e.g. when viewing compiler output).
 
 The keyboard and the screen are frozen, but the rest of the
 system functions normally. X can be (remotely) killed, but the
 systemconsole driver sc driver can't be restarted.
 Attaching GDB to the runaway X crashes GDB.
 
 By the way, the hardware has worked perfectly well for years with
 FreeBSD 4.x, v5.2.1 and with older versions of XFree86.
 
 So far I ruled out:
 
 - X video driver (nvidia -> standard vga)
 - stand-alone xterm (alternating with wterm)
 - xdm vs startx
 - windowmanager (alternating twm and Windowmaker-0.91)
 - X server's -dumbSched switch (which freezes even faster)
 - system's ncurses 5 (remapped to ncurses 5.4 out of the ports)
 - any audio or network activity (disabled)
 - kern.hz timer (1024 back to 100), which I use for network polling
 - various of the more exotic kernel options
 
 I use SCHED_4BSD, COMPAT_43, and COPAT_FREEBSD4.
 I think that including my whole kernel config would only be a
 distraction, but it is of course available.
 
 For now I suspect a race condition in the signal handling in the
 threaded libc.
 
 scs