Bug 489121 - New libgxim breaks emacs under heavy scrolling
New libgxim breaks emacs under heavy scrolling
Status: CLOSED DUPLICATE of bug 488976
Product: Fedora
Classification: Fedora
Component: libgxim (Show other bugs)
All Linux
low Severity high
: ---
: ---
Assigned To: Akira TAGOH
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2009-03-07 15:59 EST by Alfredo Ferrari
Modified: 2009-03-10 09:11 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-03-10 09:11:27 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
echo of "strace emacs xxxx" (312.13 KB, application/octet-stream)
2009-03-07 15:59 EST, Alfredo Ferrari
no flags Details

  None (edit)
Description Alfredo Ferrari 2009-03-07 15:59:19 EST
Created attachment 334416 [details]
echo of "strace emacs xxxx"

Description of problem:
When editing remotely a file using emacs (eg in a vnc window) and scrolling it fast (eg with the down arrow kept pressed) emacs crashes all the times

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

How reproducible:

Steps to Reproduce:
1. Open a vnc connection. Edit a file using emacs
2. Scroll the file keeping the down arrow (or equivalent) pressed
3. Observe emacs crashing
Actual results:
emacs crashes

Expected results:
there should be no problem

Additional info:
reverting to libgxim-0.3.1-1 fixes the problem. The problem has been verified on both i386 and x86_64. It does not depend on the network speed, even opening a vnc session on the same machine results in emacs crashing. The only error message visible on the screen is
Connection lost to X server `:1.0'

I am sorry to report a further problem with the new libgxim, but it appears to be definitively not ready for prime time, breaking to many critical applications in unpredictable ways
Comment 1 Akira TAGOH 2009-03-09 06:29:41 EDT
When emacs crashed, is imsettings-applet still running?
Comment 2 Alfredo Ferrari 2009-03-09 07:13:39 EDT
Yes, imsettings-applet is still running, at least it shows up in "ps ax" ....
Comment 3 Akira TAGOH 2009-03-09 07:40:50 EDT
Hmm, I've tried keep pressing a Down or PageDown key on emacs to reproduce, after changing the keyboard settings on gnome-keyboard-properties to get a KeyPress event too fast and too much. however I've never seen emacs crashes yet.

Can you give me more info please?

1. head -20 $HOME/.xsession-errors
2. a backtrace at the place where X connection is lost. you might get something with setting a breakpoint at x_error_handler on gdb.
3. any other logs in .xsession-errors that might relates to imsettings-applet. or run LIBGXIM_DEBUG=all imsettings-applet manually after killing the existing one and try again.
Comment 4 Akira TAGOH 2009-03-09 08:04:32 EDT
Okay, finally I can reproduce this here too
Comment 5 Alfredo Ferrari 2009-03-09 09:07:17 EDT
Ok!! I am happy I am not alone... let me know if you need further infos.
Comment 6 Akira TAGOH 2009-03-09 09:22:43 EDT
Just for updates. maybe losing X connection is a side-effect. the root cause would be the key events is somehow getting stuck and didn't send back appropriate responses to the client. I'm investigating that now.
Comment 7 Akira TAGOH 2009-03-10 09:11:27 EDT
Closing as DUPLICATE so that the root cause is the same with it and as I mentioned at comment #6, crash with X connection lost is a side-effect. that would be just timed out to wait for a response.

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

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