Re: bug#12579: Emacs 24.2 crashes or freezes

[Sebastien Vauban]

Hi Eli,

Eli Zaretskii wrote:
>> From: "Sebastien Vauban" <wxhgmqzgwmuf@spammotel.com>
>> Date: Wed, 19 Dec 2012 09:35:43 +0100
>> 
>> - I used Helm (with its Everything companion -- that is some sort of "locate"
>>   for Windows, even better than the Unix one btw) on Emacs 22/23 for months
>>   (if not for one to two years).
>> 
>> - I used it with the above setting for `shell-file-name' -- that is unchanged
>>   in my .emacs file for years (while other settings may be often added or
>>   removed).
>> 
>> All of that without (any? or much?) problems... but the Helm code base I'm
>> using now is not the same as before -- I'm as good as up-to-date for all 
>> tests
>> I did with the new Emacs versions, to be sure to avoid problems which would
>> have been fixed on one side or the other.
>> 
>> So, I've no comparison where only Emacs version would differ, reason why I
>> can't honestly answer a definite "yes".
>> 
>> But, for sure, things were very bad with the first versions of Emacs 24: in
>> the beginning, I had a lot of crashes (multiple times a day with Emacs 24.1);
>> now (with the latest versions), it simply freezes when the process "es.exe"
>> becomes suspended.
>
> To be able to debug this, I'd need to see a full sequence of
> Lisp-level API calls that lead to the problem.  This is difficult to
> obtain because the problem happens rarely.  I suspect that the problem
> is related with Emacs killing the process; because es.exe is being run
> via the shell, Emacs actually kills the shell (because that's the only
> subprocess it knows about), and relies on the shell to kill its
> children.  (On Windows, killing a process doesn't kill its children.)
> For some reason, es.exe sometimes hangs in this situation, but only if
> the shell is the Cygwin Bash -- the stock cmd.exe doesn't suffer from
> this problem.
>
> Anyway, this is guesswork, I don't have any real evidence to back it
> up.

I second your summary.

I sometimes wonder whether my typing speed can play a role, along with this
setting in my .emacs file:

--8<---------------cut here---------------start------------->8---
     ;; time that the user has to be idle for, before candidates from
     ;; DELAYED sources are collected
     (setq helm-idle-delay 0.1)
     ;; useful for sources involving heavy operations, so that
     ;; candidates from the source are not retrieved unnecessarily if
     ;; the user keeps typing

     ;; time that the user has to be idle for, before ALL candidates
     ;; are collected (>= `helm-idle-delay')
     (setq helm-input-idle-delay 0.1)
     ;; also effective for NON-DELAYED sources
--8<---------------cut here---------------end--------------->8---

In particular, I sometimes wonder whether typing erroneous names (more than 3
letters), deleting some chars (coming back to 2 letters or less -- that is no
"locate" anymore), adding new chars, all that in a speedy way, may impact or
not the fact that es.exe are killed on the fly -- prematurely?

But, as you, these are pure assumptions on things to test, but things are
difficult to test, because such a problem only happens once a day (more or
less) with real work being done in Emacs. That could maybe happen much more
often if you we could have some "monkey" program typing for file names to
locate on my laptop, ever and ever. Is there such a thing doable -- ideas?

Isn't there any "debug" or "trace" mode I can enable in the Emacs at my
disposal, that could serve you?

Best regards,
Seb