New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
runtime: make crashing more useful on Windows #20498
Comments
/cc @alexbrainman |
Try setting the environment variable |
I should mention that |
@ianlancetaylor, thanks, I didn't know about GOTRACEBACK, but it doesn't help here as "crashes in an operating system-specific manner" for Windows is currently a no-op with a TODO comment. See runtime/signal_windows.go (and my second suggestion above): func crash() {
// TODO: This routine should do whatever is needed
// to make the Windows program abort/crash as it
// would if Go was not intercepting signals.
// On Unix the routine would remove the custom signal
// handler and then raise a signal (like SIGABRT).
// Something like that should happen here.
// It's okay to leave this empty for now: if crash returns
// the ordinary exit-after-panic happens.
} |
@ianlancetaylor |
Sounds good to me.
That is agreeble from me, thank you.
I did know about GOTRACEBACK, but I did not know about "crashes in an operating system-specific manner instead of exiting" if GOTRACEBACK=crash. So the "crashing" part is not implemented on Windows.
Correct.
Correct. And that is what @bhiggins is proposing to add. I think we are all on the same page. Alex |
We have a go+C program on Windows. In absence of coredump, it is hard for us to root cause errors in the C code. Will really appreciate resolution of this issue. |
@usirsiwal try changing runtime yourself and see if it helps you. And if it works for you, submit it here to help others. If you have problems, just ask for help here. Alex |
@alexbrainman I will try the runtime change and see if it works for us. |
Hello, Thanks,
|
@usirsiwal @bhiggins i use https://msdn.microsoft.com/en-us/library/windows/desktop/bb787181(v=vs.85).aspx and try modify runtime according to the above. |
Change https://golang.org/cl/195577 mentions this issue: |
there's note about WER ui dialog to avoid to run binaries in self-maintained mode. |
Is it possible to collect a crash/core dump on windows from an application? I tried setting GOTRACEBACK=crash and I can only get a crashdump using RaiseFailFastException. However, that dump is not very usable in delve. It does not have the stack trace of the crashing thread (I'm pretty sure I need to set the Context, but, I don't know to what). Other go routine's show up all right. |
Yes, you need to modify Go. You need something like https://go-review.googlesource.com/c/go/+/195577/
I just discovered RaiseFailFastException. But, yes, RaiseFailFastException might do the trick. The only problem, how do you propose to call RaiseFailFastException when real crash happen? For that you need CL 195577 or similar.
Correct. Delve does not understand Microsoft crash dumps. Microsoft debuggers do. Like WinDbg.
I don't understand this comment. Alex |
Actually, it does. Sort of. I've only ever tested with minidumps created by procdump.exe I don't know why the ones created the... "natural" way don't work. |
Thanks for correcting me. I hardly ever use Delve, so I don't keep up with the features. How did you implement the code that reads minidumps? Can you point me to the code? Thank you. Alex |
microsoft documented it https://docs.microsoft.com/en-us/windows/win32/api/minidumpapiset/ns-minidumpapiset-minidump_header
https://github.com/go-delve/delve/blob/master/pkg/proc/core/minidump/minidump.go |
Nice code too. Alex |
Change https://golang.org/cl/271991 mentions this issue: |
Now that there's a change proposed, could this possibly be tagged for Go 1.17 so that this doesn't get missed? This would be a great improvement to post-mortem diagnostics on Windows. |
Change https://golang.org/cl/307372 mentions this issue: |
I just submitted a third attempt to fix this issue. The change is mostly based on what bhiggins has done(https://go-review.googlesource.com/c/go/+/195577/), but two of the code reviewer's questions are addressed:
|
Change https://golang.org/cl/360617 mentions this issue: |
It appears Windows 7 ignores WER_FAULT_REPORTING_NO_UI WerSetFlags API flag. And now after CL 307372, runtime will display WER GUI dialogue. We don't want to introduce random GUI dialogues during Go program execution. So disable dump crash creation on Windows 7 altogether. Updates #20498 Change-Id: Ie268a7d4609f8a0eba4fe9ecf250856b0a61b331 Reviewed-on: https://go-review.googlesource.com/c/go/+/360617 Trust: Alex Brainman <alex.brainman@gmail.com> Run-TryBot: Alex Brainman <alex.brainman@gmail.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Patrik Nyblom <pnyb@google.com>
Done. Alex |
Moving to backlog. |
What did you do?
Triggered an access violation, crashing the program.
What did you expect to see?
We configured user-mode dumps and were hoping to get a dump (either a full dump or a minidump). See: https://msdn.microsoft.com/en-us/library/windows/desktop/bb787181(v=vs.85).aspx
What did you see instead?
No dump.
Two suggestions:
We can submit a PR if this is agreeable.
The text was updated successfully, but these errors were encountered: