Re: [go-nuts] go runtime in DLL not getting intialized(?) on some windows hosts
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 > 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 > 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 . > > 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. > -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/8484282d-fdb6-47d7-b439-a66da81edb00%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] go runtime in DLL not getting intialized(?) on some windows hosts
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. On Tuesday, May 14, 2019 at 4:01:26 AM UTC+2, Jason E. Aten 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 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 golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/898ea713-ec1b-43c3-8d1b-c07bdb4e50e8%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] go runtime in DLL not getting intialized(?) on some windows hosts
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 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 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 golang-nuts+unsubscr...@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. -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAK4xykW-3_2%2BZpxgd5OGb_p%3DPESSjSXNPeYPFv11B6uTmPN%2BiQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] go runtime in DLL not getting intialized(?) on some windows hosts
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 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 golang-nuts+unsubscr...@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.
Re: [go-nuts] go runtime in DLL not getting intialized(?) on some windows hosts
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 > 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 golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/17c3ef23-b46a-4550-9337-8e91bd5e6190%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] go runtime in DLL not getting intialized(?) on some windows hosts
On Fri, May 10, 2019 at 1:43 PM Jason E. Aten 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 golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcUtmOBPm8%3DVRncnzDDQmmm3CZAJ9U1wNbePX_%2B5D5d2Vg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
[go-nuts] go runtime in DLL not getting intialized(?) on some windows hosts
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 -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/99bac16d-47f2-4e9f-b2d3-329ff6691379%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
