go runtime in DLL not getting intialized(?) on some windows hosts

[Jason E. Aten]

I'm stumped on why the Go runtime would not be initialized inside my c-shared DLL.

I'm building a mixed Go and C DLL for windows, using

go build -buildmode=c-shared

On one instance of Windows 2016, everything runs fine, both with go1.12.5 and with go1.10.8.

However, on an instance of Windows 10, and a second instance of Windows 2016, the exact

same DLL will crash because it appears the Go runtime has not been initialized. 

I say I don't think the Go runtime has been initialized because 

1) the init() routines have not been run even after DllMain has returned and 

subsequently the C host code has called into the main C function for the DLL. 

2) At the point at which the C code first calls into the Go code, we crash. This takes down the process.

I turned off DEP and I still get the crash.

I wondering if anyone can shed some light on

a) how I might understand when the Go runtime inside a DLL is supposed to be initialized;

and 

b) how I might generate hypotheses as to why it isn't getting initialized under certain circumstances.

Brainstorms welcome. Thanks for your thoughts!

-J

[Ian Lance Taylor]

On Fri, May 10, 2019 at 1:43 PM Jason E. Aten <j.e....@gmail.com> wrote:
>
> I wondering if anyone can shed some light on
>
> a) how I might understand when the Go runtime inside a DLL is supposed to be initialized;

In c-shared mode the function _rt0_amd64_windows_lib is supposed to be
called when the DLL is initialized. That function, in
runtime/rt0_windows_amd64.s, should start a new thread that will
initialize the Go runtime.

The Windows support for c-shared is very new, and perhaps there are
some circumstances in which it does not arrange for
rt0_amd64_windows_lib to be run when the DLL is loaded. I'm not sure
but I think the code that sets this up is (*peFile).addInitArray in
cmd/link/internal/ld/pe.go. So make sure that method is being called,
and then make sure it is doing the right thing.

Ian

[Jason E. Aten]

Installing the Go build environment locally on the deploy host fixed the crash. I'm guessing it is probably the missing timezone data on Windows, as in

https://github.com/golang/go/issues/21881

or some other assumption by the runtime inside the DLL that it is running on a machine that has the Go build environment installed.

On Saturday, May 11, 2019 at 2:42:40 AM UTC+2, Ian Lance Taylor wrote:

[Jason E. Aten]

Indeed, confirming data: I can re-create the crashing circumstances immediately by renaming C:\Go to C:\Go1.12.5.

[andrey mirtchovski]

file an issue, please, if you have not done so already. i'd like to follow it.

> --
> You received this message because you are subscribed to the Google Groups "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/43733e84-b762-4c33-a8bc-047689bfdb4a%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Jason E. Aten]

Further confirmation: with the env var GOROOT set to C:\Go, it is sufficient to have exactly one file under then entire C:\Go directory tree: C:\Go\lib\time\zoneinfo.zip  alone allows the Go runtime to start cleanly inside the DLL. The zoneinfo.zip file allows the runtime to start.

We should really include zoneinfo.zip, a tiny 365K file, with the runtime on windows.

[Jason E. Aten]

andrey: voice your support on https://github.com/golang/go/issues/21881 

It's been a known issue since 2017 and really needs to be fixed.

On Tuesday, May 14, 2019 at 4:05:55 AM UTC+2, andrey mirtchovski wrote:

file an issue, please, if you have not done so already. i'd like to follow it.

On Mon, May 13, 2019 at 8:01 PM Jason E. Aten <j.e...@gmail.com> wrote:
>
> Indeed, confirming data: I can re-create the crashing circumstances immediately by renaming C:\Go to C:\Go1.12.5.
>
> On Tuesday, May 14, 2019 at 3:53:10 AM UTC+2, Jason E. Aten wrote:
>>
>> Installing the Go build environment locally on the deploy host fixed the crash. I'm guessing it is probably the missing timezone data on Windows, as in
>>
>> https://github.com/golang/go/issues/21881
>>
>> or some other assumption by the runtime inside the DLL that it is running on a machine that has the Go build environment installed.
>>
>> On Saturday, May 11, 2019 at 2:42:40 AM UTC+2, Ian Lance Taylor wrote:
>>>
>>> On Fri, May 10, 2019 at 1:43 PM Jason E. Aten <j.e...@gmail.com> wrote:
>>> >
>>> > I wondering if anyone can shed some light on
>>> >
>>> > a) how I might understand when the Go runtime inside a DLL is supposed to be initialized;
>>>
>>> In c-shared mode the function _rt0_amd64_windows_lib is supposed to be
>>> called when the DLL is initialized.  That function, in
>>> runtime/rt0_windows_amd64.s, should start a new thread that will
>>> initialize the Go runtime.
>>>
>>> The Windows support for c-shared is very new, and perhaps there are
>>> some circumstances in which it does not arrange for
>>> rt0_amd64_windows_lib to be run when the DLL is loaded.  I'm not sure
>>> but I think the code that sets this up is (*peFile).addInitArray in
>>> cmd/link/internal/ld/pe.go.  So make sure that method is being called,
>>> and then make sure it is doing the right thing.
>>>
>>> Ian
>
> --
> You received this message because you are subscribed to the Google Groups "golang-nuts" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to golan...@googlegroups.com.