runtime: do not crash in lastcontinuehandler when running as DLL #32574

simonferquel · 2019-06-12T12:37:09Z

If Go DLL is used by external C program, and lastcontinuehandler
is reached, lastcontinuehandler will crash the process it is
running in.

But it should not be up to Go runtime to decide if process to be
crashed or not - it should be up to C runtime. This CL adjusts
lastcontinuehandler to not to crash when running as DLL.

Fixes #32648.

googlebot · 2019-06-12T12:37:14Z

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed (or fixed any issues), please reply here (e.g. I signed it!) and we'll verify it.

What to do if you already signed the CLA

Individual signers

It's possible we don't have your GitHub username or you're using a different email address on your commit. Check your existing CLA data and verify that your email is set on your git commits.

Corporate signers

Your company has a Point of Contact who decides which employees are authorized to participate. Ask your POC to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the Google project maintainer to go/cla#troubleshoot (Public version).
The email used to register you as an authorized contributor must be the email used for the Git commit. Check your existing CLA data and verify that your email is set on your git commits.
The email used to register you as an authorized contributor must also be attached to your GitHub account.

ℹ️ Googlers: Go here for more info.

simonferquel · 2019-06-12T12:41:34Z

Note: I need help to setup a test covering this, as it won't be trivial:
I need to

setup a continue handler in C, after Go setups its own
have some go code calling C code, that raises an exception
check that the C continue handler is correctly called.

For now, I only have a manual test-case for this, but I assume this needs to be part of the Go automated test suite.

simonferquel · 2019-06-12T13:02:02Z

I signed it!

googlebot · 2019-06-12T13:02:10Z

CLAs look good, thanks!

ℹ️ Googlers: Go here for more info.

gopherbot · 2019-06-12T13:11:34Z

This PR (HEAD: 8b4e9c1) has been imported to Gerrit for code review.

Please visit https://go-review.googlesource.com/c/go/+/181839 to see it.

Tip: You can toggle comments from me using the comments slash command (e.g. /comments off)
See the Wiki page for more info

gopherbot · 2019-06-12T13:16:33Z

Message from Gobot Gobot:

Patch Set 1:

Congratulations on opening your first change. Thank you for your contribution!

Next steps:
Within the next week or so, a maintainer will review your change and provide
feedback. See https://golang.org/doc/contribute.html#review for more info and
tips to get your patch through code review.

Most changes in the Go project go through a few rounds of revision. This can be
surprising to people new to the project. The careful, iterative review process
is our way of helping mentor contributors and ensuring that their contributions
have a lasting impact.

During May-July and Nov-Jan the Go project is in a code freeze, during which
little code gets reviewed or merged. If a reviewer responds with a comment like
R=go1.11, it means that this CL will be reviewed as part of the next development
cycle. See https://golang.org/s/release for more details.

Please don’t reply on this GitHub thread. Visit golang.org/cl/181839.
After addressing review feedback, remember to publish your drafts!

gopherbot · 2019-06-15T07:39:48Z

Message from Alex Brainman:

Patch Set 1:

(2 comments)

Sorry, but I don't see why this change is needed. Please, create an issue https://golang.org/issue/new that shows how to reproduce this problem.

And change like this needs a test.

Alex

Please don’t reply on this GitHub thread. Visit golang.org/cl/181839.
After addressing review feedback, remember to publish your drafts!

gopherbot · 2019-06-17T07:33:30Z

Message from Simon Ferquel:

Patch Set 1:

Patch Set 1:

(2 comments)

Sorry, but I don't see why this change is needed. Please, create an issue https://golang.org/issue/new that shows how to reproduce this problem.

And change like this needs a test.

Alex

I will post more details in a GitHub issue. It only occurs when using cgo, because it happens when you are doing interop with other languages that might introduce their continue handlers after the go runtime.
E.g.:

run a go program
-> the runtime setup it's exception/continue handlers
attach a .net debugger
-> the .net debugger register its own continue handlers at the end of the continue handlers list
-> the .net debugger also injects a breakpoint exception triggered every time a native thread calls .net code, as well as on any breakpoint set by the user in her code.
the go program calls some .net code using cgo
the breakpoint exception is intercepted by the second continue handlers in the go runtime, before reaching the .net debugger handler, and the program panics.

