I have not done the system call stubs in sys_*.s.
I hope to avoid that, because those do not block, so those
frames will not appear in stack traces during garbage
collection.
R=golang-dev, dvyukov, khr
CC=golang-dev
https://golang.org/cl/11360043
While we're here, fix Syscall9 on NetBSD and OpenBSD:
it was storing the results into the wrong memory locations.
I guess no one uses that function's results on those systems.
Part of cleaning up stack traces and argument frame information.
R=golang-dev, dvyukov
CC=golang-dev
https://golang.org/cl/11355044
The portable code in cmd/ld already knows how to process it,
we just have to ignore it during code generation.
R=ken2
CC=golang-dev
https://golang.org/cl/11363043
Design at http://golang.org/s/go12symtab.
This enables some cleanup of the garbage collector metadata
that will be done in future CLs.
This CL does not move the old symtab and pclntab back into
an unmapped section of the file. That's a bit tricky and will be
done separately.
Fixes#4020.
R=golang-dev, dave, cshapiro, iant, r
CC=golang-dev, nigeltao
https://golang.org/cl/11085043
Race instrumentation can allocate, switch stacks, preempt, etc.
All that is not allowed in between fork and exec.
Fixes#4840.
R=golang-dev, daniel.morsing, dave
CC=golang-dev
https://golang.org/cl/11324044
A type switch on a value with map index expressions,
could get a spurious instrumentation from a OTYPESW node.
These nodes do not need instrumentation because after
walk the type switch has been turned into a sequence
of ifs.
Fixes#5890.
R=golang-dev, dvyukov
CC=golang-dev
https://golang.org/cl/11308043
"M requires pointer receiver" can be misinterpreted to
mean that method M should have a pointer receiver but
does not. In fact the message means "M has a pointer
receiver" (and you don't have a pointer).
Fixes#5891.
R=ken2
CC=golang-dev
https://golang.org/cl/11313043
Sets both the duration from the last data packet to the first
keep alive packet and the duration between keep alive packets to be
the passed duration.
I've tested the function on both Darwin (10.8.4) and 4.2 Linux.
I've compiled (make.bash) for all the OS's and tested (all.bash)
on Darwin and Linux.
R=golang-dev, dave, rsc, dvyukov, presotto+facebook, nick
CC=golang-dev, veyron-team
https://golang.org/cl/11130044
Before:
$ go test -c -cover fmt
$ ./fmt.test -test.covermode=set
PASS
coverage: 65.1% of statements in strconv
$
After:
$ go test -c -cover fmt
$ ./fmt.test
PASS
coverage: 65.1% of statements in strconv
$
In addition to being cumbersome, the old flag didn't make sense:
the cover mode cannot be changed after the binary has been built.
Another useful effect of this CL is that if you happen to do
$ go test -c -covermode=atomic fmt
and then forget you did that and run benchmarks,
the final line of the output (the coverage summary) reminds you
that you are benchmarking with coverage enabled, which might
not be what you want.
$ ./fmt.test -test.bench .
PASS
BenchmarkSprintfEmpty 10000000 217 ns/op
BenchmarkSprintfString 2000000 755 ns/op
BenchmarkSprintfInt 2000000 774 ns/op
BenchmarkSprintfIntInt 1000000 1363 ns/op
BenchmarkSprintfPrefixedInt 1000000 1501 ns/op
BenchmarkSprintfFloat 1000000 1257 ns/op
BenchmarkManyArgs 500000 5346 ns/op
BenchmarkScanInts 1000 2562402 ns/op
BenchmarkScanRecursiveInt 500 3189457 ns/op
coverage: 91.4% of statements
$
As part of passing the new mode setting in via _testmain.go, merge
the two registration mechanisms into one extensible mechanism
(a struct).
R=r
CC=golang-dev
https://golang.org/cl/11219043
I want to think more carefully about this.
We put this in because Marshal encoded named []byte but Unmarshal rejected them.
And we noticed that Marshal's behavior was undocumented so we documented it.
But I am starting to think the docs and Unmarshal were correct and Marshal's
behavior was the problem.
Rolling back to give us more time to think.
««« original CL description
json: unmarshal types that are byte slices.
The json package cheerfully would marshal
type S struct {
IP net.IP
}
but would give an error when unmarshalling. This change allows any
type whose concrete type is a byte slice to be unmarshalled from a
string.
Fixes#5086.
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/11161044
»»»
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/11042046
In practice, rejecting an entire structure due to a single invalid byte
in a string is just too picky, and too hard to track down.
Be consistent with the bulk of the standard library by converting
invalid UTF-8 into UTF-8 with replacement runes.
R=golang-dev, crawshaw
CC=golang-dev
https://golang.org/cl/11211045
Recently addition to runtime test makes it take very close to 720s
of timeout limit on the netbsd-arm-qemu builder.
R=golang-dev, go.peter.90, rsc
CC=golang-dev
https://golang.org/cl/10935043
Deferred functions are not run by a call instruction. They are run by
the runtime editing registers to make the call start with a caller PC
returning to a
CALL deferreturn
instruction.
That instruction has always had the line number of the function's
closing brace, but that instruction's line number is irrelevant.
Stack traces show the line number of the instruction before the
return PC, because normally that's what started the call. Not so here.
The instruction before the CALL deferreturn could be almost anywhere
in the function; it's unrelated and its line number is incorrect to show.
Fix the line number by inserting a true hardware no-op with the right
line number before the returned-to CALL instruction. That is, the deferred
calls now appear to start with a caller PC returning to the second instruction
in this sequence:
NOP
CALL deferreturn
The traceback will show the line number of the NOP, which we've set
to be the line number of the function's closing brace.
The NOP here is not the usual pseudo-instruction, which would be
elided by the linker. Instead it is the real hardware instruction:
XCHG AX, AX on 386 and amd64, and AND.EQ R0, R0, R0 on ARM.
Fixes#5856.
R=ken2, ken
CC=golang-dev
https://golang.org/cl/11223043
If the stack frame size is larger than the known-unmapped region at the
bottom of the address space, then the stack split prologue cannot use the usual
condition:
SP - size >= stackguard
because SP - size may wrap around to a very large number.
Instead, if the stack frame is large, the prologue tests:
SP - stackguard >= size
(This ends up being a few instructions more expensive, so we don't do it always.)
Preemption requests register by setting stackguard to a very large value, so
that the first test (SP - size >= stackguard) cannot possibly succeed.
Unfortunately, that same very large value causes a wraparound in the
second test (SP - stackguard >= size), making it succeed incorrectly.
To avoid *that* wraparound, we have to amend the test:
stackguard != StackPreempt && SP - stackguard >= size
This test is only used for functions with large frames, which essentially
always split the stack, so the cost of the few instructions is noise.
This CL and CL 11085043 together fix the known issues with preemption,
at the beginning of a function, so we will be able to try turning it on again.
R=ken2
CC=golang-dev
https://golang.org/cl/11205043
This is a transcript before this change. I've capitalized the text being removed.
Note that it is always near another line that already says fmt, marked with <<<
$ cd $GOROOT/src/pkg/fmt
$ go test -cover
PASS
coverage FOR FMT: 91.3% of statements
ok fmt 0.040s <<<
$ go test -coverpkg strconv
PASS
coverage FOR FMT: 64.9% of statements in strconv
ok fmt 0.039s <<<
$ go test -cover -c
$ ./fmt.test -test.covermode=set <<<
PASS
coverage FOR FMT: 91.3% of statements
$ go test -coverpkg strconv -c
$ ./fmt.test -test.covermode=set <<<
PASS
coverage FOR FMT: 64.9% of statements in strconv
That the summary printed by 'go test [options] fmt' is unchanged:
$ go test -cover fmt
ok fmt 0.040s coverage: 91.3% of statements
$ go test -coverpkg strconv fmt
ok fmt 0.038s coverage: 64.9% of statements in strconv
R=r
CC=gobot, golang-dev
https://golang.org/cl/10932045
The current cas64 definition hard-codes the x86 behavior
of updating *old with the new value when the cas fails.
This is inconsistent with cas32 and casp.
Make it consistent.
This means that the cas64 uses will be epsilon less efficient
than they might be, because they have to do an unnecessary
memory load on x86. But so be it. Code clarity and consistency
is more important.
R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/10909045
STRINGSZ (200) is fine for lines generated by things like
instruction dumps, but an error containing a couple file
names can easily exceed that, especially on Macs with
the ridiculous default $TMPDIR.
R=ken2
CC=golang-dev
https://golang.org/cl/11199043
The json package cheerfully would marshal
type S struct {
IP net.IP
}
but would give an error when unmarshalling. This change allows any
type whose concrete type is a byte slice to be unmarshalled from a
string.
Fixes#5086.
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/11161044
1. "int e;" is unused, generating "unused variable" error.
2. a->e was typed void *[2], but was accessed with *(int *)(a->e), this
generated "dereferencing type-punned pointer will break strict-aliasing rules" error.
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/11009043
runtime.newproc/ready are deliberately sloppy about waking new M's,
they only ensure that there is at least 1 spinning M.
Currently to compensate for that, schedule() checks if the current P
has local work and there are no spinning M's, it wakes up another one.
It does not work if goroutines do not call schedule.
With this change a spinning M wakes up another M when it finds work to do.
It's also not ideal, but it fixes the underutilization.
A proper check would require to know the exact number of runnable G's,
but it's too expensive to maintain.
Fixes#5586.
This is reincarnation of cl/9776044 with the bug fixed.
The bug was due to code added after cl/9776044 was created:
if(tick - (((uint64)tick*0x4325c53fu)>>36)*61 == 0 && runtime·sched.runqsize > 0) {
runtime·lock(&runtime·sched);
gp = globrunqget(m->p, 1);
runtime·unlock(&runtime·sched);
}
If M gets gp from global runq here, it does not reset m->spinning.
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/10743044
Currently it crashes as follows:
fatal error: unknown pc
...
goroutine 71698 [runnable]:
runtime.racegoend()
src/pkg/runtime/race.c:171
runtime.goexit()
src/pkg/runtime/proc.c:1276 +0x9
created by runtime_test.testConcurrentReadsAfterGrowth
src/pkg/runtime/map_test.go:264 +0x332
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/10674047
If you compute the size by subtraction from the address
of the next symbol, it helps to wait until the symbols have
been sorted by address.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/11143043
Merging a couple of CLs into one, since they collided in my client
and I'm lazy.
1) Fix up output in "go test -cover" case.
We need to tell the testing package the name of the package being tested
and the name of the package being covered. It can then sort out the report.
2) Filter out the _test.go files from coverage processing. We want to measure
what the tests cover, not what's covered in the tests,
The coverage for encoding/gob goes from 82.2% to 88.4%.
There may be a cleaner way to do this - suggestions welcome - but ça suffit.
Fixes#5810.
R=rsc
CC=golang-dev
https://golang.org/cl/10868047
CL 10869046 changed cmd/go to checkout master branch, so
for "go get -u" to work, it must "git pull" instead of
"git fetch". Added "--ff-only" so that it won't accidentally
overwrite user changes.
R=dsymonds
CC=golang-dev
https://golang.org/cl/10907043
Part 3 of several.
* Linux has grown a SetsockoptByte.
* SetsockoptIPMreqn is handled directly by syscall_linux.go and syscall_freebsd.go.
R=golang-dev, mikioh.mikioh, r, bradfitz
CC=golang-dev
https://golang.org/cl/10775043
The lzw.NewReader doc comment says, "It is the caller's responsibility
to call Close on the ReadCloser when finished reading."
Thanks to Andrew Bonventre for noticing this.
R=r, dsymonds, adg
CC=andybons, golang-dev
https://golang.org/cl/10821043
ReadMIMEHeader is used by net/http, net/mail, and
mime/multipart.
Don't do so many small allocations. Calculate up front
how much we'll probably need.
benchmark old ns/op new ns/op delta
BenchmarkReadMIMEHeader 8433 7467 -11.45%
benchmark old allocs new allocs delta
BenchmarkReadMIMEHeader 23 14 -39.13%
benchmark old bytes new bytes delta
BenchmarkReadMIMEHeader 1705 1343 -21.23%
R=golang-dev, r, iant, adg
CC=golang-dev
https://golang.org/cl/8179043
origin/master is always a remote branch, and it doesn't make sense to
switch to a remote branch. master is the default branch that tracks it.
R=adg
CC=golang-dev, matt.jibson
https://golang.org/cl/10869046
This does not include AES-GCM yet. Also, it assumes that the handshake and
certificate signature hash are always SHA-256, which is true of the ciphersuites
that we currently support.
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/10762044
using m->tls[0] to save ucontext pointer is not re-entry safe, and
the old code didn't set it before the early return when signal is
received on non-Go threads.
so misc/cgo/test used to hang when testing issue 5337.
R=golang-dev, bradfitz, rsc
CC=golang-dev
https://golang.org/cl/10076045
Escape analysis needs the right curfn value on a dclfunc node, otherwise it will not analyze the function.
When generating method value wrappers, we forgot to set the curfn correctly.
Fixes#5753.
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/10383048
A struct with a single field was considered as equivalent to the
field type, which is incorrect is the field is blank.
Fields with padding could make the compiler think some
types are comparable when they are not.
Fixes#5698.
R=rsc, golang-dev, daniel.morsing, bradfitz, gri, r
CC=golang-dev
https://golang.org/cl/10271046
When deleting a timer, a panic due to nil deref
would leave a lock held, possibly leading to a deadlock
in a defer. Instead return false on a nil timer.
Fixes#5745.
R=golang-dev, daniel.morsing, dvyukov, rsc, iant
CC=golang-dev
https://golang.org/cl/10373047
This CL provides stable in-place sorting by use of
bottom up merge sort with in-place merging done by
the SymMerge algorithm from P.-S. Kim and A. Kutzner.
The additional space needed for stable sorting (in the form of
stack space) is logarithmic in the inputs size n.
Number of calls to Less and Swap grow like O(n * log n) and
O(n * log n * log n):
Stable sorting random data uses significantly more calls
to Swap than the unstable quicksort implementation (5 times more
on n=100, 10 times more on n=1e4 and 23 times more on n=1e8).
The number of calls to Less is practically the same for Sort and
Stable.
Stable sorting 1 million random integers takes 5 times longer
than using Sort.
BenchmarkSortString1K 50000 328662 ns/op
BenchmarkStableString1K 50000 380231 ns/op 1.15 slower
BenchmarkSortInt1K 50000 157336 ns/op
BenchmarkStableInt1K 50000 191167 ns/op 1.22 slower
BenchmarkSortInt64K 1000 14466297 ns/op
BenchmarkStableInt64K 500 16190266 ns/op 1.12 slower
BenchmarkSort1e2 200000 64923 ns/op
BenchmarkStable1e2 50000 167128 ns/op 2.57 slower
BenchmarkSort1e4 1000 14540613 ns/op
BenchmarkStable1e4 100 58117289 ns/op 4.00 slower
BenchmarkSort1e6 5 2429631508 ns/op
BenchmarkStable1e6 1 12077036952 ns/op 4.97 slower
R=golang-dev, bradfitz, iant, 0xjnml, rsc
CC=golang-dev
https://golang.org/cl/9612044
Design doc at golang.org/s/go12slice.
This is an experimental feature and may not be included in the release.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/10743046
There are various problems, and both Dmitriy and I
will be away for the next week. Make the runtime a bit
more stable while we're gone.
R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/10848043
fn can clearly hold a closure in memory.
argp/pc point into stack and so can hold
in memory a block that was previously
a large stack serment.
R=golang-dev, dave, rsc
CC=golang-dev
https://golang.org/cl/10784043
Depending on net/http means depending on cgo.
When the tree is in a shaky state it's nice to see sync/atomic
pass even if cgo or net causes broken binaries.
R=golang-dev, dave, r
CC=golang-dev
https://golang.org/cl/10753044
After loading a frame of a GIF, check that each pixel
is inside the frame's palette.
Fixes#5401.
R=nigeltao, r
CC=golang-dev
https://golang.org/cl/10597043
A casualty of https://golang.org/cl/10195044.
If x is an 32-bit int and u is a 64-bit ulong,
u = (uint)x // converts to uint before extension, so zero fills
u = (ulong)x // sign-extends
TBR=iant, r
CC=golang-dev
https://golang.org/cl/10814043
Exported inlined functions that perform a string conversion
using a non-exported named type may miss it in export data.
Fixes#5755.
R=rsc, golang-dev, ality, r
CC=golang-dev
https://golang.org/cl/10464043
On amd64 the frames are very close to the limit for a
nosplit (textflag 7) function, in part because the C compiler
does not make any attempt to reclaim space allocated for
completely registerized variables. Avoid a few short-lived
variables to reclaim two words.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/10758043
Keeping the string "compactframe" because that's what
I always search for to find this code. But point to the real place too.
TBR=iant
CC=golang-dev
https://golang.org/cl/10676047
Currently it replaces GOGCTRACE env var (GODEBUG=gctrace=1).
The plan is to extend it with other type of debug tracing,
e.g. GODEBUG=gctrace=1,schedtrace=100.
R=rsc
CC=bradfitz, daniel.morsing, gobot, golang-dev
https://golang.org/cl/10026045
The last patch for preemptive scheduler,
with this change stoptheworld issues preemption
requests every 100us.
Update #543.
R=golang-dev, daniel.morsing, rsc
CC=golang-dev
https://golang.org/cl/10264044
The new -coverpkg flag allows computing coverage in
one set of packages while running the tests of a different set.
Also clean up some of the previous CL's recompileForTest,
using packageList to avoid the clumsy recursion.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/10705043
On x86 it is a few words lower on the stack than m->morebuf.sp
so it is a more precise check. Enabling the check requires recording
a valid gp->sched in reflect.call too. This is a good thing in general,
since it will make stack traces during reflect.call work better, and it
may be useful for preemption too.
R=dvyukov
CC=golang-dev
https://golang.org/cl/10709043
runtime.entersyscall() sets g->status = Gsyscall,
then calls runtime.lock() which causes stack split.
runtime.newstack() resets g->status to Grunning.
This will lead to crash during GC (world is not stopped) or GC will scan stack incorrectly.
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/10696043
Also use 2048-bit RSA keys as default in generate_cert.go,
as recommended by the NIST.
R=golang-dev, rsc, bradfitz
CC=golang-dev
https://golang.org/cl/10676043
On my 64-bit machine, despite being 32-bit code, fixed-base
multiplications are 7.1x faster and arbitary multiplications are 2.6x
faster.
It is difficult to review this change. However, the code is essentially
the same as code that has been open-sourced in Chromium. There it has
been successfully performing P-256 operations for several months on
many machines so the arithmetic of the code should be sound.
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/10551044
Failure on bot:
http://build.golang.org/log/f4c648906e1289ec2237c1d0880fb1a8b1852a08
««« original CL description
runtime: fix CPU underutilization
runtime.newproc/ready are deliberately sloppy about waking new M's,
they only ensure that there is at least 1 spinning M.
Currently to compensate for that, schedule() checks if the current P
has local work and there are no spinning M's, it wakes up another one.
It does not work if goroutines do not call schedule.
With this change a spinning M wakes up another M when it finds work to do.
It's also not ideal, but it fixes the underutilization.
A proper check would require to know the exact number of runnable G's,
but it's too expensive to maintain.
Fixes#5586.
R=rsc
TBR=rsc
CC=gobot, golang-dev
https://golang.org/cl/9776044
»»»
R=golang-dev
CC=golang-dev
https://golang.org/cl/10692043
runtime.newproc/ready are deliberately sloppy about waking new M's,
they only ensure that there is at least 1 spinning M.
Currently to compensate for that, schedule() checks if the current P
has local work and there are no spinning M's, it wakes up another one.
It does not work if goroutines do not call schedule.
With this change a spinning M wakes up another M when it finds work to do.
It's also not ideal, but it fixes the underutilization.
A proper check would require to know the exact number of runnable G's,
but it's too expensive to maintain.
Fixes#5586.
R=rsc
CC=gobot, golang-dev
https://golang.org/cl/9776044
Current code can print more arguments than necessary
and also incorrectly prints "...".
Update #5723.
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/10689043
Until now, the goroutine state has been scattered during the
execution of newstack and oldstack. It's all there, and those routines
know how to get back to a working goroutine, but other pieces of
the system, like stack traces, do not. If something does interrupt
the newstack or oldstack execution, the rest of the system can't
understand the goroutine. For example, if newstack decides there
is an overflow and calls throw, the stack tracer wouldn't dump the
goroutine correctly.
For newstack to save a useful state snapshot, it needs to be able
to rewind the PC in the function that triggered the split back to
the beginning of the function. (The PC is a few instructions in, just
after the call to morestack.) To make that possible, we change the
prologues to insert a jmp back to the beginning of the function
after the call to morestack. That is, the prologue used to be roughly:
TEXT myfunc
check for split
jmpcond nosplit
call morestack
nosplit:
sub $xxx, sp
Now an extra instruction is inserted after the call:
TEXT myfunc
start:
check for split
jmpcond nosplit
call morestack
jmp start
nosplit:
sub $xxx, sp
The jmp is not executed directly. It is decoded and simulated by
runtime.rewindmorestack to discover the beginning of the function,
and then the call to morestack returns directly to the start label
instead of to the jump instruction. So logically the jmp is still
executed, just not by the cpu.
The prologue thus repeats in the case of a function that needs a
stack split, but against the cost of the split itself, the extra few
instructions are noise. The repeated prologue has the nice effect of
making a stack split double-check that the new stack is big enough:
if morestack happens to return on a too-small stack, we'll now notice
before corruption happens.
The ability for newstack to rewind to the beginning of the function
should help preemption too. If newstack decides that it was called
for preemption instead of a stack split, it now has the goroutine state
correctly paused if rescheduling is needed, and when the goroutine
can run again, it can return to the start label on its original stack
and re-execute the split check.
Here is an example of a split stack overflow showing the full
trace, without any special cases in the stack printer.
(This one was triggered by making the split check incorrect.)
runtime: newstack framesize=0x0 argsize=0x18 sp=0x6aebd0 stack=[0x6b0000, 0x6b0fa0]
morebuf={pc:0x69f5b sp:0x6aebd8 lr:0x0}
sched={pc:0x68880 sp:0x6aebd0 lr:0x0 ctxt:0x34e700}
runtime: split stack overflow: 0x6aebd0 < 0x6b0000
fatal error: runtime: split stack overflow
goroutine 1 [stack split]:
runtime.mallocgc(0x290, 0x100000000, 0x1)
/Users/rsc/g/go/src/pkg/runtime/zmalloc_darwin_amd64.c:21 fp=0x6aebd8
runtime.new()
/Users/rsc/g/go/src/pkg/runtime/zmalloc_darwin_amd64.c:682 +0x5b fp=0x6aec08
go/build.(*Context).Import(0x5ae340, 0xc210030c71, 0xa, 0xc2100b4380, 0x1b, ...)
/Users/rsc/g/go/src/pkg/go/build/build.go:424 +0x3a fp=0x6b00a0
main.loadImport(0xc210030c71, 0xa, 0xc2100b4380, 0x1b, 0xc2100b42c0, ...)
/Users/rsc/g/go/src/cmd/go/pkg.go:249 +0x371 fp=0x6b01a8
main.(*Package).load(0xc21017c800, 0xc2100b42c0, 0xc2101828c0, 0x0, 0x0, ...)
/Users/rsc/g/go/src/cmd/go/pkg.go:431 +0x2801 fp=0x6b0c98
main.loadPackage(0x369040, 0x7, 0xc2100b42c0, 0x0)
/Users/rsc/g/go/src/cmd/go/pkg.go:709 +0x857 fp=0x6b0f80
----- stack segment boundary -----
main.(*builder).action(0xc2100902a0, 0x0, 0x0, 0xc2100e6c00, 0xc2100e5750, ...)
/Users/rsc/g/go/src/cmd/go/build.go:539 +0x437 fp=0x6b14a0
main.(*builder).action(0xc2100902a0, 0x0, 0x0, 0xc21015b400, 0x2, ...)
/Users/rsc/g/go/src/cmd/go/build.go:528 +0x1d2 fp=0x6b1658
main.(*builder).test(0xc2100902a0, 0xc210092000, 0x0, 0x0, 0xc21008ff60, ...)
/Users/rsc/g/go/src/cmd/go/test.go:622 +0x1b53 fp=0x6b1f68
----- stack segment boundary -----
main.runTest(0x5a6b20, 0xc21000a020, 0x2, 0x2)
/Users/rsc/g/go/src/cmd/go/test.go:366 +0xd09 fp=0x6a5cf0
main.main()
/Users/rsc/g/go/src/cmd/go/main.go:161 +0x4f9 fp=0x6a5f78
runtime.main()
/Users/rsc/g/go/src/pkg/runtime/proc.c:183 +0x92 fp=0x6a5fa0
runtime.goexit()
/Users/rsc/g/go/src/pkg/runtime/proc.c:1266 fp=0x6a5fa8
And here is a seg fault during oldstack:
SIGSEGV: segmentation violation
PC=0x1b2a6
runtime.oldstack()
/Users/rsc/g/go/src/pkg/runtime/stack.c:159 +0x76
runtime.lessstack()
/Users/rsc/g/go/src/pkg/runtime/asm_amd64.s:270 +0x22
goroutine 1 [stack unsplit]:
fmt.(*pp).printArg(0x2102e64e0, 0xe5c80, 0x2102c9220, 0x73, 0x0, ...)
/Users/rsc/g/go/src/pkg/fmt/print.go:818 +0x3d3 fp=0x221031e6f8
fmt.(*pp).doPrintf(0x2102e64e0, 0x12fb20, 0x2, 0x221031eb98, 0x1, ...)
/Users/rsc/g/go/src/pkg/fmt/print.go:1183 +0x15cb fp=0x221031eaf0
fmt.Sprintf(0x12fb20, 0x2, 0x221031eb98, 0x1, 0x1, ...)
/Users/rsc/g/go/src/pkg/fmt/print.go:234 +0x67 fp=0x221031eb40
flag.(*stringValue).String(0x2102c9210, 0x1, 0x0)
/Users/rsc/g/go/src/pkg/flag/flag.go:180 +0xb3 fp=0x221031ebb0
flag.(*FlagSet).Var(0x2102f6000, 0x293d38, 0x2102c9210, 0x143490, 0xa, ...)
/Users/rsc/g/go/src/pkg/flag/flag.go:633 +0x40 fp=0x221031eca0
flag.(*FlagSet).StringVar(0x2102f6000, 0x2102c9210, 0x143490, 0xa, 0x12fa60, ...)
/Users/rsc/g/go/src/pkg/flag/flag.go:550 +0x91 fp=0x221031ece8
flag.(*FlagSet).String(0x2102f6000, 0x143490, 0xa, 0x12fa60, 0x0, ...)
/Users/rsc/g/go/src/pkg/flag/flag.go:563 +0x87 fp=0x221031ed38
flag.String(0x143490, 0xa, 0x12fa60, 0x0, 0x161950, ...)
/Users/rsc/g/go/src/pkg/flag/flag.go:570 +0x6b fp=0x221031ed80
testing.init()
/Users/rsc/g/go/src/pkg/testing/testing.go:-531 +0xbb fp=0x221031edc0
strings_test.init()
/Users/rsc/g/go/src/pkg/strings/strings_test.go:1115 +0x62 fp=0x221031ef70
main.init()
strings/_test/_testmain.go:90 +0x3d fp=0x221031ef78
runtime.main()
/Users/rsc/g/go/src/pkg/runtime/proc.c:180 +0x8a fp=0x221031efa0
runtime.goexit()
/Users/rsc/g/go/src/pkg/runtime/proc.c:1269 fp=0x221031efa8
goroutine 2 [runnable]:
runtime.MHeap_Scavenger()
/Users/rsc/g/go/src/pkg/runtime/mheap.c:438
runtime.goexit()
/Users/rsc/g/go/src/pkg/runtime/proc.c:1269
created by runtime.main
/Users/rsc/g/go/src/pkg/runtime/proc.c:166
rax 0x23ccc0
rbx 0x23ccc0
rcx 0x0
rdx 0x38
rdi 0x2102c0170
rsi 0x221032cfe0
rbp 0x221032cfa0
rsp 0x7fff5fbff5b0
r8 0x2102c0120
r9 0x221032cfa0
r10 0x221032c000
r11 0x104ce8
r12 0xe5c80
r13 0x1be82baac718
r14 0x13091135f7d69200
r15 0x0
rip 0x1b2a6
rflags 0x10246
cs 0x2b
fs 0x0
gs 0x0
Fixes#5723.
R=r, dvyukov, go.peter.90, dave, iant
CC=golang-dev
https://golang.org/cl/10360048
Setenv("AN_ENV_VAR", "") deletes AN_ENV_VAR instead of setting it
to "" at this moment. Also Getenv("AN_ENV_VAR") returns "not found",
if AN_ENV_VAR is "". Change it, so they behave like unix.
Fixes#5610
R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/10594043
Makes it easy to ask the simple question, what is the hash of this data?
Also fix the commentary and prints in Sum256.
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/10630043
With this CL, go test -short -cover std successfully builds and
runs all the standard package tests. The tests that look a file
line numbers (log and runtime/debug) fail, because cover is
not inserting //line directives. Everything else passes.
ok cmd/api 0.038s coverage: 66.6% of statements
? cmd/cgo [no test files]
ok cmd/fix 0.043s coverage: 27.2% of statements
ok cmd/go 0.063s coverage: 2.4% of statements
? cmd/godoc [no test files]
ok cmd/gofmt 0.085s coverage: 61.3% of statements
? cmd/yacc [no test files]
ok archive/tar 0.023s coverage: 74.2% of statements
ok archive/zip 0.075s coverage: 71.8% of statements
ok bufio 0.149s coverage: 88.2% of statements
ok bytes 0.135s coverage: 90.4% of statements
ok compress/bzip2 0.087s coverage: 85.1% of statements
ok compress/flate 0.632s coverage: 79.3% of statements
ok compress/gzip 0.027s coverage: 76.7% of statements
ok compress/lzw 0.141s coverage: 71.2% of statements
ok compress/zlib 1.123s coverage: 77.2% of statements
ok container/heap 0.020s coverage: 85.8% of statements
ok container/list 0.021s coverage: 92.5% of statements
ok container/ring 0.030s coverage: 86.5% of statements
? crypto [no test files]
ok crypto/aes 0.054s coverage: 54.3% of statements
ok crypto/cipher 0.027s coverage: 68.8% of statements
ok crypto/des 0.041s coverage: 83.8% of statements
ok crypto/dsa 0.027s coverage: 33.1% of statements
ok crypto/ecdsa 0.048s coverage: 48.7% of statements
ok crypto/elliptic 0.030s coverage: 91.6% of statements
ok crypto/hmac 0.019s coverage: 83.3% of statements
ok crypto/md5 0.020s coverage: 78.7% of statements
ok crypto/rand 0.057s coverage: 20.8% of statements
ok crypto/rc4 0.092s coverage: 70.8% of statements
ok crypto/rsa 0.261s coverage: 80.8% of statements
ok crypto/sha1 0.019s coverage: 83.9% of statements
ok crypto/sha256 0.021s coverage: 89.0% of statements
ok crypto/sha512 0.023s coverage: 88.7% of statements
ok crypto/subtle 0.027s coverage: 83.9% of statements
ok crypto/tls 0.833s coverage: 79.7% of statements
ok crypto/x509 0.961s coverage: 74.9% of statements
? crypto/x509/pkix [no test files]
ok database/sql 0.033s coverage: 75.0% of statements
ok database/sql/driver 0.020s coverage: 46.2% of statements
ok debug/dwarf 0.023s coverage: 71.5% of statements
ok debug/elf 0.035s coverage: 58.2% of statements
ok debug/gosym 0.022s coverage: 1.8% of statements
ok debug/macho 0.023s coverage: 63.7% of statements
ok debug/pe 0.024s coverage: 50.5% of statements
ok encoding/ascii85 0.021s coverage: 89.7% of statements
ok encoding/asn1 0.022s coverage: 77.9% of statements
ok encoding/base32 0.022s coverage: 91.4% of statements
ok encoding/base64 0.020s coverage: 90.7% of statements
ok encoding/binary 0.022s coverage: 66.2% of statements
ok encoding/csv 0.022s coverage: 88.5% of statements
ok encoding/gob 0.064s coverage: 82.2% of statements
ok encoding/hex 0.019s coverage: 86.3% of statements
ok encoding/json 0.047s coverage: 77.3% of statements
ok encoding/pem 0.026s coverage: 80.5% of statements
ok encoding/xml 0.039s coverage: 85.0% of statements
ok errors 0.022s coverage: 100.0% of statements
ok expvar 0.048s coverage: 72.0% of statements
ok flag 0.019s coverage: 86.9% of statements
ok fmt 0.062s coverage: 91.2% of statements
ok go/ast 0.028s coverage: 46.3% of statements
ok go/build 0.190s coverage: 75.4% of statements
ok go/doc 0.095s coverage: 76.7% of statements
ok go/format 0.036s coverage: 79.8% of statements
ok go/parser 0.075s coverage: 82.0% of statements
ok go/printer 0.733s coverage: 88.6% of statements
ok go/scanner 0.031s coverage: 86.5% of statements
ok go/token 0.062s coverage: 79.7% of statements
? hash [no test files]
ok hash/adler32 0.029s coverage: 49.0% of statements
ok hash/crc32 0.020s coverage: 64.2% of statements
ok hash/crc64 0.021s coverage: 53.5% of statements
ok hash/fnv 0.018s coverage: 75.5% of statements
ok html 0.022s coverage: 4.5% of statements
ok html/template 0.087s coverage: 83.9% of statements
ok image 0.108s coverage: 67.1% of statements
ok image/color 0.026s coverage: 20.1% of statements
ok image/draw 0.049s coverage: 69.6% of statements
ok image/gif 0.019s coverage: 65.2% of statements
ok image/jpeg 0.197s coverage: 78.6% of statements
ok image/png 0.055s coverage: 56.5% of statements
ok index/suffixarray 0.027s coverage: 82.4% of statements
ok io 0.037s coverage: 83.4% of statements
ok io/ioutil 0.022s coverage: 70.1% of statements
FAIL log 0.020s
ok log/syslog 2.063s coverage: 71.1% of statements
ok math 0.023s coverage: 76.5% of statements
ok math/big 0.235s coverage: 79.2% of statements
ok math/cmplx 0.020s coverage: 66.5% of statements
ok math/rand 0.031s coverage: 69.9% of statements
ok mime 0.022s coverage: 83.0% of statements
ok mime/multipart 0.389s coverage: 76.1% of statements
ok net 2.219s coverage: 58.0% of statements
ok net/http 4.744s coverage: 82.9% of statements
ok net/http/cgi 0.593s coverage: 68.5% of statements
ok net/http/cookiejar 0.038s coverage: 90.3% of statements
ok net/http/fcgi 0.047s coverage: 37.6% of statements
ok net/http/httptest 0.068s coverage: 68.9% of statements
ok net/http/httputil 0.058s coverage: 52.8% of statements
? net/http/pprof [no test files]
ok net/mail 0.025s coverage: 80.3% of statements
ok net/rpc 0.063s coverage: 71.5% of statements
ok net/rpc/jsonrpc 0.047s coverage: 81.3% of statements
ok net/smtp 0.032s coverage: 74.1% of statements
ok net/textproto 0.023s coverage: 66.0% of statements
ok net/url 0.020s coverage: 78.2% of statements
ok os 4.729s coverage: 73.3% of statements
ok os/exec 39.620s coverage: 65.1% of statements
ok os/signal 0.541s coverage: 89.9% of statements
ok os/user 0.022s coverage: 62.2% of statements
ok path 0.018s coverage: 90.8% of statements
ok path/filepath 10.834s coverage: 88.4% of statements
ok reflect 0.055s coverage: 83.2% of statements
ok regexp 0.084s coverage: 75.5% of statements
ok regexp/syntax 0.547s coverage: 85.2% of statements
ok runtime 4.755s coverage: 75.9% of statements
? runtime/cgo [no test files]
FAIL runtime/debug 0.018s
ok runtime/pprof 0.368s coverage: 8.5% of statements
? runtime/race [no test files]
ok sort 0.059s coverage: 97.7% of statements
ok strconv 0.315s coverage: 95.6% of statements
ok strings 0.147s coverage: 96.1% of statements
ok sync 0.083s coverage: 56.7% of statements
ok sync/atomic 0.035s coverage: 0.0% of statements
ok syscall 0.043s coverage: 24.0% of statements
ok testing 0.018s coverage: 24.0% of statements
? testing/iotest [no test files]
ok testing/quick 0.062s coverage: 83.2% of statements
ok text/scanner 0.020s coverage: 91.5% of statements
ok text/tabwriter 0.021s coverage: 90.4% of statements
ok text/template 0.052s coverage: 81.1% of statements
ok text/template/parse 0.024s coverage: 86.1% of statements
ok time 2.431s coverage: 88.8% of statements
ok unicode 0.024s coverage: 92.1% of statements
ok unicode/utf16 0.017s coverage: 97.3% of statements
ok unicode/utf8 0.019s coverage: 97.4% of statements
? unsafe [no test files]
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/10586043
Makes it easy to ask the simple question, what is the hash of this data?
Also mark block as non-escaping.
R=golang-dev, agl
CC=golang-dev
https://golang.org/cl/10624044
Before, some packages disappear silently if the package cannot be imported,
such as if the import statement is unparseable.
Before:
% ls src
foo issue
% go list ./...
_/home/r/bug/src/foo
%
After:
% go list ./...
src/issue/issue.go:3:5: expected 'STRING', found newline
_/home/r/bug/src/foo
%
R=rsc
CC=golang-dev
https://golang.org/cl/10568043
Functions without bodies were excluded from the ordering logic,
because when I wrote the ordering logic there was no reason to
analyze them.
But then we added //go:noescape tags that need analysis, and we
didn't update the ordering logic.
So in the absence of good ordering, //go:noescape only worked
if it appeared before the use in the source code.
Fixes#5773.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/10570043
USEFIELD is a special kind of NOP, so treat it like a NOP
when generating the pc-ln table.
There are more invasive fixes that could be applied here.
I am going for minimum number of lines changed.
The smallest test case we know of is five distinct Go files
in four packages, and the bug only happens with
GOEXPERIMENT=fieldtrack enabled, which we don't
normally build with, so the test would never run
meaningfully anyway.
Fixes#5762.
R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/10495044
Built after adding -Wconversion to the list of compiler
arguments used when building. I believe these are all OK
assuming we will not change the API. There is no effort to
detect overflow due to very long strings.
R=golang-dev, dave, rsc, r
CC=golang-dev
https://golang.org/cl/10195044
Currently more than 1 gorutine can execute raceWrite() in Wait()
in the following scenario:
1. goroutine 1 executes first check of wg.counter, sees that it's == 0
2. goroutine 2 executes first check of wg.counter, sees that it's == 0
3. goroutine 2 locks the mutex, sees that he is the first waiter and executes raceWrite()
4. goroutine 2 block on the semaphore
5. goroutine 3 executes Done() and unblocks goroutine 2
6. goroutine 1 lock the mutex, sees that he is the first waiter and executes raceWrite()
It produces the following false report:
WARNING: DATA RACE
Write by goroutine 35:
sync.raceWrite()
src/pkg/sync/race.go:41 +0x33
sync.(*WaitGroup).Wait()
src/pkg/sync/waitgroup.go:103 +0xae
command-line-arguments_test.TestNoRaceWaitGroupMultipleWait2()
src/pkg/runtime/race/testdata/waitgroup_test.go:156 +0x19a
testing.tRunner()
src/pkg/testing/testing.go:361 +0x108
Previous write by goroutine 36:
sync.raceWrite()
src/pkg/sync/race.go:41 +0x33
sync.(*WaitGroup).Wait()
src/pkg/sync/waitgroup.go:103 +0xae
command-line-arguments_test.func·012()
src/pkg/runtime/race/testdata/waitgroup_test.go:148 +0x4d
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/10424043
Resubmit 3c2cddfbdaec now that windows callbacks
are not generated during runtime.
Fixes#5494
R=golang-dev, minux.ma, rsc
CC=golang-dev
https://golang.org/cl/10487043
- change runtime_pollWait so it does not return
closed or timeout if IO is ready - windows must
know if IO has completed or not even after
interruption;
- add (*pollDesc).Prepare(mode int) that can be
used for both read and write, same for Wait;
- introduce runtime_pollWaitCanceled and expose
it in net as (*pollDesc).WaitCanceled(mode int);
Full windows netpoll changes are
here https://golang.org/cl/8670044/.
R=golang-dev, dvyukov
CC=golang-dev
https://golang.org/cl/10485043
The compiler still gets the escape analysis wrong, but the annotation here is correct.
R=golang-dev, dave, bradfitz
CC=golang-dev
https://golang.org/cl/10514046
No semantic change.
I found the wording distracting in a couple of instances and was moved to improve it.
R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/10478048
If a server response contains a Content-Length and the body is short,
the Transport should end in io.ErrUnexpectedEOF, not io.EOF.
Fixes#5738
R=golang-dev, kevlar, r
CC=golang-dev
https://golang.org/cl/10237050
until we decide what to do with issues 5659/5736.
Profiling with race detector is not very useful in general,
and now it makes race builders red.
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/10523043
Time is a tiny struct, so the compiler copies a Time by
copying each of the three fields.
The layout of a time on amd64 is [ptr int32 gap32 ptr].
Copying a Time onto a location that formerly held a pointer in the
second word changes only the low 32 bits, creating a different
but still plausible pointer. This confuses the garbage collector
when it appears in argument or result frames.
To avoid this problem, declare nsec as uintptr, so that there is
no gap on amd64 anymore, and therefore no partial pointers.
Note that rearranging the fields to put the int32 last still leaves
a gap - [ptr ptr int32 gap32] - because Time must have a total
size that is ptr-width aligned.
Update #5749
This CL is enough to fix the problem, but we should still do
the other actions listed in the initial report. We're not too far
from completely precise collection.
R=golang-dev, dvyukov, r
CC=golang-dev
https://golang.org/cl/10504043
The tradition is to use _posix when the platform extends beyond unix variants. As windows has its own file, rename to the more usual _unix.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/10320043
If time.Sub results in a value that won't fit in a Duration (int64),
return either the min or max int64 value as appropriate.
Fixes#5011.
R=golang-dev, bradfitz, r, rsc
CC=golang-dev
https://golang.org/cl/10328043
trivial: it is not a serious problem to leak a fd in a short lived process, but it was obscuring my investigation of issue 5593.
R=golang-dev, iant, bradfitz
CC=golang-dev
https://golang.org/cl/10391043
The old code worked, somewhat on accident, but was confusing,
and had a useless assignment to the inner err. It worked
because url.Parse parses just about anything, so the outer err
was always nil, so it always fell through to the bottom return
statement, even without the "err = nil" line.
Instead, just have two return statements, and add a comment.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/10448044
Output now:
ok crypto/aes 0.060s coverage: 89.8% of statements
ok crypto/des 0.074s coverage: 92.2% of statements
ok crypto/dsa 0.056s coverage: 34.5% of statements
ok crypto/ecdsa 0.058s coverage: 86.8% of statements
ok crypto/elliptic 0.039s coverage: 94.6% of statements
ok crypto/hmac 0.037s coverage: 93.5% of statements
ok crypto/md5 0.031s coverage: 96.2% of statements
ok crypto/rand 0.074s coverage: 9.9% of statements
ok crypto/rc4 0.090s coverage: 66.7% of statements
ok crypto/rsa 0.253s coverage: 83.5% of statements
R=rsc, adg
CC=golang-dev
https://golang.org/cl/10413044
TLS clients send ciphersuites in preference order (most prefereable
first). This change alters the order so that ECDHE comes before plain
RSA, and RC4 comes before AES (because of the Lucky13 attack).
This is unlikely to have much effect: as a server, the code uses the
client's ciphersuite order by default and, as a client, the non-Go
server probably imposes its order.
R=golang-dev, r, raggi, jsing
CC=golang-dev
https://golang.org/cl/10372045
The single flag -cover provides the default simplest behavior.
The other flags, -covermode and -coverprofile, provide more
control. The three flags interconnect to work well.
R=rsc, adg
CC=golang-dev
https://golang.org/cl/10364044
