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

runtime: fatal error: winmm.dll not found on windows-amd64-2016 during bootstrapping #56745

Open
bcmills opened this issue Nov 15, 2022 · 6 comments
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. OS-Windows WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided.
Milestone

Comments

@bcmills
Copy link
Member

bcmills commented Nov 15, 2022

From a TryBot on https://go.dev/cl/450713:

windows-amd64-2016 at 4af48c17a244c5fe21c9758ed84da0fb50b10510

…

Building Go cmd/dist using C:\workdir\go1.4. (go1.17.13 windows/amd64)
Building Go toolchain1 using C:\workdir\go1.4.
Building Go bootstrap cmd/go (go_bootstrap) using Go toolchain1.
Building Go toolchain2 using go_bootstrap and Go toolchain1.
go build io/fs: # io/fs
fatal error: winmm.dll not found
runtime: panic before malloc heap initialized

runtime stack:
runtime.throw({0x130a7da, 0x13})
	C:/workdir/go/src/runtime/panic.go:1198 +0x7b fp=0xbf6fffb58 sp=0xbf6fffb28 pc=0xa901bb
runtime.loadOptionalSyscalls()
	C:/workdir/go/src/runtime/os_windows.go:284 +0x85e fp=0xbf6fffcc0 sp=0xbf6fffb58 pc=0xa8985e
runtime.osinit()
	C:/workdir/go/src/runtime/os_windows.go:550 +0x65 fp=0xbf6fffd20 sp=0xbf6fffcc0 pc=0xa8a045
runtime.rt0_go()
	C:/workdir/go/src/runtime/asm_amd64.s:211 +0x138 fp=0xbf6fffd28 sp=0xbf6fffd20 pc=0xac4eb8
go build internal/poll: # internal/poll
<unknown line number>: internal compiler error: panic: runtime error: invalid memory address or nil pointer dereference

(CC @golang/runtime, @golang/windows)

@bcmills bcmills added OS-Windows NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. compiler/runtime Issues related to the Go compiler and/or runtime. labels Nov 15, 2022
@bcmills bcmills added this to the Backlog milestone Nov 15, 2022
@alexbrainman
Copy link
Member

alexbrainman commented Nov 16, 2022

Just FYI. timeBeginPeriod and timeEndPeriod functions are used from winmm.dll. We cannot continue without them.

Alex

@qmuntal
Copy link
Contributor

qmuntal commented Nov 16, 2022

Just FYI. timeBeginPeriod and timeEndPeriod functions are used from winmm.dll. We cannot continue without them.

Alex

To be puritan, these functions are only used if Windows does not support high resolution timers, which were introduced in Windows 10, version 1803. We could relax this failure mode so it only triggers on older Windows versions.

Having said this, I have no clue why winmm.dll could not be loaded.

@bcmills
Copy link
Member Author

bcmills commented Nov 16, 2022

Yeah, I'm not so concerned about whether failing to load the DLL should be a fatal error — it shouldn't have failed to load in the first place, in which case it doesn't matter whether that failure happens to be fatal. 😅

@mknyszek
Copy link
Contributor

mknyszek commented Nov 16, 2022

Is this a pattern of failures or has it just been one so far? I guess it's also possible this is a build infra issue... I don't know.

@mknyszek mknyszek added the WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. label Nov 16, 2022
@bcmills
Copy link
Member Author

bcmills commented Nov 16, 2022

I only know of the one so far, although I think it's been a while since the last watchflakes run...

@alexbrainman
Copy link
Member

alexbrainman commented Nov 21, 2022

To be puritan, these functions are only used if Windows does not support high resolution timers, ...

Please ignore my message. I was talking to myself. :-)

Having said this, I have no clue why winmm.dll could not be loaded.

Maybe it is possible to add call to print() which calls getlasterror() before this line

throw("winmm.dll not found")

and that might give us some clues.

Perhaps it is good idea to do the same at every windowsLoadSystemLib call site.

Alex

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. OS-Windows WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided.
Projects
Status: No status
Development

No branches or pull requests

4 participants