If you don't attach the .net debugger, no breakpoint exception is injected, and everything runs fine.

Please don’t reply on this GitHub thread. Visit golang.org/cl/181839.
After addressing review feedback, remember to publish your drafts!

gopherbot · 2019-06-17T09:20:15Z

This PR (HEAD: cf0b236) has been imported to Gerrit for code review.

Please visit https://go-review.googlesource.com/c/go/+/181839 to see it.

Tip: You can toggle comments from me using the comments slash command (e.g. /comments off)
See the Wiki page for more info

gopherbot · 2019-06-17T09:26:25Z

Message from Simon Ferquel:

Patch Set 2:

Patch Set 1:

Patch Set 1:

(2 comments)

Sorry, but I don't see why this change is needed. Please, create an issue https://golang.org/issue/new that shows how to reproduce this problem.

And change like this needs a test.

Alex

I will post more details in a GitHub issue. It only occurs when using cgo, because it happens when you are doing interop with other languages that might introduce their continue handlers after the go runtime.
E.g.:

run a go program
-> the runtime setup it's exception/continue handlers

attach a .net debugger
-> the .net debugger register its own continue handlers at the end of the continue handlers list
-> the .net debugger also injects a breakpoint exception triggered every time a native thread calls .net code, as well as on any breakpoint set by the user in her code.

the go program calls some .net code using cgo

the breakpoint exception is intercepted by the second continue handlers in the go runtime, before reaching the .net debugger handler, and the program panics.

If you don't attach the .net debugger, no breakpoint exception is injected, and everything runs fine.

I added a test in a separated commit exhibiting the behavior, and rebased this PR on it. If you run the introduced test on a Windows machine, you'll see the test panic with:

Exception 0x80000003 0x0 0x0 0x7ffcd17d4052
PC=0x7ffcd17d4052

runtime: unknown pc 0x7ffcd17d4052
stack: frame={sp:0x87fd58, fp:0x0} stack=[0x0,0x87fdc0)
000000000087fc58:  0000000000000190  0000000002030000
000000000087fc68:  0000000000000000  000000000087fc90
000000000087fc78:  0000000000000003  0000000000000001
000000000087fc88:  00007ffcd3beae06  0000000000000004
000000000087fc98:  0000000000004000  00007ffcd3d4d000
000000000087fca8:  0000000000000003  00007ffcd3d4d3e0
000000000087fcb8:  00007ffcd3c4ed63  0000000000980740
000000000087fcc8:  000000c00004fed0  000000c00004fed0
000000000087fcd8:  00000000004c0000 <flag.(*FlagSet).parseOne+880>  0000000000000000
000000000087fce8:  000000c00004ffd0  0000000000000000
000000000087fcf8:  000000c00004ffc0  0000000002030000
000000000087fd08:  0000000000000000  000000c000050000
000000000087fd18:  00000000005070e5  000000c00004fed0
000000000087fd28:  000000c00004fe90  000000c00004fed0
000000000087fd38:  0000000000000000  000000c00004fed0
000000000087fd48:  00000000006595c0  000000c00004fed0
000000000087fd58: <000000000045b9f3 <runtime.asmcgocall+115>  0000000000000000
000000000087fd68:  0000000000000000  0000000000000000
000000000087fd78:  0000000000000001  000000c00004fe08
000000000087fd88:  00000000000001a0  000000c00003f200
000000000087fd98:  0000000000434bb0 <runtime.mstart+0>  0000000000172480
000000000087fda8:  000000000045a02c <runtime.rt0_go+332>  0000000000172480
000000000087fdb8:  000000000045a033 <runtime.rt0_go+339>
runtime: unknown pc 0x7ffcd17d4052
stack: frame={sp:0x87fd58, fp:0x0} stack=[0x0,0x87fdc0)
000000000087fc58:  0000000000000190  0000000002030000
000000000087fc68:  0000000000000000  000000000087fc90
000000000087fc78:  0000000000000003  0000000000000001
000000000087fc88:  00007ffcd3beae06  0000000000000004
000000000087fc98:  0000000000004000  00007ffcd3d4d000
000000000087fca8:  0000000000000003  00007ffcd3d4d3e0
000000000087fcb8:  00007ffcd3c4ed63  0000000000980740
000000000087fcc8:  000000c00004fed0  000000c00004fed0
000000000087fcd8:  00000000004c0000 <flag.(*FlagSet).parseOne+880>  0000000000000000
000000000087fce8:  000000c00004ffd0  0000000000000000
000000000087fcf8:  000000c00004ffc0  0000000002030000
000000000087fd08:  0000000000000000  000000c000050000
000000000087fd18:  00000000005070e5  000000c00004fed0
000000000087fd28:  000000c00004fe90  000000c00004fed0
000000000087fd38:  0000000000000000  000000c00004fed0
000000000087fd48:  00000000006595c0  000000c00004fed0
000000000087fd58: <000000000045b9f3 <runtime.asmcgocall+115>  0000000000000000
000000000087fd68:  0000000000000000  0000000000000000
000000000087fd78:  0000000000000001  000000c00004fe08
000000000087fd88:  00000000000001a0  000000c00003f200
000000000087fd98:  0000000000434bb0 <runtime.mstart+0>  0000000000172480
000000000087fda8:  000000000045a02c <runtime.rt0_go+332>  0000000000172480
000000000087fdb8:  000000000045a033 <runtime.rt0_go+339>

