runtime: nosplit stack overflow when building tests with -N -l #14319
Comments
ianlancetaylor
changed the title
|
It would be nicer if this didn't happen, but I think it's also OK for us to say "don't do that." In particular, as far as I can tell, it doesn't happen with |
|
I'm seeing the same thing using go version 1.6 (final, not rc), on windows/amd64, but not cross-compiling. @ianlancetaylor Is there a workaround to compile with debug symbols (gcflags -N -l) on using 1.6 |
|
Note that you don't need to set -N -l to get debug symbols. Debug symbols are always provided. -N and -l just disable some optimizations. Could you explain more about why you use -N -l and what debugging deficiency you're seeing without them? |
|
Even if you want to use those flags, it ought to work to install the runtime and syscall packages using the default options, and use the flags only for other packages. |
|
Sorry, yes, I said "with debug symbols", but I actually meant "without optimizations". Obviously apart from the failing to compile with the above error, what I see is that when attempting to debug docker or containerd on Windows, that gdb64.exe, both directly or indirectly via LiteIDE simply doesn't trigger on breakpoints, or allow any debugging. I used to have this working, circa go 1.4.3 timeframe, maybe even 1.5.1. Note for the compile error, I might have found a workaround in #12055 But unfortunately, still no breakpoints trigger. |
|
That seems strange. Breakpoints should still work. Maybe if the breakpoint was in an inlined function or something it might not work, but I don't understand how they could be broken everywhere. Can you give us some more instructions to reproduce? |
|
Thanks @randall77. I'm actively trying to track this down. You're right the -N -l is a complete red herring. Apologies for derailing on that. I've tried various versions of golang - 1.5.1, 1.5.3 and 1.6 (currently reverted back to 1.5.1). This is all on Windows. Clone From In liteide, set a breakpoint (F9) on the very first line in
Repeat exactly the same, but this time, include the daemon code conditionally compiled in using
[Hopefully that will work, I've got some wrapper scripts which set up some autogen folders needed to compile, and a few utilities such as rsrc installed, so they may be needed. I'd need to sort out instructions for those probably.] Edit: Oops, wrong screenshot for second one. I did set exactly the same breakpoint, on the very first line executed. |
|
@randall77 Breakpoints haven't worked reliably since go1.2.3 when Ian specifically repaired them from 1.2.2. This has long been pretty trivial to reproduce by firing up gdb and setting some breakpoints, half of them generally will be missed. (go1.2.3 was the last release where they did work reliably). |
|
(Moreover because gdb lies to you about variable values as well, c.f. #6913, I've just gone completely over to printf debugging these days.) |
|
@jhowardmsft I tried following your build instructions, but no luck: What am I doing wrong? Thank you. Alex |
|
Hi Alex - thanks for trying. The first issue here seems to be your GOPATH. It should be set to c:\go\src\github.com\docker\docker\vendor;c:\go. But I suspect then you'll hit either an 'autogen' or 'rsrc' issue. Probably autogen. Can you set your GOPATH as above and it should hopefully be fairly straightforward to get to the next step. But it will need you to run a bash script to generate the autogen folder and contents, so will require GitHub for Windows (2.7.x) installed (for msys2) with sh in your path. From c:\go\src\github.com\docker\docker (only two dockers), run this script, saved as autogen.sh by Hopefully then the Sorry the instructions for building docker on Windows are so complex :( |
|
I should have added, another way to build is from c:\go\src\github.com\docker\docker, run |
|
Got little further, but still no cigar: Alex |
|
Hi Alex - that's that last piece above. Go install -v github.com/akavel/rsrc to build rsrc.exe. That then needs to be in your path. Thanks |
|
@jhowardmsft I can build the exe now, thank you. I can reproduce your problem with gdb. I am pretty sure it is dup of #10776.
But We used to link all windows executables ourselves, but we had many unresolved issues with cgo. So starting from go1.5 we started to use external linker (gcc) to build cgo binaries. We have made everything work except dwarf generation (see #10776). You can still use internal linker as in go1.4, but it is not default now. So you would have to say explicitly: but, like I said before, there are some know issue with our internal linker. I hope it helps. Alex PS: @glycerine sorry for hijacking your issue. |
|
@alexbrainman Thank you so much for your help! Yes, I can confirm add |
mdempsky
changed the title
|
Issue doesn't seem related to cross compiling (I'm able to repro it natively on linux/amd64), or specific to linux/amd64 (I'm able to repro it cross-building for darwin/amd64 and darwin/386 too). |
quentinmit
added
the
NeedsInvestigation
|
The problem here is that I'm not sure what the right answer is here, but this seems more like a cmd/go problem to me than a runtime problem. Possibly |
|
In general, go test must rebuild the package P even if
all the tests are in package P_test because it's possible
to extend or even significantly alter the package P with
test only package P source files (think. export_test.go).
Perhaps the correct solution is to make cmd/go override
const StackGuardMultiplier in runtime/internal/sys when
it's rebuilding runtime/internal/sys with -N -l (i.e. we can
make the const always generated by the build program
[either cmd/dist or cmd/go] at build time.) And arguably
that's what is the intended meaning of the constant.
Alternatively, I'm also wondering if we could introduce
a no_optimize build tag for this. But I can't think of any
other use of it.
|
|
Add |
Yes, you're right. I'd forgotten that the runtime does this. Since There's also the question of what should happen if you mix packages compiled with and without |
|
It turns out this was fixed in 1.9. I believe f8b0231 fixed it by ignoring |
natively OSX go1.6rc2 darwin amd64
but trying to cross compile to GOOS=linux GOARCH=amd64
I've never seen this; not sure how serious it is.
The text was updated successfully, but these errors were encountered: