FAQ
Change 5da9c8cd0a04 broke the windows-amd64 build:
http://build.golang.org/log/afcaaef70e7f9e80dfb56cd7f7f97dff3971e9c1

runtime: ignore SIGPROF to foreign threads before cgocallback is fully
initialized

Some libraries, for example, OpenBLAS, create work threads in a global
constructor.
If we're doing cpu profiling, it's possible that SIGPROF might come to some
of the
worker threads before we make our first cgo call. Cgocallback used to
terminate the
process when that happens, but it's better to miss a couple profiling
signals than
to abort in this case.

Fixes #9456.

Change-Id: I112b8e1a6e10e6cc8ac695a4b518c0f5

http://code.google.com/p/go/source/detail?r=5da9c8cd0a04

$ tail -200 < log
##### Building C bootstrap tool.
cmd/dist

##### Building compilers and Go bootstrap tool.
c:\gobuilder\windows-amd64-5da9c8cd0a04\go\src\runtime\sigqueue.go:163:
undefined: _SIGPROF
lib9
libbio
liblink
cmd/gc
cmd/6l
cmd/6a
cmd/6g
runtime
go tool dist: FAILED:
c:\gobuilder\windows-amd64-5da9c8cd0a04\go\pkg\tool\windows_amd64\6g -pack
-o C:\Users\WINGOP~1\AppData\Local\Temp\2\goCEE5.tmp\_go_.a -p runtime -+
-asmhdr C:\Users\WINGOP~1\AppData\Local\Temp\2\goCEE5.tmp\go_asm.h
c:\gobuilder\windows-amd64-5da9c8cd0a04\go\src\runtime\alg.go
c:\gobuilder\windows-amd64-5da9c8cd0a04\go\src\runtime\arch1_amd64.go
c:\gobuilder\windows-amd64-5da9c8cd0a04\go\src\runtime\arch_amd64.go
c:\gobuilder\windows-amd64-5da9c8cd0a04\go\src\runtime\atomic_amd64x.go
c:\gobuilder\windows-amd64-5da9c8cd0a04\go\src\runtime\cgo.go
c:\gobuilder\windows-amd64-5da9c8cd0a04\go\src\runtime\cgocall.go
c:\gobuilder\windows-amd64-5da9c8cd0a04\go\src\runtime\cgocallback.go
c:\gobuilder\windows-amd64-5da9c8cd0a04\go\src\runtime\chan.go
c:\gobuilder\windows-amd64-5da9c8cd0a04\go\src\runtime\chan1.go
c:\gobuilder\windows-amd64-5da9c8cd0a04\go\src\runtime\compiler.go
c:\gobuilder\windows-amd64-5da9c8cd0a04\go\src\runtime\complex.go
c:\gobuilder\windows-amd64-5da9c8cd0a04\go\src\runtime\cpuprof.go c:\
Build complete, duration 20.4138698s. Result: error: exit status 1

--
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

  • Minux at Dec 31, 2014 at 11:13 pm
    I'm on it.

    --
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Minux at Dec 31, 2014 at 11:54 pm
    the new test is broken on the following systems:
    1. windows/plan9: those two don't have _SIGPROF, I will add a a dummy
    definition and a switch GOOS to sigqueue.go
    2. openbsd: it got empty string from the test program, I don't understand
    how that's possible
    3. darwin 10.6: somehow the test program doesn't stop, it might be a
    genuine cgo problem there.

    I will install a VM to test for openbsd, but I don't have OS X 10.6 VM to
    figure out how to fix the problem
    on that. I'd appreciate if someone with access to 10.6 could take a look.
    Thanks.

    --
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Minux at Jan 1, 2015 at 1:17 am

    On Wed, Dec 31, 2014 at 6:53 PM, minux wrote:

    the new test is broken on the following systems:
    1. windows/plan9: those two don't have _SIGPROF, I will add a a dummy
    definition and a switch GOOS to sigqueue.go
    2. openbsd: it got empty string from the test program, I don't understand
    how that's possible
    I should have realized that this is because our runtime/cgo provides an
    alternative pthread_create function,
    but the pointer to original pthread_create is not initialized until
    x_cgo_init.

    I think this is a bug in our runtime/cgo, so I will fix that instead.
    we need to use pthread_once to initialize the pointer to the original
    pthread_create function
    in pthread_create itself.

    3. darwin 10.6: somehow the test program doesn't stop, it might be a
    genuine cgo problem there.

    I will install a VM to test for openbsd, but I don't have OS X 10.6 VM to
    figure out how to fix the problem
    on that. I'd appreciate if someone with access to 10.6 could take a look.
    Thanks.
    --
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-dev @
categoriesgo
postedDec 31, '14 at 11:11p
activeJan 1, '15 at 1:17a
posts4
users2
websitegolang.org

2 users in discussion

Minux: 3 posts Builder: 1 post

People

Translate

site design / logo © 2021 Grokbase