goroutine 7 [syscall]:
runtime/test._Cfunc_raiseException()
        _cgo_gotypes.go:67 +0x48
runtime/test.testLastContinueHandlerDoesNotEatNonGoException(0xc0000b0100)
        C:/Users/simon/gitrepos/golang/go/src/runtime/test/testsignal_windows.go:46 +0x69
runtime/test.TestLastContinueHandlerDoesNotEatNonGoException(0xc0000b0100)
        C:/Users/simon/gitrepos/golang/go/src/runtime/test/signal_windows_test.go:8 +0x32
testing.tRunner(0xc0000b0100, 0x57d890)
        C:/Users/simon/gitrepos/golang/go/src/testing/testing.go:909 +0xd0
created by testing.(*T).Run
        C:/Users/simon/gitrepos/golang/go/src/testing/testing.go:960 +0x357

goroutine 1 [chan receive]:
testing.(*T).Run(0xc0000b0100, 0x57bcfa, 0x2f, 0x57d890, 0x47b3dd)
        C:/Users/simon/gitrepos/golang/go/src/testing/testing.go:961 +0x37e
testing.runTests.func1(0xc0000b0000)
        C:/Users/simon/gitrepos/golang/go/src/testing/testing.go:1207 +0x7f
testing.tRunner(0xc0000b0000, 0xc000083dc0)
        C:/Users/simon/gitrepos/golang/go/src/testing/testing.go:909 +0xd0
testing.runTests(0xc0000044c0, 0x51a190, 0x1, 0x1, 0x0)
        C:/Users/simon/gitrepos/golang/go/src/testing/testing.go:1205 +0x2ae
testing.(*M).Run(0xc00008c080, 0x0)
        C:/Users/simon/gitrepos/golang/go/src/testing/testing.go:1122 +0x17d
main.main()
        _testmain.go:44 +0x13c

Applying the second commit fixes the test, but there is a test relying on the broken behavior somewhere else:

    crash_test.go:95: testprog Abort exit status: exit status 2147483651
    crash_test.go:646: output does not contain "runtime.abort":
    crash_test.go:666: output does not contain "Exception 0x80000003":
--- FAIL: TestRaiseException (0.24s)
    crash_test.go:95: testprog RaiseException exit status: exit status 2989
    syscall_windows_test.go:543: No stack trace:

Please don’t reply on this GitHub thread. Visit golang.org/cl/181839.
After addressing review feedback, remember to publish your drafts!

gopherbot · 2019-06-17T09:32:23Z

Message from Simon Ferquel:

Patch Set 2:

I wonder if it would make sense to allow only a subset of exception types to be propagated to another continue handler. I guess BREAKPOINT_EXCEPTION makes sense for CGO enabled programs, so I could modify the PR to return CONTINUE_SEARCH only if the exception type is BREAKPOINT_EXCEPTION and it happened in non-go code.

Please don’t reply on this GitHub thread. Visit golang.org/cl/181839.
After addressing review feedback, remember to publish your drafts!

gopherbot · 2019-06-17T11:09:30Z

Message from Simon Ferquel:

Patch Set 2:

Also, I can think of another approach to fix the issue: the main reason for this bug, is that the runtime wrongly assumes that lastcontinuehandler is always the last handler in the continue handler vector. When using non-go debuggers, that might be wrong, but we can correct this:
Instead of registering the lastcontinuehandler on init, we can defer that to just before firstcontinuehandler returns CONTINUE_SEARCH (and make sure we cleanup the lastcontinuehandler registration at the beginning of firstcontinuehandler).
This way, we ensure that at any time, the lastcontinuehandler is always the last one in the chain, and that any debugger can handle breakpoints correctly.
WDYT?

Please don’t reply on this GitHub thread. Visit golang.org/cl/181839.
After addressing review feedback, remember to publish your drafts!

gopherbot · 2019-06-18T08:36:26Z

Message from Alex Brainman:

Patch Set 2:

(3 comments)

Please don’t reply on this GitHub thread. Visit golang.org/cl/181839.
After addressing review feedback, remember to publish your drafts!

gopherbot · 2019-06-18T10:39:33Z

Message from Simon Ferquel:

Patch Set 2:

(2 comments)

Answered the comments in code, and also added a repro with a walkthrough video here: #32648

I understand that this change of behavior is pretty big, and I would be happy to prototype other approaches to fix the problem with your guidance.

It is pretty frustrating because c-shared works fine on Windows, except you can't debug anything but go code (and until this is solved, I don't want to leverage it in production workloads)

Please don’t reply on this GitHub thread. Visit golang.org/cl/181839.
After addressing review feedback, remember to publish your drafts!

gopherbot · 2019-06-19T07:38:41Z

Message from Alex Brainman:

Patch Set 2:

(3 comments)

I am travelling for the next month, so I might not have computers and Internet at times.

And we cannot submit this change until after go 1.13 is released, and Go tree will open again (some time in August). So, hopefully, we will be ready by then.

Thank you.

Alex

Please don’t reply on this GitHub thread. Visit golang.org/cl/181839.
After addressing review feedback, remember to publish your drafts!

gopherbot · 2019-06-19T14:20:42Z

This PR (HEAD: efb9f1b) has been imported to Gerrit for code review.

Please visit https://go-review.googlesource.com/c/go/+/181839 to see it.

Tip: You can toggle comments from me using the comments slash command (e.g. /comments off)
See the Wiki page for more info

gopherbot · 2019-06-19T14:55:01Z

This PR (HEAD: 017a542) has been imported to Gerrit for code review.

Please visit https://go-review.googlesource.com/c/go/+/181839 to see it.

Tip: You can toggle comments from me using the comments slash command (e.g. /comments off)
See the Wiki page for more info

gopherbot · 2019-06-19T15:10:30Z

Message from Simon Ferquel:

Patch Set 4:

(4 comments)

I've basically rewritten the whole test as an integration test more resembling to a real world scenario.
I also modified the fix so that it is applied only if go code has been build in c-shared or c-archive.

Please don’t reply on this GitHub thread. Visit golang.org/cl/181839.
After addressing review feedback, remember to publish your drafts!

gopherbot · 2019-06-19T15:10:43Z

This PR (HEAD: 78b33c1) has been imported to Gerrit for code review.

Please visit https://go-review.googlesource.com/c/go/+/181839 to see it.

Tip: You can toggle comments from me using the comments slash command (e.g. /comments off)
See the Wiki page for more info

gopherbot · 2019-07-14T06:55:43Z

Message from Alex Brainman:

Patch Set 5: Run-TryBot+1

(13 comments)

Some comments, thank you very much.

Alex

Please don’t reply on this GitHub thread. Visit golang.org/cl/181839.
After addressing review feedback, remember to publish your drafts!

gopherbot · 2019-07-14T06:56:59Z

Message from Gobot Gobot:

Patch Set 5:

TryBots beginning. Status page: https://farmer.golang.org/try?commit=cbe47382

Please don’t reply on this GitHub thread. Visit golang.org/cl/181839.
After addressing review feedback, remember to publish your drafts!

gopherbot · 2019-07-14T07:06:35Z

