Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/link: unexpected fault address (when low on disk space?) #37310

Open
bradfitz opened this issue Feb 20, 2020 · 18 comments
Open

cmd/link: unexpected fault address (when low on disk space?) #37310

bradfitz opened this issue Feb 20, 2020 · 18 comments

Comments

@bradfitz
Copy link
Contributor

@bradfitz bradfitz commented Feb 20, 2020

I just got some mysterious linker errors. I suspect they're because this machine only has 20MB of disk free (which I just noticed).

# tailscale.io/control/cfgdb.test
unexpected fault address 0x7f24b561d000
fatal error: fault
[signal SIGBUS: bus error code=0x2 addr=0x7f24b561d000 pc=0x463c2e]

goroutine 1 [running]:
runtime.throw(0x6b7228, 0x5)
        /home/bradfitz/go/src/runtime/panic.go:1112 +0x72 fp=0xc003df2ee8 sp=0xc003df2eb8 pc=0x432f62
runtime.sigpanic()
        /home/bradfitz/go/src/runtime/signal_unix.go:674 +0x443 fp=0xc003df2f18 sp=0xc003df2ee8 pc=0x449533
runtime.memmove(0x7f24b561b6b0, 0x7f24b6c77c85, 0x22df)
        /home/bradfitz/go/src/runtime/memmove_amd64.s:108 +0xbe fp=0xc003df2f20 sp=0xc003df2f18 pc=0x463c2e
cmd/link/internal/ld.(*OutBuf).Write(0xc000024900, 0x7f24b6c77c85, 0x22df, 0x22df, 0x1, 0x1, 0x0)
        /home/bradfitz/go/src/cmd/link/internal/ld/outbuf.go:65 +0xa1 fp=0xc003df2f70 sp=0xc003df2f20 pc=0x5c83a1
cmd/link/internal/ld.(*OutBuf).WriteSym(0xc000024900, 0xc002807a90)
        /home/bradfitz/go/src/cmd/link/internal/ld/outbuf.go:159 +0x6c fp=0xc003df2fc0 sp=0xc003df2f70 pc=0x5c8b7c
cmd/link/internal/ld.blk(0xc000024900, 0xc004dd0000, 0x18d8, 0x1c00, 0x5ca6b0, 0x31299c, 0xc0063c4b00, 0x1, 0x1)
        /home/bradfitz/go/src/cmd/link/internal/ld/data.go:787 +0x10f fp=0xc003df3090 sp=0xc003df2fc0 pc=0x570d1f
cmd/link/internal/ld.CodeblkPad(0xc000001e00, 0x401000, 0x31299c, 0xc0063c4b00, 0x1, 0x1)
        /home/bradfitz/go/src/cmd/link/internal/ld/data.go:701 +0xbb fp=0xc003df31a0 sp=0xc003df3090 pc=0x5703fb
cmd/link/internal/amd64.asmb(0xc000001e00)
        /home/bradfitz/go/src/cmd/link/internal/amd64/asm.go:669 +0xc6 fp=0xc003df3200 sp=0xc003df31a0 pc=0x5ec9f6
cmd/link/internal/ld.Main(0x899300, 0x10, 0x20, 0x1, 0x7, 0x10, 0x6c25b5, 0x1b, 0x6be64d, 0x14, ...)
        /home/bradfitz/go/src/cmd/link/internal/ld/main.go:269 +0xd61 fp=0xc003df3358 sp=0xc003df3200 pc=0x5c7451
main.main()
        /home/bradfitz/go/src/cmd/link/main.go:68 +0x1bc fp=0xc003df3f88 sp=0xc003df3358 pc=0x63d2bc
runtime.main()
        /home/bradfitz/go/src/runtime/proc.go:203 +0x212 fp=0xc003df3fe0 sp=0xc003df3f88 pc=0x4355b2
runtime.goexit()
        /home/bradfitz/go/src/runtime/asm_amd64.s:1375 +0x1 fp=0xc003df3fe8 sp=0xc003df3fe0 pc=0x4629c1
FAIL    tailscale.io/control/cfgdb [build failed]
FAIL

And another, which looks like the same:

goroutine 1 [running]:
runtime.throw(0x6b7228, 0x5)
        /home/bradfitz/go/src/runtime/panic.go:1112 +0x72 fp=0xc00004eee8 sp=0xc00004eeb8 pc=0x432f62
