bug#12579: 24.1; Emacs 24.1 / 24.2 (daily) crashes

[Fabrice Niessen]

Hi Thierry and Eli,

Thierry Volpiatto wrote:
> Eli Zaretskii <eliz@gnu.org> writes:
>>> From: Thierry Volpiatto <thierry.volpiatto@gmail.com>
>>> Eli Zaretskii <eliz@gnu.org> writes:
>>>>> From: Thierry Volpiatto <thierry.volpiatto@gmail.com>
>>>>>
>>>>> the es.exe backend that is for some reasons bad supported by 
>>>>> start-process.
>>>>
>>>> Any details about this?
>>>
>>> Unfortunately no, I use rarely Windows and BTW es.exe, it is just a
>>> guess.
>>
>> What is this guess based on?  What incidents did you witness that led
>> you to this guess?
>
> Because it is the only async process that run in helm-for-files, and
> every time the crash come from this; On GNU/Linux helm-for-files use
> locate and nobody reported crash on this platform.
> It is why I asked Fabrice to remove this source from helm-for-files to
> see what happen.  I am nearly sure the crashes will stop.
> Using helm-locate alone (outside of helm-for-files) should also crash
> emacs (on Windows I mean).
> So maybe es.exe, with specific settings in Everything could cause a
> crash?

My gut feeling is also that `es.exe' is (co-)responsible. In fact, this is more
than a gut feeling, as it's somehow based on a beam of presumptions:

- with the latest versions of Emacs, the infloop always occur when using
  helm-for-files (never, for example, when using helm-M-x, which is the other
  tool I'm using, as frequently, from Helm)

- `es.exe' is launched after having typed at least 3 characters in the prompt,
  and I've never seen an infloop with less characters (that is, only one or
  two) typed at the prompt: I always have typed a pattern of at least 5 to 6
  chars before the freeze occurs (sometimes, even much more, when being
  deleting many characters because I typed an fault in the filename I'm after)

- on Monday, after having gotten several frozen Emacs (since the last reboot
  of Windows -- once every 3 weeks or so), I had noticed up to 7 instances of
  `es.exe' (I guess they were hanging as some zombies, though I don't know to
  prove this -- any idea?)

- from the latest backtrace I sent today, you can see, IIUC, that frame #14
  identifies `locate-process' as the one we're waiting on

- the default `locate' command used by Helm, when on Windows, is `es.exe' (the
  command line version of "Everything", some sort of realtime `locate', much
  more powerful IMHO then than the real `locate' itself, because of that
  realtime aspect)

Does this give you more trust into Thierry's assumption?

Anyway, we'll be able to compare: I'm currently only running helm-M-x, waiting
for the next infloop. Then, I'll use helm-for-files without the locate process
for as long as needed to get an infloop. After one week, we should have a
rather solid comparison basis, based on the occurrence frequency of my
problem...

Best regards,
Fabrice