cmd/cgo: fails with gcc 4.4.1 #1
Labels
Milestone
Comments
|
Owner changed to [email protected]. Status changed to Started. |
|
This issue was closed by revision 72ec930. Merged into issue #-. |
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 |
|
Labels changed: removed type-defect, priority-medium. Owner changed to [email protected]. 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 <[email protected]>
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 <[email protected]>
Closed
|
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 <[email protected]> Run-TryBot: Austin Clements <[email protected]>
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 »»»
|
CL https://golang.org/cl/24743 mentions this issue. |
This issue was closed.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
by [email protected]:
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.The text was updated successfully, but these errors were encountered: