code review 108890045: [release-branch.go1.3] runtime: revise CL 105140044 (de...

[release-branch.go1.3] runtime: revise CL 105140044 (defer nil) to work on Windows

««« CL 105120044 / 824ea5943ba8
runtime: revise CL 105140044 (defer nil) to work on Windows

It appears that something about Go on Windows
cannot handle the fault cause by a jump to address 0.
The way Go represents and calls functions, this
never happened at all, until CL 105140044.

This CL changes the code added in CL 105140044
to make jump to 0 impossible once again.

Fixes issue 8047. (again, on Windows)

TBR=bradfitz
R=golang-codereviews, dave
CC=adg, golang-codereviews, iant, r
https://codereview.appspot.com/105120044
»»»

[rsc, 2014-06-13 01:14:11]

Hello golang-codereviews@googlegroups.com (cc: adg),

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

[bradfitz, 2014-06-13 01:14:36]

LGTM

[brainman, 2014-06-13 01:30:49]

It builds OK here on both 386 and amd64. I will investigate why test crashes
with no stack trace.

Thank you.

Alex

[rsc, 2014-06-13 01:52:51]

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

[release-branch.go1.3] runtime: revise CL 105140044 (defer nil) to work on
Windows

««« CL 105120044 / 824ea5943ba8
runtime: revise CL 105140044 (defer nil) to work on Windows

It appears that something about Go on Windows
cannot handle the fault cause by a jump to address 0.
The way Go represents and calls functions, this
never happened at all, until CL 105140044.

This CL changes the code added in CL 105140044
to make jump to 0 impossible once again.

Fixes issue 8047. (again, on Windows)

TBR=bradfitz
R=golang-codereviews, dave
CC=adg, golang-codereviews, iant, r
https://codereview.appspot.com/105120044
»»»

LGTM=bradfitz
R=golang-codereviews, bradfitz, alex.brainman
CC=adg, golang-codereviews
https://codereview.appspot.com/108890045

[brainman, 2014-06-13 02:52:17]

On 2014/06/13 01:30:49, brainman wrote:
> ... I will investigate why test crashes
> with no stack trace.

It is a variation of https://code.google.com/p/go/issues/detail?id=8006. We call
function at 0 address, our exception handler is called, but we don't handle
exception, because of this condition
http://tip.golang.org/src/pkg/runtime/os_windows_386.c#L52. So default windows
exception handler is called - Dr Watson or whatever it is called.

I have some ideas about how to fix issue 8006. So I will work on that.

Alex