runtime.sigpanic()
        /home/bradfitz/go/src/runtime/signal_unix.go:674 +0x443 fp=0xc00004ef18 sp=0xc00004eee8 pc=0x449533
runtime.memmove(0x7f29fc0a5000, 0x7f29fc6447ce, 0x4b)
        /home/bradfitz/go/src/runtime/memmove_amd64.s:205 +0x1b2 fp=0xc00004ef20 sp=0xc00004ef18 pc=0x463d22
cmd/link/internal/ld.(*OutBuf).Write(0xc000024900, 0x7f29fc6447ce, 0x4b, 0x4b, 0x7f2a23f586e0, 0x3f, 0xb)
        /home/bradfitz/go/src/cmd/link/internal/ld/outbuf.go:65 +0xa1 fp=0xc00004ef70 sp=0xc00004ef20 pc=0x5c83a1
cmd/link/internal/ld.(*OutBuf).WriteSym(0xc000024900, 0xc000a5d5f0)
        /home/bradfitz/go/src/cmd/link/internal/ld/outbuf.go:159 +0x6c fp=0xc00004efc0 sp=0xc00004ef70 pc=0x5c8b7c
cmd/link/internal/ld.blk(0xc000024900, 0xc0022e8000, 0xa80, 0xc00, 0x401000, 0x102b7c, 0xc000b93280, 0x1, 0x1)
        /home/bradfitz/go/src/cmd/link/internal/ld/data.go:787 +0x10f fp=0xc00004f090 sp=0xc00004efc0 pc=0x570d1f
cmd/link/internal/ld.CodeblkPad(0xc000001e00, 0x401000, 0x102b7c, 0xc000b93280, 0x1, 0x1)
        /home/bradfitz/go/src/cmd/link/internal/ld/data.go:701 +0xbb fp=0xc00004f1a0 sp=0xc00004f090 pc=0x5703fb
cmd/link/internal/amd64.asmb(0xc000001e00)
        /home/bradfitz/go/src/cmd/link/internal/amd64/asm.go:669 +0xc6 fp=0xc00004f200 sp=0xc00004f1a0 pc=0x5ec9f6
cmd/link/internal/ld.Main(0x899300, 0x10, 0x20, 0x1, 0x7, 0x10, 0x6c25b5, 0x1b, 0x6be64d, 0x14, ...)
        /home/bradfitz/go/src/cmd/link/internal/ld/main.go:269 +0xd61 fp=0xc00004f358 sp=0xc00004f200 pc=0x5c7451
main.main()
        /home/bradfitz/go/src/cmd/link/main.go:68 +0x1bc fp=0xc00004ff88 sp=0xc00004f358 pc=0x63d2bc
runtime.main()
        /home/bradfitz/go/src/runtime/proc.go:203 +0x212 fp=0xc00004ffe0 sp=0xc00004ff88 pc=0x4355b2
runtime.goexit()
        /home/bradfitz/go/src/runtime/asm_amd64.s:1375 +0x1 fp=0xc00004ffe8 sp=0xc00004ffe0 pc=0x4629c1
FAIL    tailscale.com/logtail/filch [build failed]
FAIL
@cherrymui
Copy link
Contributor

@cherrymui cherrymui commented Feb 20, 2020

Yeah, this is writing to mmap'd memory backed by the output file. SIGBUS may occur if write to mmap'd memory fails (maybe cannot flush to disk?).

It would be good if we can fail nicely. But I don't know how. Maybe write (using file IO) to the last byte of the output file before mmap? If that write fails we can exit with a nice error. Does it work? cc @aclements

Loading

@toothrot toothrot added this to the Backlog milestone Feb 20, 2020
@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Feb 21, 2020

I haven't looked at the code, but if we're going to mmap the output file, we should fallocate it first. Otherwise, it's possible for the program to exit after writing all blocks to the memory mapped area, calling munmap and close, but before disk blocks have been assigned. In that case the generated executable may be incomplete, which is bad. Or, of course, we can get a SIGBUS during execution which is less bad but still bad. The fix is to either fallocate or fdatasync, and fallocate is faster.

Loading

@gopherbot
Copy link

@gopherbot gopherbot commented Apr 16, 2020

