go: debug/pe: TestDefaultLinkerDWARF and TestExternalLinkerDWARF fail on windows/arm64 builder

Spotted on the new windows-arm64-aws builder on a recent Go tip commit a62c08734f8e2fc5333036e3a069a55288d1f674:

--- FAIL: TestDefaultLinkerDWARF (4.77s)
    file_test.go:395: Testprog output:
        base=0x7ff786f40000
        main=0x7ff786fd6890
        offset=0x96890
    file_test.go:426: decoding dwarf section info at offset 0x13b1: underflow
--- FAIL: TestExternalLinkerDWARF (7.73s)
    file_test.go:395: Testprog output:
        base=0x7ff6aa9b0000
        main=0x7ff6aaa46890
        offset=0x96890
    file_test.go:426: decoding dwarf section info at offset 0x13b1: underflow
FAIL
FAIL	debug/pe	15.328s

(Source.)

That builder has an open known issue (#42604) so there’s a possibility of problem with the builder, but the test failure looks like it may be a problem in debug/pe on windows/arm64 specifically. It may be relevant that testing of internal linking on windows/arm64 was intentionally skipped in CL 312045 (CC @rsc).

CC @alexbrainman via owners. Also CC @rsc and @golang/release.

About this issue

Original URL
State: closed
Created 3 years ago
Comments: 25 (19 by maintainers)

Commits related to this issue

cmd/link: use correct alignment in PE DWARF sections Set the correct section flags to insure that .debug_* sections are using 1-byte alignment instead of the default. This seems to be important for l... — committed to golang/go by thanm 3 years ago
cmd/release: start running release tests for windows-arm64 By now, all outstanding issues preventing release tests for windows-arm64 from being turned on by default are resolved: - Issues golang/go#... — committed to golang/build by dmitshur 3 years ago

Most upvoted comments

I’ve submitted https://golang.org/cl/324763 and manually verified that the test runs correctly on the windows-arm64-aws builder. @dmitshur , ok to close this issue?

thanm on Jun 3, 2021

I have awakened my Surface Pro X from its slumber, but despite valiant efforts I have not succeeded in convincing it that today is not April 26, 2021. It insists that all the other computers on the internet serving certificates from the future must be the ones who are insecurely configured. After a reboot, even less works on the machine, not even trying to use the start menu and certainly not the “Adjust date/time” menu entry. I assume it is doing background network connections all of which are failing during TLS. Perhaps if I let it sit here for a few hours it will reconsider. A remarkably secure operating system.

rsc on Jun 2, 2021

file_test.go:426: decoding dwarf section info at offset 0x13b1: underflow

It appears the problem here is decoding Dwarf section. I am not familiar with the code that decodes Dwarf.

I also don’t have windows-arm64 hardware so I cannot even try to reproduce it here.

I also don’t use windows-arm64 myself. Perhaps @zx2c4 will be interested investigating this.

It may be relevant that testing of internal linking on windows/arm64 was intentionally skipped in CL 312045 (CC @rsc).

This test uses external linker, not internal linker. And Windows does not come with C compiler and linker installed. So whatever C tools you installed on that builder could be relevant to this bug.

I hope it helps.

Alex

alexbrainman on May 27, 2021