aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2014-06-13go1.3rc2go1.3rc2Andrew Gerrand
LGTM=minux, rsc R=golang-codereviews, minux, rsc CC=golang-codereviews https://golang.org/cl/105170044
2014-06-12[release-branch.go1.3] runtime: revise CL 105140044 (defer nil) to work on ↵Russ Cox
Windows ««« CL 105120044 / 824ea5943ba8 runtime: revise CL 105140044 (defer nil) to work on Windows It appears that something about Go on Windows cannot handle the fault cause by a jump to address 0. The way Go represents and calls functions, this never happened at all, until CL 105140044. This CL changes the code added in CL 105140044 to make jump to 0 impossible once again. Fixes #8047. (again, on Windows) TBR=bradfitz R=golang-codereviews, dave CC=adg, golang-codereviews, iant, r https://golang.org/cl/105120044 »»» LGTM=bradfitz R=golang-codereviews, bradfitz, alex.brainman CC=adg, golang-codereviews https://golang.org/cl/108890045
2014-06-13revert go1.3rc2Andrew Gerrand
The Windows build is still bad. The previous CL is not go1.3rc2. TBR=bradfitz R=golang-codereviews CC=golang-codereviews https://golang.org/cl/107050043
2014-06-13go1.3rc2Andrew Gerrand
LGTM=iant R=golang-codereviews, iant CC=golang-codereviews https://golang.org/cl/103420043
2014-06-12[release-branch.go1.3] runtime: do not trace past jmpdefer during pprof ↵Russ Cox
traceback on arm ««« CL 107970043 / b336da131a84 runtime: do not trace past jmpdefer during pprof traceback on arm jmpdefer modifies PC, SP, and LR, and not atomically, so walking past jmpdefer will often end up in a state where the three are not a consistent execution snapshot. This was causing warning messages a few frames later when the traceback realized it was confused, but given the right memory it could easily crash instead. Update #8153 LGTM=minux, iant R=golang-codereviews, minux, iant CC=golang-codereviews, r https://golang.org/cl/107970043 »»» LGTM=r R=golang-codereviews, r CC=adg, golang-codereviews, iant https://golang.org/cl/101260043
2014-06-12[release-branch.go1.3] runtime: fix defer of nil funcRuss Cox
««« CL 105140044 / c2832405e9b9 runtime: fix defer of nil func Fixes #8047. LGTM=r, iant R=golang-codereviews, r, iant CC=dvyukov, golang-codereviews, khr https://golang.org/cl/105140044 »»» LGTM=r R=golang-codereviews, r CC=adg, golang-codereviews, iant https://golang.org/cl/103370044
2014-06-12[release-branch.go1.3] doc: link to release history from /doc/Russ Cox
««« CL 107950043 / 593f58ee96da doc: link to release history from /doc/ Fixes #8168. TBR=bradfitz R=golang-codereviews CC=golang-codereviews https://golang.org/cl/107950043 »»» LGTM=r R=golang-codereviews, r CC=adg, golang-codereviews, iant https://golang.org/cl/105910043
2014-06-11[release-branch.go1.3] runtime: add test for issue 8047.Russ Cox
««« CL 108840043 / 3a2306461574 runtime: add test for issue 8047. Make sure stack copier doesn't barf on a nil defer. Bug was fixed in https://golang.org/cl/101800043 This change just adds a test. Fixes #8047 LGTM=dvyukov, rsc R=dvyukov, rsc CC=golang-codereviews https://golang.org/cl/108840043 »»» TBR=adg CC=golang-codereviews https://golang.org/cl/102320043
2014-06-11[release-branch.go1.3] net/http: fix double Content-Length in responseRuss Cox
««« CL 105040043 / ef8878dbed3b net/http: fix double Content-Length in response Fixes #8180 LGTM=rsc R=rsc CC=golang-codereviews https://golang.org/cl/105040043 »»» TBR=bradfitz R=golang-codereviews CC=bradfitz, golang-codereviews, iant https://golang.org/cl/102300046
2014-06-11[release-branch.go1.3] doc/install.html: fix erroneous HTML annotationRuss Cox
««« CL 106910044 / ac907318915d doc/install.html: fix erroneous HTML annotation align=middle is invalid; use align=center LGTM=bradfitz R=golang-codereviews, bradfitz CC=golang-codereviews https://golang.org/cl/106910044 »»» LGTM=r R=golang-codereviews, r CC=bradfitz, golang-codereviews, iant https://golang.org/cl/108860047
2014-06-11[release-branch.go1.3] cmd/gc: two escape analysis fixesRuss Cox
««« CL 108860043 / f153208c0a0e cmd/gc: fix escape analysis for &x inside switch x := v.(type) The analysis for &x was using the loop depth on x set during x's declaration. A type switch creates a list of implicit declarations that were not getting initialized with loop depths. Fixes #8176. LGTM=iant R=iant CC=golang-codereviews https://golang.org/cl/108860043 »»» ««« CL 108870044 / 331dbd4a6334 cmd/gc: fix &result escaping into result There is a hierarchy of location defined by loop depth: -1 = the heap 0 = function results 1 = local variables (and parameters) 2 = local variable declared inside a loop 3 = local variable declared inside a loop inside a loop etc In general if an address from loopdepth n is assigned to something in loop depth m < n, that indicates an extended lifetime of some form that requires a heap allocation. Function results can be local variables too, though, and so they don't actually fit into the hierarchy very well. Treat the address of a function result as level 1 so that if it is written back into a result, the address is treated as escaping. Fixes issue 8185 . LGTM=iant R=iant CC=golang-codereviews https://golang.org/cl/108870044 »»» LGTM=r R=golang-codereviews, r CC=bradfitz, golang-codereviews, iant https://golang.org/cl/107930044
2014-06-11[release-branch.go1.3] cmd/ld: fix PC deltas in DWARF line number tableRuss Cox
««« CL 104950045 / 87daa424d96a cmd/ld: fix PC deltas in DWARF line number table The putpclcdelta function set the DWARF line number PC to s->value + pcline->pc, which is correct, but the code then set the local variable pc to epc, which can be a different value. This caused the next delta in the DWARF table to be wrong. Fixes #8098. LGTM=rsc R=rsc CC=golang-codereviews https://golang.org/cl/104950045 »»» LGTM=r R=golang-codereviews, r CC=bradfitz, golang-codereviews, iant https://golang.org/cl/107900045
2014-06-11[release-branch.go1.3] nacltest.bash, misc/nacl/README: update NaCl docs.Russ Cox
««« CL 105030043 / 6146799f32ed nacltest.bash, misc/nacl/README: update NaCl docs. LGTM=rsc R=dave, rsc CC=golang-codereviews https://golang.org/cl/105030043 »»» LGTM=r R=golang-codereviews, r CC=bradfitz, golang-codereviews, iant https://golang.org/cl/105020044
2014-06-11[release-branch.go1.3] docs: link to the assembler document from the ↵Russ Cox
Documents tab ««« CL 108840045 / 087e446f2c41 docs: link to the assembler document from the Documents tab Fixes #8156. LGTM=bradfitz R=golang-codereviews, bradfitz CC=golang-codereviews https://golang.org/cl/108840045 »»» LGTM=r R=golang-codereviews, r CC=bradfitz, golang-codereviews, iant https://golang.org/cl/101170045
2014-06-06[release-branch.go1.3] runtime: fix panic stack during runtime.Goexit during ↵Russ Cox
panic ««« CL 102220043 / 00224712f89e runtime: fix panic stack during runtime.Goexit during panic A runtime.Goexit during a panic-invoked deferred call left the panic stack intact even though all the stack frames are gone when the goroutine is torn down. The next goroutine to reuse that struct will have a bogus panic stack and can cause the traceback routines to walk into garbage. Most likely to happen during tests, because t.Fatal might be called during a deferred func and uses runtime.Goexit. This "not enough cleared in Goexit" failure mode has happened to us multiple times now. Clear all the pointers that don't make sense to keep, not just gp->panic. Fixes #8158. LGTM=iant, dvyukov R=iant, dvyukov CC=golang-codereviews https://golang.org/cl/102220043 »»» LGTM=iant R=golang-codereviews, iant CC=golang-codereviews, r https://golang.org/cl/108780044
2014-06-06[release-branch.go1.3] cmd/6g: fix stack zeroing on native clientRuss Cox
««« CL 108740047 / c8e9255aed3f cmd/6g: fix stack zeroing on native client I am not sure what the rounding here was trying to do, but it was skipping the first pointer on native client. The code above the rounding already checks that xoffset is widthptr-aligned, so the rnd was a no-op everywhere but on Native Client. And on Native Client it was wrong. Perhaps it was supposed to be rounding down, not up, but zerorange handles the extra 32 bits correctly, so the rnd does not seem to be necessary at all. This wouldn't be worth doing for Go 1.3 except that it can affect code on the playground. Fixes #8155. LGTM=r, iant R=golang-codereviews, r, iant CC=dvyukov, golang-codereviews, khr https://golang.org/cl/108740047 »»» LGTM=iant R=golang-codereviews, iant CC=golang-codereviews, r https://golang.org/cl/107830044
2014-06-06[release-branch.go1.3] doc: fix happens-before rules for buffered channelsRuss Cox
««« CL 101980047 / 12c9a9ff50d8 doc: fix happens-before rules for buffered channels The current wording is reversed in 2 places. Not sure how it got 4 LGTMs (mine was there as well). Update #6242. LGTM=dan.kortschak, r, rsc R=golang-codereviews, 0xjnml, dan.kortschak, r, rsc CC=golang-codereviews https://golang.org/cl/101980047 »»» LGTM=iant R=golang-codereviews, iant CC=golang-codereviews, r https://golang.org/cl/106830047
2014-06-06[release-branch.go1.3] cmd/cgo: for typedef of untagged struct, use typedef ↵Russ Cox
name in C code ««« CL 103080043 / 5e058e21b67d cmd/cgo: for typedef of untagged struct, use typedef name in C code Fixes #8148. LGTM=cookieo9, rsc R=rsc, cookieo9 CC=golang-codereviews https://golang.org/cl/103080043 »»» LGTM=iant R=golang-codereviews, iant CC=golang-codereviews, r https://golang.org/cl/103900046
2014-06-04[release-branch.go1.3] doc/install-source.html: document that GO386 will be ↵Shenghou Ma
auto-detected when building on both 386 and amd64. ««« CL 102150046 / ccf7893cc2f0 doc/install-source.html: document that GO386 will be auto-detected when building on both 386 and amd64. Fixes #8152. LGTM=iant R=iant CC=golang-codereviews https://golang.org/cl/102150046 »»» LGTM=iant R=golang-codereviews, iant CC=golang-codereviews https://golang.org/cl/105830044
2014-06-04[release-branch.go1.3] debug/elf: support DWARF that needs relocs for 386David Symonds
««« CL 96680045 / 5439c77d4acb debug/elf: support DWARF that needs relocs for 386 It's not clear how widespread this issue is, but we do have a test case generated by a development version of clang. I don't know whether this should go into 1.3 or not; happy to hear arguments either way. LGTM=rsc R=golang-codereviews, bradfitz, rsc CC=golang-codereviews https://golang.org/cl/96680045 »»» LGTM=rsc R=rsc CC=golang-codereviews https://golang.org/cl/102140043
2014-06-04[release-branch.go1.3] compress/gzip: allow Reset on Reader without NewReaderDavid Symonds
««« CL 103020044 / 318b56ffe04b compress/gzip: allow Reset on Reader without NewReader Fixes #8126. LGTM=bradfitz R=golang-codereviews, bradfitz CC=golang-codereviews https://golang.org/cl/103020044 »»» TBR=rsc R=rsc CC=golang-codereviews https://golang.org/cl/105820043
2014-06-03[release-branch.go1.3] crypto/tls: fix typo referencing the required Config ↵Russ Cox
field ««« CL 107740043 / d86ec79a5f30 crypto/tls: fix typo referencing the required Config field Thanks to Frithjof Schulze for noticing. LGTM=adg R=adg CC=agl, golang-codereviews, r https://golang.org/cl/107740043 »»» LGTM=r R=golang-codereviews, r CC=bradfitz, golang-codereviews, iant https://golang.org/cl/103020043
2014-06-03[release-branch.go1.3] cmd/gc: fix escape analysis of func returning ↵Russ Cox
indirect of parameter ««« CL 102040046 / a078b2056ebc cmd/gc: fix escape analysis of func returning indirect of parameter I introduced this bug when I changed the escape analysis to run in phases based on call graph dependency order, in order to be more precise about inputs escaping back to outputs (functions returning their arguments). Given func f(z **int) *int { return *z } we were tagging the function as 'z does not escape and is not returned', which is all true, but not enough information. If used as: var x int p := &x q := &p leak(f(q)) then the compiler might try to keep x, p, and q all on the stack, since (according to the recorded information) nothing interesting ends up being passed to leak. In fact since f returns *q = p, &x is passed to leak and x needs to be heap allocated. To trigger the bug, you need a chain that the compiler wants to keep on the stack (like x, p, q above), and you need a function that returns an indirect of its argument, and you need to pass the head of the chain to that function. This doesn't come up very often: this bug has been present since June 2012 (between Go 1 and Go 1.1) and we haven't seen it until now. It helps that most functions that return indirects are getters that are simple enough to be inlined, avoiding the bug. Earlier versions of Go also had the benefit that if &x really wasn't used beyond x's lifetime, nothing broke if you put &x in a heap-allocated structure accidentally. With the new stack copying, though, heap-allocated structures containing &x are not updated when the stack is copied and x moves, leading to crashes in Go 1.3 that were not crashes in Go 1.2 or Go 1.1. The fix is in two parts. First, in the analysis of a function, recognize when a value obtained via indirect of a parameter ends up being returned. Mark those parameters as having content escape back to the return results (but we don't bother to write down which result). Second, when using the analysis to analyze, say, f(q), mark parameters with content escaping as having any indirections escape to the heap. (We don't bother trying to match the content to the return value.) The fix could be less precise (simpler). In the first part we might mark all content-escaping parameters as plain escaping, and then the second part could be dropped. Or we might assume that when calling f(q) all the things pointed at by q escape always (for any f and q). The fix could also be more precise (more complex). We might record the specific mapping from parameter to result along with the number of indirects from the parameter to the thing being returned as the result, and then at the call sites we could set up exactly the right graph for the called function. That would make notleaks(f(q)) be able to keep x on the stack, because the reuslt of f(q) isn't passed to anything that leaks it. The less precise the fix, the more stack allocations become heap allocations. This fix is exactly as precise as it needs to be so that none of the current stack allocations in the standard library turn into heap allocations. Fixes #8120. LGTM=iant R=golang-codereviews, iant CC=golang-codereviews, khr, r https://golang.org/cl/102040046 »»» LGTM=iant R=golang-codereviews, iant CC=golang-codereviews https://golang.org/cl/103870043
2014-06-03[release-branch.go1.3] time: support version 3 zone recordsDavid Symonds
««« CL 100930044 / fde405c62fca time: support version 3 zone records Fixes #8134 LGTM=iant R=golang-codereviews, iant CC=golang-codereviews, r, rsc https://golang.org/cl/100930044 »»» LGTM=rsc R=adg, rsc CC=golang-codereviews https://golang.org/cl/96690043
2014-06-03[release-branch.go1.3] cmd/gc: fix liveness for address-taken variables in ↵David Symonds
inlined functions ««« CL 96670046 / 1bec455e95f1 cmd/gc: fix liveness for address-taken variables in inlined functions The 'address taken' bit in a function variable was not propagating into the inlined copies, causing incorrect liveness information. LGTM=dsymonds, bradfitz R=golang-codereviews, bradfitz CC=dsymonds, golang-codereviews, iant, khr, r https://golang.org/cl/96670046 »»» TBR=adg R=adg CC=golang-codereviews https://golang.org/cl/103810046
2014-06-03[release-branch.go1.3] runtime: fix 1-byte return during x.(T) for 0-byte TDavid Symonds
««« CL 100940043 / 93baf7bea171 runtime: fix 1-byte return during x.(T) for 0-byte T The 1-byte write was silently clearing a byte on the stack. If there was another function call with more arguments in the same stack frame, no harm done. Otherwise, if the variable at that location was already zero, no harm done. Otherwise, problems. Fixes #8139. LGTM=dsymonds R=golang-codereviews, dsymonds CC=golang-codereviews, iant, r https://golang.org/cl/100940043 »»» TBR=adg CC=golang-codereviews https://golang.org/cl/105760045
2014-06-03[release-branch.go1.3] cmd/gc: don't generate zillions of linehists for ↵David Symonds
wrapper functions ««« CL 104840043 / 876107512a67 cmd/gc: don't generate zillions of linehists for wrapper functions This is a workaround - the code should be better than this - but the fix avoids generating large numbers of linehist entries for the wrapper functions that enable interface conversions. There can be many of them, they all happen at the end of compilation, and they can all share a linehist entry. Avoids bad n^2 behavior in liblink. Test case in issue 8135 goes from 64 seconds to 2.5 seconds (still bad but not intolerable). Fixes #8135. LGTM=rsc R=rsc CC=golang-codereviews https://golang.org/cl/104840043 »»» TBR=adg CC=golang-codereviews https://golang.org/cl/102070045
2014-06-03[release-branch.go1.3] cmd/cgo: use same Go type for typedef to anonymous structDavid Symonds
««« CL 102080043 / 256d975c53cb cmd/cgo: use same Go type for typedef to anonymous struct If we see a typedef to an anonymous struct more than once, presumably in two different Go files that import "C", use the same Go type name. Fixes #8133. LGTM=rsc R=rsc CC=golang-codereviews https://golang.org/cl/102080043 »»» TBR=adg CC=golang-codereviews https://golang.org/cl/102100043
2014-06-03[release-branch.go1.3] doc: mention WriteHeapDump in 1.3 release notesDavid Symonds
««« CL 103810044 / 603f6c3b152c doc: mention WriteHeapDump in 1.3 release notes LGTM=r R=khr, r CC=golang-codereviews https://golang.org/cl/103810044 »»» TBR=adg R=adg CC=golang-codereviews https://golang.org/cl/99700043
2014-06-02go1.3rc1go1.3rc1Andrew Gerrand
LGTM=minux R=golang-codereviews, minux CC=golang-codereviews https://golang.org/cl/102920050
2014-06-02[release-branch.go1.3] misc/nacl: remove cmd/link from testzip.protoAndrew Gerrand
There's no cmd/link in this branch. LGTM=bradfitz R=golang-codereviews, bradfitz CC=golang-codereviews https://golang.org/cl/102050043
2014-06-02[release-branch.go1.3] remove package debug/goobj and copy functionality to ↵Andrew Gerrand
cmd/nm https://golang.org/cl/103760043/
2014-06-02[release-branch.go1.3] remove cmd/linkAndrew Gerrand
https://golang.org/cl/106740043
2014-06-01doc/contrib.html: update links, mailing lists and link to 1.3 release note.Shenghou Ma
LGTM=adg R=golang-codereviews, r, adg CC=golang-codereviews https://golang.org/cl/102020045
2014-06-02misc/makerelease: report uploads to the new downloads pageAndrew Gerrand
LGTM=bradfitz R=golang-codereviews, bradfitz CC=golang-codereviews https://golang.org/cl/102040047
2014-06-02api: add go1.3.txtBrad Fitzpatrick
Update #8112 LGTM=adg R=adg CC=golang-codereviews https://golang.org/cl/104790045
2014-06-01build: don't build goplay in run.rc.Shenghou Ma
Fix plan 9 build. TBR=rsc R=golang-codereviews CC=golang-codereviews https://golang.org/cl/100880047
2014-06-01cmd/objdump: add arm disassemblerRuss Cox
Fixes #7452. LGTM=minux, iant R=minux, iant CC=golang-codereviews https://golang.org/cl/104770046
2014-06-02cmd/dist: only use beta tag in version string for the exact revisionAndrew Gerrand
Right now, any revision on the default branch after go1.3beta2 is described by "go verson" as go1.3beta2 plus some revision. That's OK for now, but once go1.3 is released, that will seem wrong. LGTM=rsc R=rsc CC=golang-codereviews https://golang.org/cl/98650046
2014-06-02build: remove goplay from run.bash and run.batAndrew Gerrand
TBR=rsc R=golang-codereviews CC=golang-codereviews https://golang.org/cl/106730043
2014-06-02misc/goplay: remove programAndrew Gerrand
This program has barely been touched since it was first committed, and in its current state it opens a code execution vector similar to the one that was recently fixed in go.tools/playground/socket. Rather than try to make it secure, remove it. LGTM=minux, rsc R=rsc, minux CC=golang-codereviews https://golang.org/cl/102030047
2014-06-01runtime: fix correctness test at end of tracebackRuss Cox
We were requiring that the defer stack and the panic stack be completely processed, thinking that if any were left over the stack scan and the defer stack/panic stack must be out of sync. It turns out that the panic stack may well have leftover entries in some situations, and that's okay. Fixes #8132. LGTM=minux, r R=golang-codereviews, minux, r CC=golang-codereviews, iant, khr https://golang.org/cl/100900044
2014-06-01lib/timezone: update to IANA 2014dRob Pike
LGTM=bradfitz R=golang-codereviews, bradfitz CC=golang-codereviews https://golang.org/cl/102040045
2014-05-31runtime: mark some C globals as having no pointers.Keith Randall
C globals are conservatively scanned. This helps avoid false retention, especially for 32 bit. LGTM=rsc R=golang-codereviews, khr, rsc CC=golang-codereviews https://golang.org/cl/102040043
2014-05-31runtime: make continuation pc available to stack walkRuss Cox
The 'continuation pc' is where the frame will continue execution, if anywhere. For a frame that stopped execution due to a CALL instruction, the continuation pc is immediately after the CALL. But for a frame that stopped execution due to a fault, the continuation pc is the pc after the most recent CALL to deferproc in that frame, or else 0. That is where execution will continue, if anywhere. The liveness information is only recorded for CALL instructions. This change makes sure that we never look for liveness information except for CALL instructions. Using a valid PC fixes crashes when a garbage collection or stack copying tries to process a stack frame that has faulted. Record continuation pc in heapdump (format change). Fixes #8048. LGTM=iant, khr R=khr, iant, dvyukov CC=golang-codereviews, r https://golang.org/cl/100870044
2014-05-31cmd/gc: fix handling of for post-condition in -race modeRuss Cox
Fixes #8102. LGTM=bradfitz, dvyukov R=golang-codereviews, bradfitz, dvyukov CC=golang-codereviews https://golang.org/cl/100870046
2014-05-31runtime: fix error check in freebsd/386 i386_set_ldtRuss Cox
Update #2675 The code here was using the error check for Linux/386, not the one for FreeBSD/386. Most of the time it worked. Thanks to Neel Natu (FreeBSD developer) for finding this. The s/JCC/JAE/ a few lines later is a no-op but makes the test match the rest of the file. Why we write JAE instead of JCC I don't know, but the two are equivalent and the file might as well be consistent. LGTM=bradfitz, minux R=golang-codereviews, bradfitz, minux CC=golang-codereviews https://golang.org/cl/99680044
2014-05-31runtime/debug: skip TestWriteHeapDumpNonempty on NaCl.Shenghou Ma
TestWriteHeap is useless on NaCl anyway. LGTM=bradfitz R=golang-codereviews, bradfitz CC=golang-codereviews https://golang.org/cl/101980048
2014-05-31C: add another email of mine.Shenghou Ma
LGTM=bradfitz R=golang-codereviews, bradfitz CC=golang-codereviews https://golang.org/cl/102920047
2014-05-31runtime: fix empty heap dump bug on windows.Shenghou Ma
Fixes #8119. LGTM=khr, rsc R=alex.brainman, khr, bradfitz, rsc CC=golang-codereviews https://golang.org/cl/93640044
7apu2bq3rhoylwmucxizk54afw5jyda7pho4j5zdcqpwkufke7zdzwad.onion