bug#13701: 24.2.93; Segmentation fault

bug#13701: 24.2.93; Segmentation fault

[Sebastien Vauban]

Eli,

When answering your latest post, I got a segfault, and Emacs completely
crashed:

--8<---------------cut here---------------start------------->8---
warning: sys_read called when read is in progress
[New Thread 15276.0x17cc]


Program received signal SIGSEGV, Segmentation fault.
0x00000213 in ?? ()
(gdb)
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x00000213 in ?? ()
(gdb) continue
Continuing.
[New Thread 15276.0x6638]
[Inferior 1 (process 15276) exited with code 0377]
(gdb)
--8<---------------cut here---------------end--------------->8---

Best regards,
  Seb

-- 
Sebastien Vauban

bug#13701: 24.2.93; Segmentation fault

[Glenn Morris]

"Sebastien Vauban" wrote:

> warning: sys_read called when read is in progress

Searching for this message, I found that the only hit is crashes
previously reported by you in Emacs 24.1 and 24.2:

http://lists.gnu.org/archive/html/help-gnu-emacs/2012-10/msg00021.html

So maybe the issue(s) is not new and is caused by some unusual
circumstance on your machine.

> Program received signal SIGSEGV, Segmentation fault.
> 0x00000213 in ?? ()

I'm going to go out on a limb and say that more information will be
needed to solve this...

bug#13701: 24.2.93; Segmentation fault

[Thierry Volpiatto]

Glenn Morris <rgm@gnu.org> writes:

> "Sebastien Vauban" wrote:
>
>> warning: sys_read called when read is in progress
>
> Searching for this message, I found that the only hit is crashes
> previously reported by you in Emacs 24.1 and 24.2:
>
> http://lists.gnu.org/archive/html/help-gnu-emacs/2012-10/msg00021.html
>
> So maybe the issue(s) is not new and is caused by some unusual
> circumstance on your machine.
The initial problem was the user is setting `shell-file-name' to
"/path/to/bash" on a windows machine where the value is normally
"/path/to/cmdproxy.exe".
The result is that all externals programs made to be used with
"cmdproxy.exe" are crashing Emacs.
In the case of `helm', the user is crashing Emacs with the helm-locate
command which use the executable "es.exe" which is part of "everything"
program.
So I think these crash are not the fault of Emacs nor helm, but a bad
setting of user.

So the question is:
Sebastien, are you still using shell-file-name==bash in your config ?

>> Program received signal SIGSEGV, Segmentation fault.
>> 0x00000213 in ?? ()
>
> I'm going to go out on a limb and say that more information will be
> needed to solve this...
>
>
>
>

-- 
Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

bug#13701: 24.2.93; Segmentation fault

[Sebastien Vauban]

Hi Thierry, Glenn and all,

Thierry Volpiatto wrote:
> Glenn Morris <rgm-mXXj517/zsQ@public.gmane.org> writes:
>> "Sebastien Vauban" wrote:
>>
>>> warning: sys_read called when read is in progress
>>
>> Searching for this message, I found that the only hit is crashes
>> previously reported by you in Emacs 24.1 and 24.2:
>>
>> http://lists.gnu.org/archive/html/help-gnu-emacs/2012-10/msg00021.html
>>
>> So maybe the issue(s) is not new and is caused by some unusual
>> circumstance on your machine.
>
> The initial problem was the user is setting `shell-file-name' to
> "/path/to/bash" on a windows machine where the value is normally
> "/path/to/cmdproxy.exe".
> The result is that all externals programs made to be used with
> "cmdproxy.exe" are crashing Emacs.
> In the case of `helm', the user is crashing Emacs with the helm-locate
> command which use the executable "es.exe" which is part of "everything"
> program.
> So I think these crash are not the fault of Emacs nor helm, but a bad
> setting of user.
>
> So the question is:
> Sebastien, are you still using shell-file-name==bash in your config ?

