Remember that Anything (at that time) crashed on Windows -- 6 months ago or so
--, and that you changed some code, making "Emacs" behave correctly after
that?
Well, I did yesterday an update of Helm (last one was from June or so), and
similar problems come back to light.
Some details:
GNU Emacs 24.1.1 (i386-mingw-nt5.1.2600) of 2012-06-02 on MARVIN
on Windows XP
The only helm-commands I'm using:
- <f3> runs the command helm-for-files
- M-x runs the command helm-M-x
The problems (which reappared from yesterday) were noticed when using
`helm-for-files'. I enter some letters to identify the file or buffer I'm
after, and Emacs simply blocks. Doing `C-g' has no effect at all. Waiting
neither. The only exit I have is killing Emacs and restarting a new one.
Once again, I don't say that (the new version of) Helm is the culprit, but
somehow the interactions between Helm and Everything (and the Cygwin shell
maybe) make Emacs block at some point.
Temporarily, I've checked out an older version of Helm, and will try to bisect
until I fond the problematic one, but that'll take some time...
commit 35fc048e36f20e605285eded155cc6b63f1c3b04
Author: Michael Markert <markert.mich...@googlemail.com>
Date: Wed Jun 6 21:35:18 2012 +0200
For your information, the "Emacs is blocked" rate is something like 4 times a
day, on Helm yesterday's version.
"Sebastien Vauban" <wxhgmqzgw...@spammotel.com> writes:
> Hi Thierry,
> Remember that Anything (at that time) crashed on Windows -- 6 months ago or so
> --, and that you changed some code, making "Emacs" behave correctly after
> that?
> Well, I did yesterday an update of Helm (last one was from June or so), and
> similar problems come back to light.
> Some details:
> GNU Emacs 24.1.1 (i386-mingw-nt5.1.2600) of 2012-06-02 on MARVIN
> on Windows XP
> The only helm-commands I'm using:
> - <f3> runs the command helm-for-files
> - M-x runs the command helm-M-x
> The problems (which reappared from yesterday) were noticed when using
> `helm-for-files'. I enter some letters to identify the file or buffer I'm
> after, and Emacs simply blocks. Doing `C-g' has no effect at all. Waiting
> neither. The only exit I have is killing Emacs and restarting a new one.
> Once again, I don't say that (the new version of) Helm is the culprit, but
> somehow the interactions between Helm and Everything (and the Cygwin shell
> maybe) make Emacs block at some point.
I tried hard right now to make Emacs crashing with helm but couldn't,
can't reproduce your crash either from Linux and Windows.
Did you try from emacs -Q?
Can you run Emacs inside gdb? (This is the only way to debug
efficiently).
Also you could send a bug report to Emacs, like this people at Emacs can
try to reproduce inside gdb from the build directory.
> Temporarily, I've checked out an older version of Helm, and will try to bisect
> until I fond the problematic one, but that'll take some time...
> commit 35fc048e36f20e605285eded155cc6b63f1c3b04
> Author: Michael Markert <markert.mich...@googlemail.com>
> Date: Wed Jun 6 21:35:18 2012 +0200
> For your information, the "Emacs is blocked" rate is something like 4 times a
> day, on Helm yesterday's version.
> Best regards,
> Seb
-- Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997
Thierry Volpiatto wrote:
> "Sebastien Vauban" <wxhgmqzgw...@spammotel.com> writes:
>> Remember that Anything (at that time) crashed on Windows -- 6 months ago or so
>> --, and that you changed some code, making "Emacs" behave correctly after
>> that?
>> Well, I did yesterday an update of Helm (last one was from June or so), and
>> similar problems come back to light.
>> Some details:
>> GNU Emacs 24.1.1 (i386-mingw-nt5.1.2600) of 2012-06-02 on MARVIN
>> on Windows XP
>> The only helm-commands I'm using:
>> - <f3> runs the command helm-for-files
>> - M-x runs the command helm-M-x
>> The problems (which reappared from yesterday) were noticed when using
>> `helm-for-files'. I enter some letters to identify the file or buffer I'm
>> after, and Emacs simply blocks. Doing `C-g' has no effect at all. Waiting
>> neither. The only exit I have is killing Emacs and restarting a new one.
>> Once again, I don't say that (the new version of) Helm is the culprit, but
>> somehow the interactions between Helm and Everything (and the Cygwin shell
>> maybe) make Emacs block at some point.
> I tried hard right now to make Emacs crashing with helm but couldn't,
> can't reproduce your crash either from Linux and Windows.
> Did you try from emacs -Q?
> Can you run Emacs inside gdb? (This is the only way to debug
> efficiently).
> Also you could send a bug report to Emacs, like this people at Emacs can
> try to reproduce inside gdb from the build directory.
>> Temporarily, I've checked out an older version of Helm, and will try to bisect
>> until I fond the problematic one, but that'll take some time...
By bisecting, I found the commit which inserts problematic behavior on
Windows:
- it works OK with version of 2012-07-02 12:30 (1204798),
- it does not with the next one, of 2012-07-02 23:21 (c4FD008).
"Sebastien Vauban" <wxhgmqzgw...@spammotel.com> writes:
> By bisecting, I found the commit which inserts problematic behavior on
> Windows:
> - it works OK with version of 2012-07-02 12:30 (1204798),
> - it does not with the next one, of 2012-07-02 23:21 (c4FD008).
Did you try to reproduce with emacs -Q as I asked you?
I see nothing in the commits of 2012-07-02 that can crash emacs.
I have no other report of such a crash and I can't reproduce these crash
myself.
I think more at something running on your emacs and when you run helm,
it is the "too much process" that make your emacs crashing.
So again please try to reproduce with emacs -Q.
Also to really start debugging your problem, you should run your emacs inside
GDB as I already asked.
Do C-h C-d for more info.
Also if you report your bug to Emacs, it would be really helpful, you
will get help from experts with GDB like Eli, among others.
When Emacs crash it is not generally the cause of toplevel code like
helm but come from Emacs low level code.
I don't think the problem comes from helm itself, surely from code used
by helm in the back but not helm itself, if so I should have had at
least one crash since then but nothing.
To take an example, last time I had a crash with helm, it was when I was
in helm-find-files and I hit M-i to have info on a file:
Immediat crash.
It was not a bug of helm itself but a bug in x-tooltip C code, but at
first I could think it was an helm bug because Emacs was crashing when
using helm.
It is for this reason we need more infos on your bug.
-- Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997