Bug 11223

Summary:	scrolling in XMMS's gtk 1 dialogs cause system lock up
Product:	xorg	Reporter:	Laurence Darby <ldarby>
Component:	* Other	Assignee:	Xorg Project Team <xorg-team>
Status:	RESOLVED INVALID	QA Contact:	Xorg Project Team <xorg-team>
Severity:	major
Priority:	medium
Version:	unspecified
Hardware:	x86 (IA32)
OS:	Linux (All)
Whiteboard:
i915 platform:		i915 features:

Description Laurence Darby 2007-06-10 17:22:22 UTC

Hi,

With xorg-server version 1.3.0.0, if I open one of the GTK 1 config windows in XMMS, then scroll any of the scroll widgets, the system locks up, ie. network downloads started from a VT separate from X stop and (sleep 10 ; eject) wont eject after the lockup, although linux's magic sysrq key combo still works to reboot. I've yet to find another gtk 1 program to see if this is XMMS specific or not. One of the dialogs (add dir) automatically scrolls and causes a lock up so probably not input related.
It's 100% repeatable, which is definitely helpful :) Also initially I tried many different kernels (including 2.6.16.52 & 2.6.21.3) with different configs but that didn't change anything. Also it locks up with both the open source nv driver and the nvidia binary blob.

It does not lock up running the 6.9.0 release.

I'm running mostly Slackware-current, everything (kernel, xorg, gtk1, xmms) compiled with gcc 4.1.2.

I would like some general advice on how to debug this. I've found and fixed a bug in x11 before: https://bugs.freedesktop.org/show_bug.cgi?id=3304

I tried using the xautomation tool to send the exact mouse presses that trigger the lock up while switched to a virtual terminal to see if anything gets printed on the console before the lockup, but being on the vt prevented it locking up and then scrolling works. I could setup my mini-itx diskless computer for debugging remotely if that would be helpful? Any advice would be appreciated here. It's taken a few days already to find out that it's related to xorg versions...

Thanks,
Laurence

Comment 1 Laurence Darby 2007-06-11 14:23:11 UTC

sh*t.  I was running xmms at RT priority.  I last read the warning about doing that over 6 years ago, and it's finally come to bite me. :(

I have previously had wierd experiences with RT:  Once, my computer locked up for 10 mins, then X died, and the whole time there wasn't a single glitch in the audio while xmms continued to play without X running....

Anyway, I have 2 disks, I'm going to use one exclusively for audio because the linux I/O schedulers still aren't good enough for non RT xmms.

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.