The answer is yes:

  ╭────
  │ shell-file-name is a variable defined in `C source code'.
  │ Its value is "c:/cygwin/bin/bash.exe"
  ╰────

IIRC, I was asked by Eli (or, at the very least, allowed) to set back Bash as
my inferior shell.

FYI, I'm using that setting since 1999, when I began really working with
Emacs, and it did not cause any problems either with Helm (in that time,
Anything) for the last years in which I used it (at least, from 2010).

Problems began appearing with Emacs 24, IIRC.

That does not mean I absolutely have to keep that setting, but this is _by far_
my preferred one, as I'm using Cygwin Bash (or Zsh) all around the place, and
I want to be able to do the exact same thing from withing Emacs: for example,
calling one of my script on a selected region, or things like that.

Best regards,
  Seb

-- 
Sebastien Vauban

bug#13701: 24.2.93; Segmentation fault

[Thierry Volpiatto]

Hi Sébastien,

"Sebastien Vauban" <wxhgmqzgwmuf@spammotel.com> writes:

> Hi Thierry, Glenn and all,
>
> Thierry Volpiatto wrote:
>> Glenn Morris <rgm@gnu.org> writes:
>>> "Sebastien Vauban" wrote:
>>>
>>>> warning: sys_read called when read is in progress
>>>
>>> Searching for this message, I found that the only hit is crashes
>>> previously reported by you in Emacs 24.1 and 24.2:
>>>
>>> http://lists.gnu.org/archive/html/help-gnu-emacs/2012-10/msg00021.html
>>>
>>> So maybe the issue(s) is not new and is caused by some unusual
>>> circumstance on your machine.
>>
>> The initial problem was the user is setting `shell-file-name' to
>> "/path/to/bash" on a windows machine where the value is normally
>> "/path/to/cmdproxy.exe".
>> The result is that all externals programs made to be used with
>> "cmdproxy.exe" are crashing Emacs.
>> In the case of `helm', the user is crashing Emacs with the helm-locate
>> command which use the executable "es.exe" which is part of "everything"
>> program.
>> So I think these crash are not the fault of Emacs nor helm, but a bad
>> setting of user.
>>
>> So the question is:
>> Sebastien, are you still using shell-file-name==bash in your config ?
>
> The answer is yes:
>
>   ╭────
>   │ shell-file-name is a variable defined in `C source code'.
>   │ Its value is "c:/cygwin/bin/bash.exe"
>   ╰────
>
> IIRC, I was asked by Eli (or, at the very least, allowed) to set back Bash as
> my inferior shell.
>
> FYI, I'm using that setting since 1999, when I began really working with
> Emacs, and it did not cause any problems either with Helm (in that time,
> Anything) for the last years in which I used it (at least, from 2010).
At the beginning of anything, locate was not implemented for windows
with "everything", probably helm is working without crash if you use the
locate executable of your cygwin stuff instead of "everything".
So I repeat that helm itself is NOT crashing Emacs, but the backend used
by helm in an unsupported shell IS crashing Emacs.

> Problems began appearing with Emacs 24, IIRC.
This is not related to Emacs-24 IMO, same problem would happen in
Emacs-23 in same context.

> That does not mean I absolutely have to keep that setting, but this is _by far_
> my preferred one, as I'm using Cygwin Bash (or Zsh) all around the place, and
> I want to be able to do the exact same thing from withing Emacs: for example,
> calling one of my script on a selected region, or things like that.
Probably you should let-bind `shell-file-name' to "bash" or whatever
when calling your scripts from Emacs and leave the global value to its
default setting.

That say, probably Emacs should detect when calling a process if the
executable is compatible with value of `shell-file-name' and throw a big
old error if so before crashing Emacs, don't know if that is possible
though.
(probably it is what Eli want to fix)

-- 
Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: bug#13701: 24.2.93; Segmentation fault

[Sebastien Vauban]

Hi Thierry,

I'm replying with things I know are facts, in order for others not to be
confused by the configuration in which problems do appear.

Thierry Volpiatto wrote:
> "Sebastien Vauban" <wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw@public.gmane.org> writes:
>> Thierry Volpiatto wrote:
>>> Glenn Morris <rgm-mXXj517/zsQ@public.gmane.org> writes:
>>>> "Sebastien Vauban" wrote:
>>>>
>>>>> warning: sys_read called when read is in progress
>>>>
>>>> Searching for this message, I found that the only hit is crashes
>>>> previously reported by you in Emacs 24.1 and 24.2:
>>>>
>>>> http://lists.gnu.org/archive/html/help-gnu-emacs/2012-10/msg00021.html
>>>>
>>>> So maybe the issue(s) is not new and is caused by some unusual
>>>> circumstance on your machine.
>>>
>>> The initial problem was the user is setting `shell-file-name' to
>>> "/path/to/bash" on a windows machine where the value is normally
>>> "/path/to/cmdproxy.exe". The result is that all externals programs made to
>>> be used with "cmdproxy.exe" are crashing Emacs. In the case of `helm', the
>>> user is crashing Emacs with the helm-locate command which use the
>>> executable "es.exe" which is part of "everything" program. So I think
>>> these crash are not the fault of Emacs nor helm, but a bad setting of
>>> user.
>>>
>>> So the question is: Sebastien, are you still using shell-file-name==bash
>>> in your config ?
>>
>> The answer is yes:
>>
>>   ╭────
>>   │ shell-file-name is a variable defined in `C source code'.
>>   │ Its value is "c:/cygwin/bin/bash.exe"
>>   ╰────
>>
>> IIRC, I was asked by Eli (or, at the very least, allowed) to set back Bash
>> as my inferior shell.
>>
>> FYI, I'm using that setting since 1999, when I began really working with
>> Emacs, and it did not cause any problems either with Helm (in that time,
>> Anything) for the last years in which I used it (at least, from 2010).
>
> At the beginning of anything, locate was not implemented for windows with
> "everything"

When was that true?  Not anymore in 2010.

> probably helm is working without crash if you use the locate executable of
> your cygwin stuff instead of "everything".

No, never ever. Cygwin's locate is _not_ installed by default. And, in fact,
is not straightforward to get it installed and have it run every day or so.
You need to pass thru a long list of steps, much longer than simply selecting
the package and expecting it to be up and running (and up-to-date).

So, I never did use Cygwin locate at all.

When I say I used Anything back in 2010, it was already with Everything (and
es.exe).

> So I repeat that helm itself is NOT crashing Emacs, but the backend used by
> helm in an unsupported shell IS crashing Emacs.

Yes, when I refer to Helm, I never pinpoint it as being buggy. I refer to its
use, from the user perspective, and something somehow that breaks Emacs when
being used.

>> Problems began appearing with Emacs 24, IIRC.
>
> This is not related to Emacs-24 IMO, same problem would happen in Emacs-23
> in same context.

I really don't remember Emacs crashes with Emacs 23, with that same set of
tools:

- Bash (or Zsh) as my inferior shell in Emacs
- Helm (or Anything) with Everything (es.exe)

That did work, from 2010 to somewhere a couple of months ago.

>> That does not mean I absolutely have to keep that setting, but this is _by
>> far_ my preferred one, as I'm using Cygwin Bash (or Zsh) all around the
>> place, and I want to be able to do the exact same thing from withing Emacs:
>> for example, calling one of my script on a selected region, or things like
>> that.
>
> Probably you should let-bind `shell-file-name' to "bash" or whatever when
> calling your scripts from Emacs and leave the global value to its default
> setting.

