Red Hat Bugzilla – Bug 984177
scroll bar freezes emacs
Last modified: 2013-07-30 13:32:31 EDT
Description of problem:
When using EMACS with Fedora 19, the emacs graphical interface hangs if I click on the scroll bar to scroll the text. I can scroll the text with the mouse wheel and with keyboard, but doing it with scroll bar freeze the graphical interface of emacs.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. open emacs
2. click on the scroll bar and scroll the welcome text
3. emacs freeze
the emacs graphical interface freezes
scroll the text
The attachment is strace of emacs when in hangs. Note that the pooling still works after the graphical interface freezes. I do not know if the scroll bar action is present on the trace.
Created attachment 772975 [details]
strace of emacs when it freezes
Reproduced here. I rebuilt emacs 24.3-9 locally from rawhide for F-19, and it does not have this problem.
I've added (scroll-bar-mode -1) to my .emacs file and it fixed the problem as there is no more scrollbar being shown. :-)
Thanks for the bug.
I will look on that issue.
After upgrading to FC19 the problem didn't show up with emacs-24.2-19.fc18.x86_64
(To get emacs work in this constellation /usr/lib64/libgnutls.so.28 was linked to the missing /usr/lib64/libgnutls.so.26)
After doing a distro-sync which downgraded to emacs-24.2-18.fc19.x86_64
the problem showed up the first time.
Today I applied the update to emacs-24.2-20.fc19.x86_64 according to BUG 981135
which did not fix the problem.
Currently I am using a local build from source of emacs version 24.3.1 which doesn't show the problem.
I think this is the same bug I'm hitting, so maybe we can "merge" them (with all info) or close one as duplicate of other ( #953779 )
*** Bug 953779 has been marked as a duplicate of this bug. ***
I only managed to reproduce it once (in emacs -q).
It seems not that easy to reproduce?
Can someone attach a gdb backtrace when it has hung?
It doesn't happen quickly, but you move the scroll up/down until it happens, it doesn't crash, If I kill it with SIGHUP I can get trace, not sure is it helpful
Created attachment 774650 [details]
backtrace when killed with -1 (SIGHUP)
For me it always happen and it is immediate, it is just use the scrollbar. But the only thing that hangs is the graphical interface, Emacs keep running behind the graphical interface.
Comment 11 seconded here.
I have already informed upstream about that trouble
But I think that upgrading emacs-24.3 in F19 is pretty late
I have tested emacs-24.3 and trunk and in those two versions scrollbar is working properly.
I did a local build of the emacs-24.3-10.fc20 SRPM on F19 and it solves the problem. Is there an issue with pushing a 24.3 update to F19?
Did you tried whether some dependencies are not broken?
Do you think that regressions are needed?
It is enough to call git merge master on f19 brach and call
command like git push, fedpkg build and fedpkg update.
I can do that but it is need to test whether all is working properly.
I think that pushing emacs to the stable will take a time.
and I do not think that karma is enough.
In the meantime I will prepare steps for pushing into f19 update
I have checked dependencies like
repoquery --whatrequires --alldeps=src --enablerepo=fedora-source emacs
***** emacs packages
I checked to of them like automake and pypy and it seems that emacs is used only for editing text.
I certainly haven't checked all of them, but I think the main case to worry about is packages that provide some .el files, and for an update from 24.2 to 24.3, it seems quite unlikely that there would be any breakage. If I remember correctly, Fedora (and Red Hat Linux before that) has had emacs point release updates in the past, and I don't recall there ever having been any serious issues.
There was a big problem with an emacs major release upgrade some time back, and that resulted in having to bump the epoch to revert to the earlier major release. I would certainly advise against pushing a major release upgrade like 24.x to 25.x.
Anyhow, if the changeset you found fixes the problem and you can backport it to 24.2, I don't have any objection to that course of action.
From my point of view it would be good
to have the latest version (not trunk) in Fedora.
I have made the test for emacs-ibus package and there is a command line call like emacs --no-init file ....
Upgrade to 24.3 version could case a problem with running those lisp files, right?
I have tested emacs-rpm-spec-mode (installed with emacs-24.2) and run with 24.3 and it seems to be ok.
In the meantime here is a koji build.
Now the git push; fedpkg build and fedpkg update should be called for closing that problem.
From my point of view emacs-24.3 is prepared for building and updating in F19 repositories.
emacs-24.3-9.fc19 has been submitted as an update for Fedora 19.
Well, emacs was upgraded into 24.3 version
scm-commit (https://lists.fedoraproject.org/pipermail/scm-commits/Week-of-Mon-20130722/1061462.html) -> MODIFIED
I turn off karma so that emacs should be tested deeply.
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing emacs-24.3-9.fc19'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
The update fixed the problem but I was not able to login and leave karma. I was required to click "I'm human" then upload my GPG key and then I had no more access to the page pointed by the link, as it was always redirected to an empty TODO list...
thanks for confirmation that new emacs solved that problem.
Did you observe the problem with login previously?
My Fedora account (petersenna) was inactive due missing key and low activity. I've tried again now and it worked now. Thanks for fixing Emacs! :-)
emacs-24.3-9.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.