Message from Gobot Gobot:

Patch Set 5: TryBot-Result+1

TryBots are happy.

Please don’t reply on this GitHub thread. Visit golang.org/cl/181839.
After addressing review feedback, remember to publish your drafts!

gopherbot · 2019-07-31T12:44:08Z

This PR (HEAD: e0fd37e) has been imported to Gerrit for code review.

Please visit https://go-review.googlesource.com/c/go/+/181839 to see it.

Tip: You can toggle comments from me using the comments slash command (e.g. /comments off)
See the Wiki page for more info

gopherbot · 2019-07-31T12:46:19Z

Message from Simon Ferquel:

Patch Set 5:

(13 comments)

Just updated the PR with changes requested by Alex Brainman.
Sorry I could not resume working on this earlier!

Please don’t reply on this GitHub thread. Visit golang.org/cl/181839.
After addressing review feedback, remember to publish your drafts!

This test reproduces a golang dll run from within a C program with a debugger attached. It emulates the behavior of a debugger handling a breakpoint in C code called back by GO code. Signed-off-by: Simon Ferquel <[email protected]>

If Go DLL is used by external C program, and lastcontinuehandler is reached, lastcontinuehandler will crash the process it is running in. But it should not be up to Go runtime to decide if process to be crashed or not - it should be up to C runtime. This CL adjusts lastcontinuehandler to not to crash when running as DLL. Fixes golang#32648.

gopherbot · 2019-07-31T12:57:36Z

This PR (HEAD: a5f71ea) has been imported to Gerrit for code review.

Please visit https://go-review.googlesource.com/c/go/+/181839 to see it.

Tip: You can toggle comments from me using the comments slash command (e.g. /comments off)
See the Wiki page for more info

gopherbot · 2019-07-31T12:59:41Z

Message from Simon Ferquel:

Patch Set 7:

Patch Set 5:

(13 comments)

Just updated the PR with changes requested by Alex Brainman.
Sorry I could not resume working on this earlier!

Also just rebased for having an up-to-date base

Please don’t reply on this GitHub thread. Visit golang.org/cl/181839.
After addressing review feedback, remember to publish your drafts!

gopherbot · 2019-07-31T13:00:54Z

Message from Simon Ferquel:

Patch Set 8: Commit message was updated.

Please don’t reply on this GitHub thread. Visit golang.org/cl/181839.
After addressing review feedback, remember to publish your drafts!

gopherbot · 2019-07-31T13:42:34Z

Message from Simon Ferquel:

Patch Set 10: Commit message was updated.

Please don’t reply on this GitHub thread. Visit golang.org/cl/181839.
After addressing review feedback, remember to publish your drafts!

gopherbot · 2019-07-31T13:57:53Z

Message from Simon Ferquel:

Patch Set 11:

(14 comments)

Struggling with the commit message. Otherwise I think it is pretty much done.

Please don’t reply on this GitHub thread. Visit golang.org/cl/181839.
After addressing review feedback, remember to publish your drafts!

gopherbot · 2019-08-04T06:06:13Z

Message from Alex Brainman:

Patch Set 11:

(1 comment)

I am still reviewing your code, but decided to reply to your commit message question first. So you can update CL without waiting for me to finish review.

Thank you.

Alex

Please don’t reply on this GitHub thread. Visit golang.org/cl/181839.
After addressing review feedback, remember to publish your drafts!

gopherbot · 2019-08-04T06:19:09Z

Message from Agniva De Sarker:

Patch Set 11:

(1 comment)

Please don’t reply on this GitHub thread. Visit golang.org/cl/181839.
After addressing review feedback, remember to publish your drafts!

gopherbot · 2019-08-04T06:30:21Z

Message from Alex Brainman:

Patch Set 11: Run-TryBot+1

(2 comments)

Just one comment. And I am waiting to see your final commit message.

Thank you.

Alex

Please don’t reply on this GitHub thread. Visit golang.org/cl/181839.
After addressing review feedback, remember to publish your drafts!

gopherbot · 2019-08-04T06:31:15Z

Message from Gobot Gobot:

Patch Set 11:

TryBots beginning. Status page: https://farmer.golang.org/try?commit=8635b7ea

