Bug 102761 - Xemacs becomes unresponsive, takes down mozilla UI response
Summary: Xemacs becomes unresponsive, takes down mozilla UI response
Status: CLOSED DUPLICATE of bug 90386
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: xemacs   
(Show other bugs)
Version: 9
Hardware: athlon
OS: Linux
Target Milestone: ---
Assignee: Jens Petersen
QA Contact: Jay Turner
Depends On:
TreeView+ depends on / blocked
Reported: 2003-08-20 19:07 UTC by Matt Luker
Modified: 2015-01-08 00:06 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-02-21 18:58:10 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Matt Luker 2003-08-20 19:07:30 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030530

Description of problem:
Occasionally mozilla's UI windowing, text, and mouse reponses will cease to
work.  Tabs will stop loading or displaying.  Text boxes no longer have a
cursor.  Mozilla becomes unusable at this point, but closing it does not work. 
A killall is required.  However, on a fresh restart of mozilla, the problem

The problem appears to be with Xemacs.  Looking at its window, it is no longer
displaying anything (blank window with window title and nothing being displayed
in the window).  Xemacs will not respond or shutdown cleanly.  Kill is required.

Upon killing xemacs, all windowing tasks in Mozilla start to respond normally.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Load xemacs and mozilla
2. Leave xemacs running and use mozilla, occasionally bouncing back to the
xemacs desktop
3. Problem will eventually crop up

Additional info:

If I may suggest a theory, I believe this has something to do with how Xemacs
relates to the X-cursors.  I have noted bug #90614 happening on my system as
well (NVidia card).  Considering that this problem and the cursors problem both
hang on xemacs, there is probably something in the way it makes calls to the
window manager and xserver that is hanging some system.

Comment 1 Jens Petersen 2003-09-02 06:58:01 UTC
Thanks for the report.  This also sounds somewhat reminiscent of bug 90386

Could I ask you to try with the current xemacs package in rawhide/Severn
to see if the problem still occurs with it (it no longer uses lesstif)?

Comment 2 Matt Luker 2003-09-04 18:29:50 UTC
I upgraded to the Severn Xemacs packages (which required a bunch of other stuff
to including glibc).

I noticed that the Xemacs cursor problem still persists--but it is much more
manageable.  The cursor will sometimes remain as the xemacs cursor when outside
xemacs, but as soon as it is moved or a window is clicked on, it changes. 
Additionally, before when the cursor was messed up (say, set to a stopwatch),
clicking on the desktop switcher would not work or would not act as expected. 
This no longer happening.

So it looks like the cursor logic is still not completely locked down, but some
of the problems that went with it appear to have been resolved.  I will see if
it locks up the windowing functions in mozilla--but so far so good.

Comment 3 Jens Petersen 2003-09-05 01:55:15 UTC
Good to hear that is working somewhat better at least.

Comment 4 Jens Petersen 2003-09-08 03:14:12 UTC
ICBW but I think the cursor problem and the hanging are two 
quite separate problems.

Please re-open this report if you're still seeing problems.  Thanks.

*** This bug has been marked as a duplicate of 90386 ***

Comment 5 Red Hat Bugzilla 2006-02-21 18:58:10 UTC
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.

Note You need to log in before you can comment on or make changes to this bug.