By advicing shell-command-on-region and family?

> That say, probably Emacs should detect when calling a process if the
> executable is compatible with value of `shell-file-name' and throw a big old
> error if so before crashing Emacs, don't know if that is possible though.
> (probably it is what Eli want to fix)

I'll let them guide me toward the long-term solution.

Best regards,
  Seb

-- 
Sebastien Vauban

bug#13701: 24.2.93; Segmentation fault

[Eli Zaretskii]

> From: Thierry Volpiatto <thierry.volpiatto@gmail.com>
> Date: Wed, 13 Feb 2013 10:04:15 +0100
> Cc: 13701@debbugs.gnu.org
> 
> That say, probably Emacs should detect when calling a process if the
> executable is compatible with value of `shell-file-name' and throw a big
> old error if so before crashing Emacs, don't know if that is possible
> though.

It's not easy, at least.

> (probably it is what Eli want to fix)

Actually, I'm still trying to figure out what the heck happens on
Sebastien's machine ;-)

One problem with running programs via Bash or zsh is that these shells
catch and ignore signals, and who knows what they do with Windows
termination messages (which Emacs uses to kill subprocesses).  One
other problem, which is specific to Windows, is that the
TerminateProcess API does not kill child processes of the process we
kill, so that killing a shell might leave the programs it runs in the
system.  I see in Sebastien's reports that TerminateProcess is
sometimes called, which might be a symptom of the problem (Emacs
generally tries to avoid calling TerminateProcess, if it possibly
can).

Re: bug#13701: 24.2.93; Segmentation fault

[Sebastien Vauban]

Eli, Thierry,

Eli Zaretskii wrote:
>> From: Thierry Volpiatto <thierry.volpiatto-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> Date: Wed, 13 Feb 2013 10:04:15 +0100
>> Cc: 13701-ubl+/3LiMTaZdePnXv/OxA@public.gmane.org
>> 
>> That say, probably Emacs should detect when calling a process if the
>> executable is compatible with value of `shell-file-name' and throw a big
>> old error if so before crashing Emacs, don't know if that is possible
>> though.
>
> It's not easy, at least.
>
>> (probably it is what Eli want to fix)
>
> Actually, I'm still trying to figure out what the heck happens on
> Sebastien's machine ;-)
>
> One problem with running programs via Bash or zsh is that these shells
> catch and ignore signals, and who knows what they do with Windows
> termination messages (which Emacs uses to kill subprocesses).  One
> other problem, which is specific to Windows, is that the
> TerminateProcess API does not kill child processes of the process we
> kill, so that killing a shell might leave the programs it runs in the
> system.  I see in Sebastien's reports that TerminateProcess is
> sometimes called, which might be a symptom of the problem (Emacs
> generally tries to avoid calling TerminateProcess, if it possibly
> can).

Just to add on the confusion, in the v24.2.91, 92 and 93, for sure, I'm do not
have ghost processes anymore (I don't remember the correct name): ones I had
to kill via ProcessExplorer (for example) to let Emacs respond again to me.

But... I cannot really say it's because of changes done in the dev versions,
as I happened to have a new, and fast, machine since beginning of January 2013
(Asus i7 laptop with 4 GB RAM and 256 GB SSD -- with Windows 8). So, if time
is a variable, time constraints definitely changed on my new system.

For the rest, nothing changed[1]: Emacs, Cygwin, and the good friends.

Best regards,
  Seb

[1] Even if my .emacs evolves weekly, if not daily ;-)

-- 
Sebastien Vauban