Red Hat Bugzilla – Bug 489121
New libgxim breaks emacs under heavy scrolling
Last modified: 2009-03-10 09:11:27 EDT
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): libgxim-0.3.2-4.fc10.x86_64 libgxim-0.3.2-4.fc10.i386 How reproducible: Always 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
When emacs crashed, is imsettings-applet still running?
Yes, imsettings-applet is still running, at least it shows up in "ps ax" ....
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.
Okay, finally I can reproduce this here too
Ok!! I am happy I am not alone... let me know if you need further infos.
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.
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 ***