code review 7202053: lib9/main.c: don't show the crash dialog on windows

lib9/main.c: don't show the crash dialog on windows
Fixes issue 3202. (Or rather, work around issue 3202)

[minux1, 2013-01-25 00:13:50]

Hello alex.brainman@gmail.com, rsc@golang.org (cc: golang-dev@googlegroups.com),

I'd like you to review this change to
https://code.google.com/p/go/

[minux1, 2013-01-25 00:20:49]

if necessary, we can catch the most common error by adding:
signal(SIGBUS, defaulthandler);
signal(SIGSEGV, defaulthandler);
to main().

because this change will completely stop the "Your application has crashed"
dialog from opening so if the program does trigger that, it will exit
silently
(if the signal is not being caught)

so we can add a defaulthandler() that just print("%s: fault", argv0); and
then
exit to avoid the program exit silently.

also, should i apply the same change to cmd/dist?

[brainman, 2013-01-25 00:25:45]

I have no computer here. I will look at it next week. Sorry.

Alex

[minux1, 2013-01-25 00:27:49]

On Fri, Jan 25, 2013 at 8:25 AM, <alex.brainman@gmail.com> wrote:

> I have no computer here. I will look at it next week. Sorry.
>
sure, i can wait. :)

[brainman, 2013-01-30 01:54:25]

LGTM

Thank you very much.

Alex

On 2013/01/25 00:20:49, minux wrote:
> ...
> 
> so we can add a defaulthandler() that just print("%s: fault", argv0); and
> then
> exit to avoid the program exit silently.

I am not sure about cost and benefits. The program will exit with an error exit
code, so it is not silent as such. On the other hand, handlers means extra code
to maintain. What can you add in handler above error exit code? What is allowed
to do inside of handler? Can you print there?

> 
> also, should i apply the same change to cmd/dist?

I wouldn't do it. It is simple enough and rarely changed. Now that you have
found the way, we could always add it when it hurts. :-)

https://codereview.appspot.com/7202053/diff/4002/src/lib9/main.c
File src/lib9/main.c (right):

https://codereview.appspot.com/7202053/diff/4002/src/lib9/main.c#newcode40
src/lib9/main.c:40: SetErrorMode(SEM_FAILCRITICALERRORS | SEM_NOGPFAULTERRORBOX
| SEM_NOOPENFILEERRORBOX);
Should you do a "double-shuffle"
http://blogs.msdn.com/b/oldnewthing/archive/2004/07/27/198410.aspx here?

[minux1, 2013-02-02 17:26:09]

PTAL.

On 2013/01/30 01:54:25, brainman wrote:
> On 2013/01/25 00:20:49, minux wrote:
> > ...
> > 
> > so we can add a defaulthandler() that just print("%s: fault", argv0); and
> > then
> > exit to avoid the program exit silently.
> 
> I am not sure about cost and benefits. The program will exit with an error
exit
> code, so it is not silent as such. On the other hand, handlers means extra
code
> to maintain. What can you add in handler above error exit code? What is
allowed
> to do inside of handler? Can you print there?
I've mirrored what we do for cmd/gc for crashes. 
> https://codereview.appspot.com/7202053/diff/4002/src/lib9/main.c#newcode40
> src/lib9/main.c:40: SetErrorMode(SEM_FAILCRITICALERRORS |
SEM_NOGPFAULTERRORBOX
> | SEM_NOOPENFILEERRORBOX);
> Should you do a "double-shuffle"
> http://blogs.msdn.com/b/oldnewthing/archive/2004/07/27/198410.aspx here?
Done.

[rsc, 2013-02-02 21:28:06]

LGTM

[brainman, 2013-02-02 21:38:24]

https://codereview.appspot.com/7202053/diff/10002/src/lib9/main.c
File src/lib9/main.c (right):

https://codereview.appspot.com/7202053/diff/10002/src/lib9/main.c#newcode46
src/lib9/main.c:46: signal(SIGBUS, crashhandler);
From signal doco:

The list below summarizes restrictions that determine which functions you can
use in your signal-handler routine.
Do not issue low-level or STDIO.H I/O routines (such as printf and fread).
Do not call heap routines or any routine that uses the heap routines (such as
malloc, _strdup, and _putenv). See malloc for more information.
Do not use any function that generates a system call (e.g., _getcwd, time).
Do not use longjmp unless the interrupt is caused by a floating-point exception
(i.e., sig is SIGFPE). In this case, first reinitialize the floating-point
package with a call to _fpreset.
Do not use any overlay routines.

Do we want to take the risk?

[minux1, 2013-02-02 21:54:04]

On Sun, Feb 3, 2013 at 5:38 AM, <alex.brainman@gmail.com> wrote:

> https://codereview.appspot.**com/7202053/diff/10002/src/**
>
lib9/main.c#newcode46<https://codereview.appspot.com/7202053/diff/10002/src/lib9/main.c#newcode46>
> src/lib9/main.c:46: signal(SIGBUS, crashhandler);
> From signal doco:
>
> The list below summarizes restrictions that determine which functions
> you can use in your signal-handler routine.
> Do not issue low-level or STDIO.H I/O routines (such as printf and
> fread).
> Do not call heap routines or any routine that uses the heap routines
> (such as malloc, _strdup, and _putenv). See malloc for more information.
> Do not use any function that generates a system call (e.g., _getcwd,
> time).
> Do not use longjmp unless the interrupt is caused by a floating-point
> exception (i.e., sig is SIGFPE). In this case, first reinitialize the
> floating-point package with a call to _fpreset.
> Do not use any overlay routines.
>
> Do we want to take the risk?
>
i think we could take the risk to provide some info. to the user, and
this's what
we already do for cmd/gc.

not to mention the fact that most windows user don't have the habit of echo
%errorlevel% after some mysterious command failure (without the message
the user might not even know that the command failed).

[brainman, 2013-02-02 22:06:14]

I am fine with that, if you see it works on your computer. I don't have one now
to check.

Alex

[minux1, 2013-02-02 22:11:41]

*** Submitted as https://code.google.com/p/go/source/detail?r=c23760174a83 ***

lib9/main.c: don't show the crash dialog on windows
Fixes issue 3202. (Or rather, work around issue 3202)

R=alex.brainman, rsc
CC=golang-dev
https://codereview.appspot.com/7202053