! Please note that this is a snapshot of our old Bugzilla server, which is read only since May 29, 2020. Please go to gitlab.xfce.org for our new server !
Switching back and forth between an Xfce Session and one of the virtual conso...
Status:
RESOLVED: INVALID
Product:
Xfce4-settings
Component:
Keyboard Settings

Comments

Description Troels Vedel Kloejgaard 2010-01-16 12:15:29 CET
Intel Core 2 Duo E6750, 2.66 GHz, FSB 1333 MHz, 4 MB Level 2 Cache (Conroe)

Asus Motherboard P5E (Intel Motherboard Chipset X38)

2 x 1 GB Kingston RAM DDR2, 800 MHz, PC2-6400

Inno3D Geforce 8400GS (Memory: 256 MB)

Seagate Barracuda, 320 GB, 7200.10, SATA II/3, 16 MB Cache

Asus DVD Writer, 18x, SATA, Black

Antec Nine Hundred Gamer Case

NorthQ 500 Watt Ultra Silent Power Supply

Linux Kernel, version 2.6.30.5 (command: uname -r)

Zenwalk Linux 6.2, 32-bit packages (command: cat /etc/zenwalk-version)

Xfce 4.6.1 (command: ls /var/log/packages/ | grep xfce)

The Xfce packages are the packages from the Zenwalk Linux 6.2 Standard Edition Installation CD (release date: September 6, 2009). No subsequent upgrade has been performed of these packages.

The bug applies to the Xfce4 application launcher xfrun4.

Steps to reproduce:

(1) Log in to an Xfce Session

(2) Open one or more apps with heavy memory usage, say Mozilla Firefox 3.5 with 20 tabs

(3) Switch to one of the virtual consoles (ttys), for instance tty1 (short cut: Ctrl + Alt + F1)

(4) Remain at the tty for several minutes (with or without login)

(5) Switch back to the running Xfce Session (short cut: Alt + F7)


Switching back to the running Xfce Session, xfrun4 goes berserk and spawns a large number of separate xfrun4 processes (evidenced by top), each process guzzling a part of the memory. Effect: the Xfce Session grinds to a halt so that no memory is left for mouse actions and keyboard presses. Only solution: hard reboot.

I have reproduced the bug numerous times and on one occasion I managed to run top so that I could see the proliferation of separate xfrun4 processes. Unfortunately, I've not been able to take a screenshot as the keyboard did not respond and I don't have a camera.

The screen resolution under X is 1280x1024. The ttys are running as VESA Framebuffer Consoles at 1024x768 with 16 bit color depth.

Although a system freeze or lock up could have a malfunctioning motherboard as the root cause, I haven't experienced any system freezes or lock ups when running an Xfce Session exclusively, when running console sessions on the ttys exclusively, or when booting the system.

Also, I haven't experienced any problems when performing multiple graphical logins via Xnest or gdmXnest from a running Xfce Session.

The bug could be specific to Zenwalk Linux but I don't think so. Unlike the big mainstream Linux distributions, Zenwalk Linux doesn't patch the upstream packages to the hilt.
Comment 1 Brian J. Tarricone (not reading bugmail) 2010-01-16 23:23:59 CET
Sounds like a keyboard shortcut issue.  X is getting the mouse down for alt+F2, but is never getting the mouse up since it switches away from X, so autorepeat must come into play.

That's odd tho; you'd think it wouldn't get activated at all since you have to do ctrl+alt+F# to get out of X... unless this user's setup is odd.
Comment 2 Sean Davis editbugs 2015-01-31 19:14:20 CET
Please confirm if this is still an issue with xfce-settings 4.11.3

Bug #6163

Reported by:
Troels Vedel Kloejgaard
Reported on: 2010-01-16
Last modified on: 2020-05-25

People

Assignee:
Jannis Pohlmann
CC List:
4 users

Version

Attachments

Additional information