Change https://golang.org/cl/228385 mentions this issue: [dev.link] cmd/link: fallocate space, and remove all msync calls

Loading

@nightlyone
Copy link
Contributor

@nightlyone nightlyone commented Apr 17, 2020

What is the story for platforms that don't support fallocate? Should there be pre-zeroing or something else?

Loading

@aclements
Copy link
Member

@aclements aclements commented Apr 17, 2020

We definitely considered pre-zeroing, but it adds 50–100% to the IO cost, and considering we've had one report of this in 10 years, it doesn't seem worth significantly slowing down every link for such a rare case. fallocate is obviously the right thing to do when it's available, but when it isn't, there isn't an obviously right answer. (It would be nice if the runtime gave us a good way to handle SIGBUS, like recognizing that it's in an mmaped region and turning it into a useful panic; that may be worth doing, but it's also a non-trivial project.)

For reference, here are the benchmark numbers for allocating a 100 MiB file on three different machines using different techniques (source by @jeremyfaller and myself):

Linux ext4, SSD, laptop:
name         time/op
Msync         105ms ±12%
Fallocate    52.6ms ± 2%
WriteBlocks  78.4ms ± 2%
NoSync       55.0ms ± 2%

Linux ext4, 7200 RPM HDD, workstation:
name         time/op
Msync         730ms ± 8%
Fallocate    74.1ms ± 1%
WriteBlocks   114ms ± 1%
NoSync       76.0ms ± 1%

macOS laptop:
name         time/op
Msync         141ms ±19%
Fallocate    93.4ms ±13%
WriteBlocks   193ms ± 4%
NoSync       88.9ms ±10%

Loading

@aclements
Copy link
Member

@aclements aclements commented Apr 17, 2020

considering we've had one report of this in 10 years

Actually, this is somewhat unfair since the linker didn't use mmap until a couple years ago. I don't believe we've had reports from other uses of mmap, but I don't know how commonly used it is.

It would be nice if the runtime gave us a good way to handle SIGBUS

Also EXCEPTION_IN_PAGE_ERROR on Windows.

Loading

@bradfitz
Copy link
Contributor Author

@bradfitz bradfitz commented Apr 17, 2020

If we don't fail nicely when out of disk I fear we'll get lots of bogus issues filed.

Perhaps cmd/go can check disk space if (and only if) cmd/link returns a failed exit status.

Loading

@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Apr 17, 2020

When the linker uses fallocate it should fail nicely when out of disk space.

fallocate is part of POSIX (as posix_fallocate) so it is generally available. On Windows perhaps it will be necessary to write out zeroes, I don't know.

Loading

gopherbot pushed a commit that referenced this issue Apr 20, 2020
The fallocate calls will lower the chances of SIGBUS in the linker, but
it might still happen on other unsupported platforms and filesystems.

Darwin cmd/compile stats:

Munmap                    16.0ms ± 8%     0.8ms ± 3%   -95.19%  (p=0.000 n=8+10)
TotalTime                  484ms ± 2%     462ms ± 2%    -4.52%  (p=0.000 n=10+9)

Updates #37310

Change-Id: I41c6e490adec26fa1ebee49a5b268828f5ba05e1
Reviewed-on: https://go-review.googlesource.com/c/go/+/228385
Run-TryBot: Jeremy Faller <jeremy@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
@aclements
Copy link
Member

@aclements aclements commented Apr 20, 2020

At least in glibc, posix_fallocate falls back to an implementation that just writes the blocks. Beyond Linux and macOS, I'm not sure what platforms natively support it, though I'm sure some of them do.

On Windows, as far as I can tell, there's no equivalent of fallocate and you're expected to catch EXCEPTION_IN_PAGE_ERROR: "To guard against exceptions due to input and output (I/O) errors, all attempts to access memory mapped files should be wrapped in structured exception handlers."

Loading

xujianhai666 added a commit to xujianhai666/go-1 that referenced this issue May 21, 2020
The fallocate calls will lower the chances of SIGBUS in the linker, but
it might still happen on other unsupported platforms and filesystems.

Darwin cmd/compile stats:

Munmap                    16.0ms ± 8%     0.8ms ± 3%   -95.19%  (p=0.000 n=8+10)
TotalTime                  484ms ± 2%     462ms ± 2%    -4.52%  (p=0.000 n=10+9)