Please don’t reply on this GitHub thread. Visit golang.org/cl/181839.
After addressing review feedback, remember to publish your drafts!

gopherbot · 2019-08-04T06:41:40Z

Message from Gobot Gobot:

Patch Set 11: TryBot-Result+1

TryBots are happy.

Please don’t reply on this GitHub thread. Visit golang.org/cl/181839.
After addressing review feedback, remember to publish your drafts!

Signed-off-by: Simon Ferquel <[email protected]>

gopherbot · 2019-08-05T11:28:56Z

This PR (HEAD: dbdffcb) has been imported to Gerrit for code review.

Please visit https://go-review.googlesource.com/c/go/+/181839 to see it.

Tip: You can toggle comments from me using the comments slash command (e.g. /comments off)
See the Wiki page for more info

gopherbot · 2019-08-05T11:30:01Z

Message from Simon Ferquel:

Patch Set 13:

(18 comments)

New patch upcoming with typo fix

Please don’t reply on this GitHub thread. Visit golang.org/cl/181839.
After addressing review feedback, remember to publish your drafts!

gopherbot · 2019-08-14T10:01:13Z

Message from Alex Brainman:

Patch Set 14: Run-TryBot+1

Please don’t reply on this GitHub thread. Visit golang.org/cl/181839.
After addressing review feedback, remember to publish your drafts!

gopherbot · 2019-08-14T10:01:15Z

Message from Gobot Gobot:

Patch Set 14:

TryBots beginning. Status page: https://farmer.golang.org/try?commit=7d5d7049

Please don’t reply on this GitHub thread. Visit golang.org/cl/181839.
After addressing review feedback, remember to publish your drafts!

gopherbot · 2019-08-14T10:11:41Z

Message from Gobot Gobot:

Patch Set 14: TryBot-Result+1

TryBots are happy.

Please don’t reply on this GitHub thread. Visit golang.org/cl/181839.
After addressing review feedback, remember to publish your drafts!

gopherbot · 2019-08-14T10:19:39Z

Message from Alex Brainman:

Patch Set 14:

This CL LGTM. Thank you very much.

I will submit this CL once Go tree opens for submission as per

https://groups.google.com/d/msg/golang-dev/UQOSRilopzw/Xtth3MQmAgAJ

Feel free to ping me here, so I don't forget.

Alex

Please don’t reply on this GitHub thread. Visit golang.org/cl/181839.
After addressing review feedback, remember to publish your drafts!

If Go DLL is used by external C program, and lastcontinuehandler is reached, lastcontinuehandler will crash the process it is running in. But it should not be up to Go runtime to decide if process to be crashed or not - it should be up to C runtime. This CL adjusts lastcontinuehandler to not to crash when running as DLL. Fixes #32648. Change-Id: Ia455e69b8dde2a6f42f06b90e8af4aa322ca269a GitHub-Last-Rev: dbdffcb GitHub-Pull-Request: #32574 Reviewed-on: https://go-review.googlesource.com/c/go/+/181839 Run-TryBot: Alex Brainman <[email protected]> TryBot-Result: Gobot Gobot <[email protected]> Reviewed-by: Alex Brainman <[email protected]>

gopherbot · 2019-08-31T00:52:20Z

Message from Alex Brainman:

Patch Set 14: Code-Review+2

Please don’t reply on this GitHub thread. Visit golang.org/cl/181839.
After addressing review feedback, remember to publish your drafts!

gopherbot · 2019-08-31T00:57:22Z

This PR is being closed because golang.org/cl/181839 has been merged.

If Go DLL is used by external C program, and lastcontinuehandler is reached, lastcontinuehandler will crash the process it is running in. But it should not be up to Go runtime to decide if process to be crashed or not - it should be up to C runtime. This CL adjusts lastcontinuehandler to not to crash when running as DLL. Fixes golang#32648. Change-Id: Ia455e69b8dde2a6f42f06b90e8af4aa322ca269a GitHub-Last-Rev: dbdffcb GitHub-Pull-Request: golang#32574 Reviewed-on: https://go-review.googlesource.com/c/go/+/181839 Run-TryBot: Alex Brainman <[email protected]> TryBot-Result: Gobot Gobot <[email protected]> Reviewed-by: Alex Brainman <[email protected]>

googlebot added the cla: no Used by googlebot to label PRs as having an invalid CLA. The text of this label should not change. label Jun 12, 2019

googlebot added cla: yes Used by googlebot to label PRs as having a valid CLA. The text of this label should not change. and removed cla: no Used by googlebot to label PRs as having an invalid CLA. The text of this label should not change. labels Jun 12, 2019

simonferquel force-pushed the fix-signal-windows-non-go-exceptions branch from 8b4e9c1 to cf0b236 Compare June 17, 2019 09:19

simonferquel mentioned this pull request Jun 17, 2019

runtime: On Windows, lastcontinuehandler intercepts exception raised in non-go code #32648

Closed

simonferquel force-pushed the fix-signal-windows-non-go-exceptions branch from cf0b236 to efb9f1b Compare June 19, 2019 14:20

simonferquel force-pushed the fix-signal-windows-non-go-exceptions branch from efb9f1b to 017a542 Compare June 19, 2019 14:54

simonferquel force-pushed the fix-signal-windows-non-go-exceptions branch from 017a542 to 78b33c1 Compare June 19, 2019 15:09

simonferquel force-pushed the fix-signal-windows-non-go-exceptions branch from 78b33c1 to e0fd37e Compare July 31, 2019 12:43

simonferquel added 2 commits July 31, 2019 14:56

Add a test for continue handler and non-go program

1c7a0ff

This test reproduces a golang dll run from within a C program with a debugger attached. It emulates the behavior of a debugger handling a breakpoint in C code called back by GO code. Signed-off-by: Simon Ferquel <[email protected]>

simonferquel force-pushed the fix-signal-windows-non-go-exceptions branch from e0fd37e to a5f71ea Compare July 31, 2019 12:57

simonferquel changed the title ~~runtime: ignore exceptions from non-go code in lastcontinuehandler on Windows~~ runtime: do not crash in lastcontinuehandler when running as DLL Aug 5, 2019

Typo fix

dbdffcb

Signed-off-by: Simon Ferquel <[email protected]>

gopherbot closed this Aug 31, 2019

runtime: do not crash in lastcontinuehandler when running as DLL #32574

runtime: do not crash in lastcontinuehandler when running as DLL #32574

Conversation

simonferquel commented Jun 12, 2019 • edited Loading

googlebot commented Jun 12, 2019

What to do if you already signed the CLA

Individual signers

Corporate signers

simonferquel commented Jun 12, 2019

simonferquel commented Jun 12, 2019

googlebot commented Jun 12, 2019

gopherbot commented Jun 12, 2019

gopherbot commented Jun 12, 2019

gopherbot commented Jun 15, 2019

gopherbot commented Jun 17, 2019

gopherbot commented Jun 17, 2019

gopherbot commented Jun 17, 2019

gopherbot commented Jun 17, 2019

gopherbot commented Jun 17, 2019

gopherbot commented Jun 18, 2019

gopherbot commented Jun 18, 2019

gopherbot commented Jun 19, 2019

gopherbot commented Jun 19, 2019

gopherbot commented Jun 19, 2019

gopherbot commented Jun 19, 2019

gopherbot commented Jun 19, 2019

gopherbot commented Jul 14, 2019

gopherbot commented Jul 14, 2019

gopherbot commented Jul 14, 2019

gopherbot commented Jul 31, 2019

gopherbot commented Jul 31, 2019

gopherbot commented Jul 31, 2019

gopherbot commented Jul 31, 2019

gopherbot commented Jul 31, 2019

gopherbot commented Jul 31, 2019

gopherbot commented Jul 31, 2019

gopherbot commented Aug 4, 2019

gopherbot commented Aug 4, 2019

gopherbot commented Aug 4, 2019

gopherbot commented Aug 4, 2019

gopherbot commented Aug 4, 2019

gopherbot commented Aug 5, 2019

gopherbot commented Aug 5, 2019

gopherbot commented Aug 14, 2019

gopherbot commented Aug 14, 2019

gopherbot commented Aug 14, 2019

gopherbot commented Aug 14, 2019

gopherbot commented Aug 31, 2019

gopherbot commented Aug 31, 2019

simonferquel commented Jun 12, 2019 •

edited

Loading