Bug 102761
| Summary: | Xemacs becomes unresponsive, takes down mozilla UI response | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | Matt Luker <kostya> |
| Component: | xemacs | Assignee: | Jens Petersen <petersen> |
| Status: | CLOSED DUPLICATE | QA Contact: | Jay Turner <jturner> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 9 | CC: | srevivo |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | athlon | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2006-02-21 18:58:10 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Thanks for the report. This also sounds somewhat reminiscent of bug 90386 perhaps? 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)? 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. Good to hear that is working somewhat better at least. 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 *** Changed to 'CLOSED' state since 'RESOLVED' has been deprecated. |
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 persists. 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): xemacs-21.4.12 How reproducible: Sometimes 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.