Updates golang#37310

Change-Id: I41c6e490adec26fa1ebee49a5b268828f5ba05e1
Reviewed-on: https://go-review.googlesource.com/c/go/+/228385
Run-TryBot: Jeremy Faller <jeremy@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
@cherrymui
Copy link
Contributor

@cherrymui cherrymui commented Jun 10, 2020

@jeremyfaller @aclements is this fixed by CL https://go-review.googlesource.com/c/go/+/228385 , or there is still things to be done for this? I guess we don't close this as currently we only pre-allocate on some platforms, not all?

Loading

@cherrymui
Copy link
Contributor

@cherrymui cherrymui commented Sep 18, 2020

As @rsc pointed at #41466 (comment) , on OSes that we don't preallocate, we could use SetPanicOnFault to make it fail gracefully, if we do #41155 .

Loading

@jeremyfaller
Copy link
Contributor

@jeremyfaller jeremyfaller commented Sep 18, 2020

Sorry, missed this discussion.

I believe we are fixed as well as we can be without prezeroing. The OSs that don't support fallocate -- we currently do a best effort, but could still SIGBUS. I like the solution to SetPanicOnFault as it's a better experience than dying with a terrible error message.

Loading

@cherrymui
Copy link
Contributor

@cherrymui cherrymui commented Sep 18, 2020

Just to be clear, we didn't use SetPanicOnFault because it doesn't catch SIGBUS, only SIGSEGV. But now there is ongoing discussion on #41155 . If we do that, I think we want to revisit SetPanicOnFault.

Loading

@rsc
Copy link
Contributor

@rsc rsc commented Sep 18, 2020

I don't see any dissents on #41155 and it's marked NeedsFix already, so I won't comment there, but replying to the "if we do #41155" above:

I added SetPanicOnFault for exactly this specific use case, during an earlier, aborted rewrite of the linker. If an mmap fault is producing SIGBUS then that signal should be included, no question.

Loading

@vkuznet
Copy link

@vkuznet vkuznet commented Jun 23, 2021

I doubt it is related to disk space, I encounter this issue from rather non-trivial environment. We need to build RPMs, and quite often we build Go code from rpm spec files. Originally, I thought the issue was related to AFS file system we use, then I adjusted spec to use /tmp area, and regardless of my attempts I always get this issue when I run rpm build, but I have no issue when I compile code from a local file system. The issue appears either at go build or at go mod and stack trace suggest some race conditions with goroutines involved in a build. Here is what I see (from rpm build log, the plus sign indicates the command executed):

+ mkdir -p /tmp/k8s_info
+ rm -rf /tmp/k8s_info
+ mkdir -p /tmp/k8s_info/cache
+ export GOCACHE=/tmp/k8s_info/cache
+ GOCACHE=/tmp/k8s_info/cache
+ cd /tmp/k8s_info
+ cp /afs/cern.ch/work/v/valya/builds/w820/SOURCES/cms/cmsmon-tools/0.5.35/k8s_info.go .
+ go mod init github.com/vkuznet/k8s_info
go: creating new go.mod: module github.com/vkuznet/k8s_info
go: to add module requirements and sums:
        go mod tidy
+ go mod tidy
fatal error: unexpected signal during runtime execution
[signal SIGBUS: bus error code=0x2 addr=0xbbebab pc=0x457481]

runtime stack:
runtime.throw(0xa61e2a, 0x2a)
        /usr/local/go/src/runtime/panic.go:1117 +0x72
runtime.sigpanic()
        /usr/local/go/src/runtime/signal_unix.go:718 +0x2e5
runtime.step(0xbbebab, 0xebb55, 0xebb55, 0x7f16377fd718, 0x7f16377fd70c, 0xbbc201, 0x0, 0x46dd60, 0x7f16377fd740, 0x7f16377fd734)
        /usr/local/go/src/runtime/symtab.go:975 +0x21
runtime.pcvalue(0xce8828, 0xd947a0, 0x2366b, 0x476f6a, 0x7f16377fd910, 0x1, 0xd947a0, 0x4339d2)
        /usr/local/go/src/runtime/symtab.go:779 +0x165
runtime.funcspdelta(0xce8828, 0xd947a0, 0x476f6a, 0x7f16377fd910, 0x0)
        /usr/local/go/src/runtime/symtab.go:902 +0x65
runtime.gentraceback(0xffffffffffffffff, 0xffffffffffffffff, 0x0, 0xc000102c00, 0x0, 0x0, 0x7fffffff, 0xa914c0, 0x7f16377fdb98, 0x0, ...)
        /usr/local/go/src/runtime/traceback.go:208 +0x15fd
runtime.copystack(0xc000102c00, 0x1000)
        /usr/local/go/src/runtime/stack.go:908 +0x2f1
runtime.shrinkstack(0xc000102c00)
        /usr/local/go/src/runtime/stack.go:1180 +0x13d
runtime.newstack()
        /usr/local/go/src/runtime/stack.go:1037 +0x30b
runtime.morestack()
        /usr/local/go/src/runtime/asm_amd64.s:458 +0x8f

goroutine 29 [running]:
sync.(*Map).Load(0xc0001da090, 0x996aa0, 0xc000119b90, 0x0, 0xc000335db0, 0x40cd7b)
        /usr/local/go/src/sync/map.go:102 +0x30a fp=0xc000205d60 sp=0xc000205d58 pc=0x476f6a
cmd/go/internal/par.(*Cache).Do(0xc0001da090, 0x996aa0, 0xc000119b90, 0xc000335df8, 0xc000280000, 0x0)
        /usr/local/go/src/cmd/go/internal/par/work.go:120 +0x45 fp=0xc000205dc0 sp=0xc000205d60 pc=0x773e65
cmd/go/internal/modload.(*loader).pkg(0xc000158180, 0xc0003aa8c9, 0x6, 0xc0003aa800, 0x6)
        /usr/local/go/src/cmd/go/internal/modload/load.go:962 +0xc8 fp=0xc000205e30 sp=0xc000205dc0 pc=0x836ca8
cmd/go/internal/modload.(*loader).load(0xc000158180, 0xc0003a04d0)
        /usr/local/go/src/cmd/go/internal/modload/load.go:1112 +0x3de fp=0xc000205f40 sp=0xc000205e30 pc=0x83747e
cmd/go/internal/modload.(*loader).pkg.func1.1()
        /usr/local/go/src/cmd/go/internal/modload/load.go:968 +0x33 fp=0xc000205f60 sp=0xc000205f40 pc=0x849e93
cmd/go/internal/par.(*Queue).Add.func1(0xc0001380e0, 0xc000119440)
        /usr/local/go/src/cmd/go/internal/par/queue.go:58 +0x7c fp=0xc000205fd0 sp=0xc000205f60 pc=0x7742bc
runtime.goexit()
        /usr/local/go/src/runtime/asm_amd64.s:1371 +0x1 fp=0xc000205fd8 sp=0xc000205fd0 pc=0x46dd61
created by cmd/go/internal/par.(*Queue).Add
        /usr/local/go/src/cmd/go/internal/par/queue.go:56 +0x23d

goroutine 1 [chan receive]:
cmd/go/internal/modload.loadFromRoots(0xc0001a7da0, 0x1, 0x0, 0x1, 0x100, 0xc0001301c8, 0x0)
        /usr/local/go/src/cmd/go/internal/modload/load.go:831 +0x328
cmd/go/internal/modload.LoadPackages(0xb1de88, 0xc000124000, 0xc0001a7da0, 0x1, 0x0, 0x1, 0xc000119430, 0x1, 0x1, 0xa35980
, ...)
        /usr/local/go/src/cmd/go/internal/modload/load.go:261 +0x398
cmd/go/internal/modcmd.runTidy(0xb1de88, 0xc000124000, 0xdc8700, 0xc00011e170, 0x0, 0x0)
        /usr/local/go/src/cmd/go/internal/modcmd/tidy.go:64 +0x113
main.main()
        /usr/local/go/src/cmd/go/main.go:195 +0x70c

goroutine 30 [semacquire]:
fatal error: unexpected signal during runtime execution
panic during panic
[signal SIGBUS: bus error code=0x2 addr=0xad51d4 pc=0x45c4cb]

runtime stack:
runtime.throw(0xa61e2a, 0x2a)
        /usr/local/go/src/runtime/panic.go:1117 +0x72
runtime.sigpanic()
        /usr/local/go/src/runtime/signal_unix.go:718 +0x2e5
runtime.gentraceback(0xffffffffffffffff, 0xffffffffffffffff, 0x0, 0xc000103680, 0x0, 0x0, 0x64, 0x0, 0x0, 0x0, ...)
        /usr/local/go/src/runtime/traceback.go:409 +0xbeb
runtime.traceback1(0xffffffffffffffff, 0xffffffffffffffff, 0x0, 0xc000103680, 0x0)
        /usr/local/go/src/runtime/traceback.go:732 +0xf2
runtime.traceback(...)
        /usr/local/go/src/runtime/traceback.go:686
runtime.tracebackothers(0xc000282180)
        /usr/local/go/src/runtime/traceback.go:951 +0x148
runtime.dopanic_m(0xc000282180, 0x437cd2, 0x7f16377fd630, 0x1)
        /usr/local/go/src/runtime/panic.go:1317 +0x2a8
runtime.fatalthrow.func1()
        /usr/local/go/src/runtime/panic.go:1172 +0x5f
runtime.fatalthrow()
        /usr/local/go/src/runtime/panic.go:1169 +0x57
runtime.throw(0xa61e2a, 0x2a)
        /usr/local/go/src/runtime/panic.go:1117 +0x72
runtime.sigpanic()
        /usr/local/go/src/runtime/signal_unix.go:718 +0x2e5
runtime.step(0xbbebab, 0xebb55, 0xebb55, 0x7f16377fd718, 0x7f16377fd70c, 0xbbc201, 0x0, 0x46dd60, 0x7f16377fd740, 0x7f1637
7fd734)
        /usr/local/go/src/runtime/symtab.go:975 +0x21
runtime.pcvalue(0xce8828, 0xd947a0, 0x2366b, 0x476f6a, 0x7f16377fd910, 0x1, 0xd947a0, 0x4339d2)
        /usr/local/go/src/runtime/symtab.go:779 +0x165
runtime.funcspdelta(0xce8828, 0xd947a0, 0x476f6a, 0x7f16377fd910, 0x0)
        /usr/local/go/src/runtime/symtab.go:902 +0x65
runtime.gentraceback(0xffffffffffffffff, 0xffffffffffffffff, 0x0, 0xc000102c00, 0x0, 0x0, 0x7fffffff, 0xa914c0, 0x7f16377fdb98, 0x0, ...)
        /usr/local/go/src/runtime/traceback.go:208 +0x15fd
runtime.copystack(0xc000102c00, 0x1000)
        /usr/local/go/src/runtime/stack.go:908 +0x2f1
runtime.shrinkstack(0xc000102c00)
        /usr/local/go/src/runtime/stack.go:1180 +0x13d
runtime.newstack()
        /usr/local/go/src/runtime/stack.go:1037 +0x30b
runtime.morestack()
        /usr/local/go/src/runtime/asm_amd64.s:458 +0x8f
error: Bad exit status from /afs/cern.ch/work/v/valya/builds/w820/tmp/rpm-tmp.eRa5Wz (%install)

The code is very small and does not have any external dependencies. We use go 1.16, and yet I'm seeing the same issue as discussed in this ticket and all possible explanation in this and other tickets seems do not apply here. I build without CGO, I used local cache, I used /tmp area, and yet I still see build fails when it is invoked from RPM build environment, but it is just fine and I do not use RPM build.

Loading

@cherrymui
Copy link
Contributor

@cherrymui cherrymui commented Jun 23, 2021

@vkuznet the original issue is specifically about the faults when disk space is low in the linker. Your issue is different, and it is the go command instead of the linker. You may want to file a separate issue. Thanks.

Loading

@vkuznet
Copy link

@vkuznet vkuznet commented Jun 23, 2021

@cherrymui , as I wrote I tried different approaches, and in fact I can reproduce issue with go build instead of go mod, therefore it is related to linker and possibly another issue(s), that's why I posted here since it seems related to original post, but as I said I doubt it is related to low disk space.

Loading

@cherrymui
Copy link
Contributor

@cherrymui cherrymui commented Jun 23, 2021

From your stack trace it is the cmd/go binary that crashes, not the cmd/link binary. Thanks.

Loading

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
10 participants