Description of problem: I'm trying to track down a bug somewhere in emacs or maybe mercurial. I can reproduce the problem as follows. 1. open emacs in a directory with a .hg subdirectory 2. C-x v v Enter, to open up a VC dir buffer viewing that directory 3. go to a file that's been modified and hit v, enter a log message, then C-c C-c to commit the change 4. hit g to refresh the buffer -- then something goes wrong and the status line says [waiting....] From that point on, emacs is unresponsive. I used pkill emacs to stop it and trigger ABRT to make this bug report Version-Release number of selected component: emacs-24.5-2.fc22 Additional info: reporter: libreport-2.5.1 backtrace_rating: 4 cmdline: emacs APSTest.hs crash_function: AREF executable: /usr/bin/emacs-24.5 global_pid: 32400 kernel: 4.0.4-303.fc22.x86_64 runlevel: N 5 type: CCpp uid: 1000 var_log_messages: [System Logs]:\n-- Logs begin at Wed 2015-06-03 16:18:33 EDT, end at Tue 2015-06-16 13:30:49 EDT. -- Truncated backtrace: Thread no. 1 (10 frames) #0 AREF at ../../src/lisp.h:1356 #1 HASH_KEY at ../../src/lisp.h:1814 #2 hash_lookup at ../../src/fns.c:3813 #3 Fcoding_system_p at ../../src/coding.c:8504 #4 Fcheck_coding_system at ../../src/coding.c:8563 #5 Ffuncall at ../../src/eval.c:2811 #6 exec_byte_code at ../../src/bytecode.c:916 #7 funcall_lambda at ../../src/eval.c:3044 #8 Ffuncall at ../../src/eval.c:2872 #9 exec_byte_code at ../../src/bytecode.c:916
Created attachment 1039601 [details] File: backtrace
Created attachment 1039602 [details] File: cgroup
Created attachment 1039603 [details] File: core_backtrace
Created attachment 1039604 [details] File: dso_list
Created attachment 1039605 [details] File: environ
Created attachment 1039606 [details] File: limits
Created attachment 1039607 [details] File: maps
Created attachment 1039608 [details] File: mountinfo
Created attachment 1039609 [details] File: namespaces
Created attachment 1039610 [details] File: open_fds
Created attachment 1039611 [details] File: proc_pid_status
Oops, make that C-x v d Enter to view the directory.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
I can't reproduce this. Can you still make the reproducer work when running "emacs -Q" ?
Sorry, I think I made a mistake on item 2: 1. open emacs in a directory with a .hg subdirectory 2. C-x v d Enter, to open up a VC dir buffer viewing that directory 3. go to a file that's been modified and hit v, enter a log message, then C-c C-c to commit the change 4. hit g to refresh the buffer -- then something goes wrong and the status line says [waiting...] I just tried it again on an up-to-date Fedora 23 machine. Emacs is more responsive, but the [waiting...] never disappears and the update process in the *vc-dir* buffer takes forever to finish. The command running in that buffer is hg status -mardui -C files... I think the source of the problem is hg status -i. Some of my directories include a *lot* of ignored files, and previously emacs would hang waiting for hg to print information about every one of them. So I think that as of emacs-24.5-6.fc23.x86_64, the problem has mostly been fixed. What's left is that vc-dir.el and vc-hg.el do a lot of work that doesn't seem to be necessary in directories like that.
(In reply to Garrett Mitchener from comment #15) > hg status -mardui -C files... > > I think the source of the problem is hg status -i. Some of my directories > include a *lot* of ignored files, and previously emacs would hang waiting > for hg to print information about every one of them. This is what is indeed causing a delay. How many ignored files do you have? I have generated 10000 ignored files and the delay is still less than 1 second. But I agree that this should be fixed, there should probably be an upper limit on how many files should be displayed. > So I think that as of emacs-24.5-6.fc23.x86_64, the problem has mostly been > fixed. What's left is that vc-dir.el and vc-hg.el do a lot of work that > doesn't seem to be necessary in directories like that. On Fedora 23, you can try https://copr.fedorainfracloud.org/coprs/jsynacek/emacs-25/. The code looks pretty similar, though, at least in vc-hg.el.
[garrett@grograman]$ time hg status -i | wc 6890134 13782556 464679469 real 9m0.809s user 6m7.277s sys 0m59.760s So yes, almost 7 million. I have a *lot* of ignored files... This is a simulation project, and those are data files that shouldn't be tracked by hg. But I do need for several scripts to be under version control.
Ok, so this looks like something that should be correctly handled in hg. It takes a lot of time to process the files. You can apply the following workaround: 1) sudo emacs /usr/share/emacs/24.5/lisp/vc/vc-hg.el.gz 2) Apply the following patch to the file (simply remove the 'i' from hg arguments): @@ -628,7 +628,7 @@ (vc-hg-after-dir-status update-function))) (defun vc-hg-dir-status-files (dir files _default-state update-function) - (apply 'vc-hg-command (current-buffer) 'async dir "status" "-mardui" "-C" files) + (apply 'vc-hg-command (current-buffer) 'async dir "status" "-mardu" "-C" files) (vc-run-delayed (vc-hg-after-dir-status update-function))) 3) Save and restart emacs (or reevaluate vc-hg-dir-status-files). I can't think of anything better right now. Hg takes way too much time displaying those ignored files and emacs just bluntly waits and tries to display all of them.
Reported upstream: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=22481
Fixed upstream: http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=06083cf41c473404d246de9b91a0116f38c5485f
emacs-24.5-7.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-37ae1c1888
emacs-24.5-7.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-37ae1c1888
emacs-24.5-7.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.