- 28 Apr, 2011 12 commits
-
-
Russ Cox authored
Fixes #1722. R=ken2 CC=golang-dev https://golang.org/cl/4442099
-
Evan Shaw authored
R=golang-dev, bradfitz, dsymonds CC=golang-dev https://golang.org/cl/4426069
-
Andrew Gerrand authored
R=golang-dev CC=golang-dev https://golang.org/cl/4439081
-
Andrew Gerrand authored
R=rsc CC=golang-dev https://golang.org/cl/4437077
-
Andrew Gerrand authored
R=rsc, bradfitz CC=golang-dev https://golang.org/cl/4431068
-
Brad Fitzpatrick authored
before & after: adler32.BenchmarkGolden 100000 14747 ns/op adler32.BenchmarkGolden 200000 8761 ns/op Found by profiling PNG encoding. R=rsc, bradfitzwork, eds CC=golang-dev https://golang.org/cl/4441073
-
Russ Cox authored
This time for sure. R=golang-dev, dsymonds CC=golang-dev https://golang.org/cl/4437078
-
Lorenzo Stoakes authored
Previously, whether declaring a type which copied the structure of a type it was referenced in via a pointer field would work depended on whether you declared it before or after the type it copied, e.g. type T2 T1; type T1 struct { F *T2 } would work, however type T1 struct { F *T2 }; type T2 T1 wouldn't. Fixes #667. R=rsc CC=golang-dev https://golang.org/cl/4313064
-
Russ Cox authored
The g->sched.sp saved stack pointer and the g->stackbase and g->stackguard stack bounds can change even while "the world is stopped", because a goroutine has to call functions (and therefore might split its stack) when exiting a system call to check whether the world is stopped (and if so, wait until the world continues). That means the garbage collector cannot access those values safely (without a race) for goroutines executing system calls. Instead, save a consistent triple in g->gcsp, g->gcstack, g->gcguard during entersyscall and have the garbage collector refer to those. The old code was occasionally seeing (because of the race) an sp and stk that did not correspond to each other, so that stk - sp was not the number of stack bytes following sp. In that case, if sp < stk then the call scanblock(sp, stk - sp) scanned too many bytes (anything between the two pointers, which pointed into different allocation blocks). If sp > stk then stk - sp wrapped around. On 32-bit, stk - sp is a uintptr (uint32) converted to int64 in the call to scanblock, so a large (~4G) but positive number. Scanblock would try to scan that many bytes and eventually fault accessing unmapped memory. On 64-bit, stk - sp is a uintptr (uint64) promoted to int64 in the call to scanblock, so a negative number. Scanblock would not scan anything, possibly causing in-use blocks to be freed. In short, 32-bit platforms would have seen either ineffective garbage collection or crashes during garbage collection, while 64-bit platforms would have seen either ineffective or incorrect garbage collection. You can see the invalid arguments to scanblock in the stack traces in issue 1620. Fixes #1620. Fixes #1746. R=iant, r CC=golang-dev https://golang.org/cl/4437075
-
Russ Cox authored
Fixes #1397. R=iant CC=golang-dev https://golang.org/cl/4444064
-
Russ Cox authored
runtime: memory allocated by OS not in usable range runtime: out of memory: cannot allocate 1114112-byte block (2138832896 in use) throw: out of memory runtime.throw+0x40 /Users/rsc/g/go/src/pkg/runtime/runtime.c:102 runtime.throw(0x1fffd, 0x101) runtime.mallocgc+0x2af /Users/rsc/g/go/src/pkg/runtime/malloc.c:60 runtime.mallocgc(0x100004, 0x0, 0x1, 0x1, 0xc093, ...) runtime.mal+0x40 /Users/rsc/g/go/src/pkg/runtime/malloc.c:289 runtime.mal(0x100004, 0x20bc4) runtime.new+0x26 /Users/rsc/g/go/src/pkg/runtime/malloc.c:296 runtime.new(0x100004, 0x8fe84000, 0x20bc4) main.main+0x29 /Users/rsc/x.go:11 main.main() runtime.mainstart+0xf /Users/rsc/g/go/src/pkg/runtime/386/asm.s:93 runtime.mainstart() runtime.goexit /Users/rsc/g/go/src/pkg/runtime/proc.c:178 runtime.goexit() ----- goroutine created by ----- _rt0_386+0xbf /Users/rsc/g/go/src/pkg/runtime/386/asm.s:80 R=iant, r CC=golang-dev https://golang.org/cl/4444073
-
Andrew Gerrand authored
R=brad_danga_com, rsc, dfc, r, dchest, bradfitz CC=golang-dev https://golang.org/cl/4439075
-
- 27 Apr, 2011 13 commits
-
-
Brad Fitzpatrick authored
This one didn't come up in previous greps. R=adg CC=golang-dev https://golang.org/cl/4430071
-
Brad Fitzpatrick authored
This also removes an unnecessary allocation in http/transfer.go R=r, rsc1, r2, adg CC=golang-dev https://golang.org/cl/4426066
-
Brad Fitzpatrick authored
R=rsc CC=golang-dev https://golang.org/cl/4432076
-
Brad Fitzpatrick authored
Fixes #1725 R=rsc CC=golang-dev https://golang.org/cl/4442086
-
Gustavo Niemeyer authored
R=golang-dev, rsc1 CC=golang-dev https://golang.org/cl/4438077
-
Brad Fitzpatrick authored
Add local URI path support, which isn't as fringe as I originally thought. (it's supported by Apache) Send an implicit 302 status on redirects (not 200). Fixes #1597 R=rsc, r CC=golang-dev https://golang.org/cl/4442089
-
Peter Mundy authored
In a GOROOT path a backslash is a path separator not an escape character. For example, `C:\go`. Fixes gotest error: version.go:3: unknown escape sequence: g R=rsc CC=golang-dev https://golang.org/cl/4437076
-
Evan Shaw authored
R=golang-dev, bradfitzgo, bradfitzwork, nigeltao, rog CC=golang-dev https://golang.org/cl/4271078
-
Rob Pike authored
Fixes #1742. I hope. Also this picks up an update to go_tutorial.html that should already have happened. R=brainman, rsc, peterGo CC=golang-dev https://golang.org/cl/4452050
-
Russ Cox authored
R=dsymonds CC=golang-dev https://golang.org/cl/4436060
-
Russ Cox authored
Fixes #1531. R=adg CC=golang-dev https://golang.org/cl/4442088
-
Andrew Gerrand authored
For example, with GOPATH set like so GOPATH=/home/adg/gocode And after creating some subdirectories mkdir /home/adg/gocode/{bin,pkg,src} I can use goinstall to install the github.com/nf/goto web server, which depends on the github.com/nf/stat package, with goinstall github.com/nf/goto This downloads and installs all dependencies (that aren't already installed) like so /home/adg/gocode/bin/goto /home/adg/gocode/pkg/darwin_amd64/github.com/nf/stat.a /home/adg/gocode/src/github.com/nf/goto/... /home/adg/gocode/src/github.com/nf/stat/... R=rsc, niemeyer CC=golang-dev https://golang.org/cl/4438043
-
Andrew Gerrand authored
R=rsc, dfc CC=golang-dev https://golang.org/cl/4452047
-
- 26 Apr, 2011 13 commits
-
-
Rob Pike authored
R=bradfitzgo CC=golang-dev https://golang.org/cl/4442085
-
Rob Pike authored
Can make the API nicer in some cases. R=rsc, rog, r2 CC=golang-dev https://golang.org/cl/4428064
-
Brad Fitzpatrick authored
No bugs found yet, though. R=rsc, bradfitzwork CC=golang-dev https://golang.org/cl/4436058
-
Adam Langley authored
I ran the new verification code against a large number of certificates with a huge (>1000) number of intermediates. I had previously convinced myself that a cycle in the certificate graph implied a cycle in the hash graph (and thus, a contradiction). This is bogus because the signatures don't cover each other. Secondly, I managed to drive the verification into a time explosion with a fully connected graph of certificates. The code would try to walk the factorial number of paths. This change switches the CertPool to dealing with indexes of certificates rather than pointers: this makes equality easy. (I didn't want to compare pointers because a reasonable gc could move objects around over time.) Secondly, verification now memorizes the chains from a given certificate. This is dynamic programming for the lazy, but there's a solid reason behind it: dynamic programming would ignore the Issuer hints that we can exploit by walking up the chain rather than down. R=bradfitzgo CC=golang-dev https://golang.org/cl/4439070
-
Albert Strasheim authored
R=rsc, bradfitzgo CC=golang-dev https://golang.org/cl/4433070
-
Russ Cox authored
Used to fault trying to access l->list->next when l->list == nil after MCentral_AllocList. Now prints runtime: out of memory: no room in arena for 65536-byte allocation (536870912 in use) throw: out of memory followed by stack trace. Fixes #1650. R=r, dfc CC=golang-dev https://golang.org/cl/4446062
-
Alex Brainman authored
R=bradfitzgo, rsc, peterGo CC=golang-dev https://golang.org/cl/4441051
-
Alex Brainman authored
This change will allow to generate valid executable, even if rsc disables dwarf generation, as it happend at revision 9a64273f9d68. R=rsc CC=golang-dev, lvd, vcc https://golang.org/cl/4425066
-
Brad Fitzpatrick authored
Work on issue 155 R=rsc, bradfitzwork CC=golang-dev https://golang.org/cl/4435071
-
Russ Cox authored
Also, 6g was passing uninitialized Node &n2 to regalloc, causing non-deterministic register collisions (but only when both left and right hand side of comparison had function calls). Fixes #1728. R=ken2 CC=golang-dev https://golang.org/cl/4425070
-
Russ Cox authored
It's no longer used. R=adg CC=golang-dev https://golang.org/cl/4426061
-
Russ Cox authored
Will fill dashboard down the screen instead of up when builders get stuck and resume. Already live. Also delete dead benchmark code. I think it is safe to say that if/when we bring benchmarks back, we will use a different data model. Fixes #1228. R=adg CC=golang-dev https://golang.org/cl/4449059
-
Andrew Gerrand authored
This permits the websocket handler to inspect http headers and such. Fixes #1726. R=ukai, bradfitz, bradfitzgo CC=golang-dev https://golang.org/cl/4439069
-
- 25 Apr, 2011 2 commits
-
-
Dave Cheney authored
R=rsc, r CC=golang-dev https://golang.org/cl/4438069
-
Russ Cox authored
Fixes #1680. R=ken2 CC=golang-dev https://golang.org/cl/4446061
-