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/cgo: fails with gcc 4.4.1 #1

Closed
gopherbot opened this issue Oct 22, 2009 · 12 comments
Closed

cmd/cgo: fails with gcc 4.4.1 #1

gopherbot opened this issue Oct 22, 2009 · 12 comments
Milestone

Comments

@gopherbot
Copy link

by rsc+personal@swtch.com:

What steps will reproduce the problem?
1. Run build on Ubuntu 9.10, which uses gcc 4.4.1

What is the expected output? What do you see instead?

Cgo fails with the following error:

{{{
go/misc/cgo/stdio$ make
cgo  file.go
could not determine kind of name for C.CString
could not determine kind of name for C.puts
could not determine kind of name for C.fflushstdout
could not determine kind of name for C.free
throw: sys·mapaccess1: key not in map

panic PC=0x2b01c2b96a08
throw+0x33 /media/scratch/workspace/go/src/pkg/runtime/runtime.c:71
    throw(0x4d2daf, 0x0)
sys·mapaccess1+0x74 
/media/scratch/workspace/go/src/pkg/runtime/hashmap.c:769
    sys·mapaccess1(0xc2b51930, 0x2b01)
main·*Prog·loadDebugInfo+0xa67 
/media/scratch/workspace/go/src/cmd/cgo/gcc.go:164
    main·*Prog·loadDebugInfo(0xc2bc0000, 0x2b01)
main·main+0x352 
/media/scratch/workspace/go/src/cmd/cgo/main.go:68
    main·main()
mainstart+0xf 
/media/scratch/workspace/go/src/pkg/runtime/amd64/asm.s:55
    mainstart()
goexit /media/scratch/workspace/go/src/pkg/runtime/proc.c:133
    goexit()
make: *** [file.cgo1.go] Error 2
}}}

Please use labels and text to provide additional information.
@agl
Copy link
Contributor

agl commented Oct 29, 2009

Comment 1:

Owner changed to a...@chromium.org.

Status changed to Started.

@agl
Copy link
Contributor

agl commented Nov 2, 2009

Comment 2:

This issue was closed by revision eea14bb9e8.

Status changed to Fixed.

Merged into issue #-.

@rsc
Copy link
Contributor

rsc commented Nov 4, 2009

Comment 3:

This issue was closed by revision 72ec930.

Merged into issue #-.

@gopherbot
Copy link
Author

Comment 4 by solstice.dhiver:

i still have a similar error:
--- cd ../misc/cgo/stdio
rm -rf *.[568vqo] *.a [568vq].out *.cgo[12].go *.cgo[34].c *.so _obj _test 
_testmain.go hello fib chain run.out
cgo  file.go
could not determine kind of name for C.puts
could not determine kind of name for C.CString
could not determine kind of name for C.fflushstdout
could not determine kind of name for C.free
failed to interpret gcc output:
cc1: warnings being treated as errors
cgo-test: In function ‘f’:
cgo-test:0: erreur: déclaration sans effet
cgo-test:1: erreur: déclaration sans effet
cgo-test:2: erreur: déclaration sans effet
cgo-test:3: erreur: déclaration sans effet
make: *** [file.cgo1.go] Erreur 2
using gcc 4.4.2

@gopherbot
Copy link
Author

Comment 5 by solstice.dhiver:

i was given the advice to run export LC_ALL="en_US.UTF-8" before building and it 
works.
so may i fill another bug for that or it's stil the same ?

@rsc
Copy link
Contributor

rsc commented Nov 15, 2009

Comment 6:

Labels changed: removed type-defect, priority-medium.

Owner changed to r...@golang.org.

Status changed to Duplicate.

Merged into issue #21.

crawshaw added a commit that referenced this issue Mar 3, 2015
On one recent job I saw an unexpected SIGSTOP, which I suspect is
simply the job timeout. But the lack of other diagnostics suggests
lldb just didn't see the "run" command.

-----

process handle SIGHUP  --stop false --pass true --notify false
process handle SIGPIPE --stop false --pass true --notify false
process handle SIGUSR1 --stop false --pass true --notify false
process handle SIGSEGV --stop false --pass true --notify false
process handle SIGBUS  --stop false --pass true --notify false
breakpoint set -n getwd
run
(lldb) NAME        PASS   STOP   NOTIFY
==========  =====  =====  ======
SIGHUP      true   false  false
(lldb) NAME        PASS   STOP   NOTIFY
==========  =====  =====  ======
SIGPIPE     true   false  false
(lldb) NAME        PASS   STOP   NOTIFY
==========  =====  =====  ======
SIGUSR1     true   false  false
(lldb) NAME        PASS   STOP   NOTIFY
==========  =====  =====  ======
SIGSEGV     true   false  false
(lldb) NAME        PASS   STOP   NOTIFY
==========  =====  =====  ======
SIGBUS      true   false  false
(lldb) Breakpoint 1: where = libsystem_c.dylib`getwd, address = 0x2f7f7294
(lldb) Process 23755 stopped
* thread #1: tid = 0x104c02, 0x1febb000 dyld`_dyld_start, stop reason = signal SIGSTOP
    frame #0: 0x1febb000 dyld`_dyld_start
dyld`_dyld_start:
-> 0x1febb000:  mov    r8, sp
   0x1febb004:  sub    sp, sp, #0x10
   0x1febb008:  bic    sp, sp, #0x7
   0x1febb00c:  ldr    r3, [pc, #112]            ; _dyld_start + 132
(lldb) go_darwin_arm_exec: timeout (stage br getwd)
FAIL	compress/gzip	359.226s

Change-Id: Ifc2123f5ceaa6d3f9b31bb5cb6e77a2c8ec23818
Reviewed-on: https://go-review.googlesource.com/6613
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
RLH added a commit that referenced this issue Mar 17, 2015
The GC assumes that there will be no asynchronous write barriers when
the world is stopped. This keeps the synchronization between write
barriers and the GC simple. However, currently, there are a few places
in runtime code where this assumption does not hold.
The GC stops the world by collecting all Ps, which stops all user Go
code, but small parts of the runtime can run without a P. For example,
the code that releases a P must still deschedule its G onto a runnable
queue before stopping. Similarly, when a G returns from a long-running
syscall, it must run code to reacquire a P.
Currently, this code can contain write barriers. This can lead to the
GC collecting reachable objects if something like the following
sequence of events happens:
1. GC stops the world by collecting all Ps.
2. G #1 returns from a syscall (for example), tries to install a
pointer to object X, and calls greyobject on X.
3. greyobject on G #1 marks X, but does not yet add it to a write
buffer. At this point, X is effectively black, not grey, even though
it may point to white objects.
4. GC reaches X through some other path and calls greyobject on X, but
greyobject does nothing because X is already marked.
5. GC completes.
6. greyobject on G #1 adds X to a work buffer, but it's too late.
7. Objects that were reachable only through X are incorrectly collected.
To fix this, we check the invariant that no asynchronous write
barriers happen when the world is stopped by checking that write
barriers always have a P, and modify all currently known sources of
these writes to disable the write barrier. In all modified cases this
is safe because the object in question will always be reachable via
some other path.

Some of the trace code was turned off, in particular the
code that traces returning from a syscall. The GC assumes
that as far as the heap is concerned the thread is stopped
when it is in a syscall. Upon returning the trace code
must not do any heap writes for the same reasons discussed
above.

Fixes #10098
Fixes #9953
Fixes #9951
Fixes #9884

May relate to #9610 #9771

Change-Id: Ic2e70b7caffa053e56156838eb8d89503e3c0c8a
Reviewed-on: https://go-review.googlesource.com/7504
Reviewed-by: Austin Clements <austin@google.com>
@gopherbot
Copy link
Author

CL https://golang.org/cl/9696 mentions this issue.

aclements added a commit that referenced this issue May 6, 2015
Currently, the GC uses a moving average of recent scan work ratios to
estimate the total scan work required by this cycle. This is in turn
used to compute how much scan work should be done by mutators when
they allocate in order to perform all expected scan work by the time
the allocated heap reaches the heap goal.

However, our current scan work estimate can be arbitrarily wrong if
the heap topography changes significantly from one cycle to the
next. For example, in the go1 benchmarks, at the beginning of each
benchmark, the heap is dominated by a 256MB no-scan object, so the GC
learns that the scan density of the heap is very low. In benchmarks
that then rapidly allocate pointer-dense objects, by the time of the
next GC cycle, our estimate of the scan work can be too low by a large
factor. This in turn lets the mutator allocate faster than the GC can
collect, allowing it to get arbitrarily far ahead of the scan work
estimate, which leads to very long GC cycles with very little mutator
assist that can overshoot the heap goal by large margins. This is
particularly easy to demonstrate with BinaryTree17:

$ GODEBUG=gctrace=1 ./go1.test -test.bench BinaryTree17
gc #1 @0.017s 2%: 0+0+0+0+0 ms clock, 0+0+0+0/0/0+0 ms cpu, 4->262->262 MB, 4 MB goal, 1 P
gc #2 @0.026s 3%: 0+0+0+0+0 ms clock, 0+0+0+0/0/0+0 ms cpu, 262->262->262 MB, 524 MB goal, 1 P
testing: warning: no tests to run
PASS
BenchmarkBinaryTree17	gc #3 @1.906s 0%: 0+0+0+0+7 ms clock, 0+0+0+0/0/0+7 ms cpu, 325->325->287 MB, 325 MB goal, 1 P (forced)
gc #4 @12.203s 20%: 0+0+0+10067+10 ms clock, 0+0+0+0/2523/852+10 ms cpu, 430->2092->1950 MB, 574 MB goal, 1 P
       1       9150447353 ns/op

Change this estimate to instead use the *current* scannable heap
size. This has the advantage of being based solely on the current
state of the heap, not on past densities or reachable heap sizes, so
it isn't susceptible to falling behind during these sorts of phase
changes. This is strictly an over-estimate, but it's better to
over-estimate and get more assist than necessary than it is to
under-estimate and potentially spiral out of control. Experiments with
scaling this estimate back showed no obvious benefit for mutator
utilization, heap size, or assist time.

This new estimate has little effect for most benchmarks, including
most go1 benchmarks, x/benchmarks, and the 6g benchmark. It has a huge
effect for benchmarks that triggered the bad pacer behavior:

name                   old mean              new mean              delta
BinaryTree17            10.0s × (1.00,1.00)    3.5s × (0.98,1.01)  -64.93% (p=0.000)
Fannkuch11              2.74s × (1.00,1.01)   2.65s × (1.00,1.00)   -3.52% (p=0.000)
FmtFprintfEmpty        56.4ns × (0.99,1.00)  57.8ns × (1.00,1.01)   +2.43% (p=0.000)
FmtFprintfString        187ns × (0.99,1.00)   185ns × (0.99,1.01)   -1.19% (p=0.010)
FmtFprintfInt           184ns × (1.00,1.00)   183ns × (1.00,1.00)  (no variance)
FmtFprintfIntInt        321ns × (1.00,1.00)   315ns × (1.00,1.00)   -1.80% (p=0.000)
FmtFprintfPrefixedInt   266ns × (1.00,1.00)   263ns × (1.00,1.00)   -1.22% (p=0.000)
FmtFprintfFloat         353ns × (1.00,1.00)   353ns × (1.00,1.00)   -0.13% (p=0.035)
FmtManyArgs            1.21µs × (1.00,1.00)  1.19µs × (1.00,1.00)   -1.33% (p=0.000)
GobDecode              9.69ms × (1.00,1.00)  9.59ms × (1.00,1.00)   -1.07% (p=0.000)
GobEncode              7.89ms × (0.99,1.01)  7.74ms × (1.00,1.00)   -1.92% (p=0.000)
Gzip                    391ms × (1.00,1.00)   392ms × (1.00,1.00)     ~    (p=0.522)
Gunzip                 97.1ms × (1.00,1.00)  97.0ms × (1.00,1.00)   -0.10% (p=0.000)
HTTPClientServer       55.7µs × (0.99,1.01)  56.7µs × (0.99,1.01)   +1.81% (p=0.001)
JSONEncode             19.1ms × (1.00,1.00)  19.0ms × (1.00,1.00)   -0.85% (p=0.000)
JSONDecode             66.8ms × (1.00,1.00)  66.9ms × (1.00,1.00)     ~    (p=0.288)
Mandelbrot200          4.13ms × (1.00,1.00)  4.12ms × (1.00,1.00)   -0.08% (p=0.000)
GoParse                3.97ms × (1.00,1.01)  4.01ms × (1.00,1.00)   +0.99% (p=0.000)
RegexpMatchEasy0_32     114ns × (1.00,1.00)   115ns × (0.99,1.00)     ~    (p=0.070)
RegexpMatchEasy0_1K     376ns × (1.00,1.00)   376ns × (1.00,1.00)     ~    (p=0.900)
RegexpMatchEasy1_32    94.9ns × (1.00,1.00)  96.3ns × (1.00,1.01)   +1.53% (p=0.001)
RegexpMatchEasy1_1K     568ns × (1.00,1.00)   567ns × (1.00,1.00)   -0.22% (p=0.001)
RegexpMatchMedium_32    159ns × (1.00,1.00)   159ns × (1.00,1.00)     ~    (p=0.178)
RegexpMatchMedium_1K   46.4µs × (1.00,1.00)  46.6µs × (1.00,1.00)   +0.29% (p=0.000)
RegexpMatchHard_32     2.37µs × (1.00,1.00)  2.37µs × (1.00,1.00)     ~    (p=0.722)
RegexpMatchHard_1K     71.1µs × (1.00,1.00)  71.2µs × (1.00,1.00)     ~    (p=0.229)
Revcomp                 565ms × (1.00,1.00)   562ms × (1.00,1.00)   -0.52% (p=0.000)
Template               81.0ms × (1.00,1.00)  80.2ms × (1.00,1.00)   -0.97% (p=0.000)
TimeParse               380ns × (1.00,1.00)   380ns × (1.00,1.00)     ~    (p=0.148)
TimeFormat              405ns × (0.99,1.00)   385ns × (0.99,1.00)   -5.00% (p=0.000)

Change-Id: I11274158bf3affaf62662e02de7af12d5fb789e4
Reviewed-on: https://go-review.googlesource.com/9696
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Austin Clements <austin@google.com>
rsc added a commit that referenced this issue May 11, 2015
««« backport c6213d8a9118
crypto/rsa: add SHA-224 hash prefix

http://www.rsa.com/rsalabs/node.asp?id=2125:

NOTE: A new OID has been defined for the combination
of the v1.5 signature scheme and the SHA-224 hash function:
        sha224WithRSAEncryption OBJECT IDENTIFIER ::=
Like the other sha*WithRSAEncryption OIDs in PKCS #1 v2.1,
this OID has NULL parameters.
The DigestInfo encoding for SHA-224 (see Section 9.2, Note 1) is:
        (0x)30 2d 30 0d 06 09 60 86 48 01 65 03 04 02 04 05 00 04 1c || H

R=golang-dev, agl
CC=golang-dev
https://golang.org/cl/6208076

»»»
@golang golang locked and limited conversation to collaborators Jun 24, 2016
@gopherbot
Copy link
Author

CL https://golang.org/cl/24743 mentions this issue.

@rsc rsc removed their assignment Jun 22, 2022
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants