- 08 Jan, 2016 6 commits
-
-
Brad Fitzpatrick authored
As Andy Balholm noted in #11207: "RFC2616 §4.2 says that a header's field-content can consist of *TEXT, and RFC2616 §2.2 says that TEXT is <any OCTET except CTLs, but including LWS>, so that would mean that bytes greater than 128 are allowed." This is a partial rollback of the strictness from https://golang.org/cl/11207 (added in the Go 1.6 dev cycle, only released in Go 1.6beta1) Fixes #11207 Change-Id: I3a752a7941de100e4803ff16a5d626d5cfec4f03 Reviewed-on: https://go-review.googlesource.com/18374Reviewed-by: Russ Cox <rsc@golang.org> Reviewed-by: Andrew Gerrand <adg@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
-
Robert Griesemer authored
Fixes #13742. Change-Id: I7c8b51b60e31402bf708bf8d70e07fd06295e8ce Reviewed-on: https://go-review.googlesource.com/18393Reviewed-by: Russ Cox <rsc@golang.org>
-
Ian Lance Taylor authored
It's fairly common to call cgo functions with conversions to unsafe.Pointer or other C types. Apply the simpler checking of address expressions when possible when the address expression occurs within a type conversion. Change-Id: I5187d4eb4d27a6542621c396cad9ee4b8647d1cd Reviewed-on: https://go-review.googlesource.com/18391 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
-
Russ Cox authored
Go 1.5 and earlier said "day out of range". As part of working on this code it morphed into "day of month out of range". To avoid churn in the output restore the old text. This fixes some tests reported privately. Change-Id: If179676cd49f9a471a9441fec2f5220c85eb0799 Reviewed-on: https://go-review.googlesource.com/18386Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Russ Cox authored
Fixes #13564. Change-Id: I30c827ef4a112fee21b8493a67d0227109e35072 Reviewed-on: https://go-review.googlesource.com/18384Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Brad Fitzpatrick authored
Document the three GODEBUG environment variables in the package doc. Updates the bundled http2 to x/net git rev 415f1917 for https://golang.org/cl/18372. Fixes #13611 Change-Id: I3116c5d7de70d3d15242d7198f3758b1fb7d94b9 Reviewed-on: https://go-review.googlesource.com/18373Reviewed-by: Andrew Gerrand <adg@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
- 07 Jan, 2016 21 commits
-
-
Brad Fitzpatrick authored
I thought there was still work to do in http2 for this, but I guess not: the work for parsing them is in net/url (used by http2) and the handling of OPTIONS * is already in net/http serverHandler, also used by http2. But keep the tests. Change-Id: I566dd0a03cf13c9ea8e735c6bd32d2c521ed503b Reviewed-on: https://go-review.googlesource.com/18368Reviewed-by: Blake Mizerany <blake.mizerany@gmail.com> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
-
Matthew Dempsky authored
Adding the evconst(n) call for OANDAND and OOROR in golang.org/cl/18262 was originally just to parallel the above iscmp branch, but upon further inspection it seemed odd that removing it caused test/fixedbugs/issue6671.go's var b mybool // ... b = bool(true) && true // ERROR "cannot use" to start failing (i.e., by not emitting the expected "cannot use" error). The problem is that evconst(n)'s settrue and setfalse paths always reset n.Type to idealbool, even for logical operators where n.Type should preserve the operand type. Adding the evconst(n) call for OANDAND/OOROR inadvertantly worked around this by turning the later evconst(n) call at line 2167 into a noop, so the "n.Type = t" assignment at line 739 would preserve the operand type. However, that means evconst(n) was still clobbering n.Type for ONOT, so declarations like: const _ bool = !mybool(true) were erroneously accepted. Update #13821. Change-Id: I18e37287f05398fdaeecc0f0d23984e244f025da Reviewed-on: https://go-review.googlesource.com/18362 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
-
Austin Clements authored
f90b48e0 intended to require the stack barrier lock in all cases of sigprof that walked the user stack, but got it wrong. In particular, if sp < gp.stack.lo || gp.stack.hi < sp, tracebackUser would be true, but we wouldn't acquire the stack lock. If it then turned out that we were in a cgo call, it would walk the stack without the lock. In fact, the whole structure of stack locking is sigprof is somewhat wrong because it assumes the G to lock is gp.m.curg, but all three gentraceback calls start from potentially different Gs. To fix this, we lower the gcTryLockStackBarriers calls much closer to the gentraceback calls. There are now three separate trylock calls, each clearly associated with a gentraceback and the locked G clearly matches the G from which the gentraceback starts. This actually brings the sigprof logic closer to what it originally was before stack barrier locking. This depends on "runtime: increase assumed stack size in externalthreadhandler" because it very slightly increases the stack used by sigprof; without this other commit, this is enough to blow the profiler thread's assumed stack size. Fixes #12528 (hopefully for real this time!). For the 1.5 branch, though it will require some backporting. On the 1.5 branch, this will *not* require the "runtime: increase assumed stack size in externalthreadhandler" commit: there's no pcvalue cache, so the used stack is smaller. Change-Id: Id2f6446ac276848f6fc158bee550cccd03186b83 Reviewed-on: https://go-review.googlesource.com/18328 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
-
Austin Clements authored
On Windows, externalthreadhandler currently sets the assumed stack size for the profiler thread and the ctrlhandler threads to 8KB. The actual stack size is determined by the SizeOfStackReserve field in the binary set by the linker, which is currently at least 64KB (and typically 128KB). It turns out the profiler thread is running within a few words of the 8KB-(stack guard) bound set by externalthreadhandler. If it overflows this bound, morestack crashes unceremoniously with an access violation, which we then fail to handle, causing the whole process to exit without explanation. To avoid this problem and give us some breathing room, increase the assumed stack size in externalthreadhandler to 32KB (there's some unknown amount of stack already in use, so it's not safe to increase this all the way to the reserve size). We also document the relationships between externalthreadhandler and SizeOfStackReserve to make this more obvious in the future. Change-Id: I2f9f9c0892076d78e09827022ff0f2bedd9680a9 Reviewed-on: https://go-review.googlesource.com/18304 Run-TryBot: Austin Clements <austin@google.com> Reviewed-by: Alex Brainman <alex.brainman@gmail.com> Reviewed-by: Minux Ma <minux@golang.org>
-
Austin Clements authored
If a sigprof happens during a cgo call, we traceback from the entry point of the cgo call. However, if the SP is outside of the G's stack, we'll then ignore this traceback, even if it was successful, and overwrite it with just _ExternalCode. Fix this by accepting any successful traceback, regardless of whether we got it from a cgo entry point or from regular Go code. Fixes #13466. Change-Id: I5da9684361fc5964f44985d74a8cdf02ffefd213 Reviewed-on: https://go-review.googlesource.com/18327 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
-
Russ Cox authored
Change-Id: Ideb4bd9ffb1b5f1aef7d94ff791a262f54a650d5 Reviewed-on: https://go-review.googlesource.com/18344Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Russ Cox authored
net has GODEBUG text already. net/http still needs it (leaving for Brad). For #13611. Change-Id: Icea1027924a23a687cbbe4001985e8c6384629d7 Reviewed-on: https://go-review.googlesource.com/18346Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Brad Fitzpatrick authored
Updates http2 to x/net git rev 520af5de654d for https://golang.org/cl/18370 Fixes #13659 Change-Id: I920eaff6036ac22c500a97449826c6b12f873d7f Reviewed-on: https://go-review.googlesource.com/18371 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Andrew Gerrand <adg@golang.org>
-
Michael McGreevy authored
Change-Id: I995ac0559f89110662d79d136d710ef3a0bb1505 Reviewed-on: https://go-review.googlesource.com/18351Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Russ Cox authored
Fixes #13731. Change-Id: Iaf70a8b41c947f0d86013808564112ab676136e3 Reviewed-on: https://go-review.googlesource.com/18345Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
-
Michael Hudson-Doyle authored
Fixes #13358 Change-Id: I57ed50c2610cab11fb3d9749f9e7d4a37daa7977 Reviewed-on: https://go-review.googlesource.com/18276Reviewed-by: Russ Cox <rsc@golang.org>
-
Russ Cox authored
Now there are ARM downloads too. Change-Id: I236381508c69d56748e672d184b92caa715e81ae Reviewed-on: https://go-review.googlesource.com/18342Reviewed-by: Andrew Gerrand <adg@golang.org>
-
Brad Fitzpatrick authored
Update bundled http2 to git rev d1ba260648 (https://golang.org/cl/18288). Fixes the flaky TestTransportAndServerSharedBodyRace_h2. Also adds some debugging to TestTransportAndServerSharedBodyRace_h2 which I hope won't ever be necessary again, but I know will be. Fixes #13556 Change-Id: Ibcf2fc23ec0122dcac8891fdc3bd7f8acddd880e Reviewed-on: https://go-review.googlesource.com/18289Reviewed-by: Andrew Gerrand <adg@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Andrew Gerrand authored
Fixes golang/go#12490 Change-Id: I0861e62aaa589fc63217c83e9c227c17e35cda75 Reviewed-on: https://go-review.googlesource.com/18277Reviewed-by: Russ Cox <rsc@golang.org>
-
Ian Lance Taylor authored
After a failure on the build dashboard I tested testcarchive test 2 and found that it failed an average of 1 in 475 runs on my laptop. With this change it ran over 50,000 times without failing. I bumped up the other iteration limits to correspond. Change-Id: I0155c68161a2c2a09ae25c91e9269f1e8702628d Reviewed-on: https://go-review.googlesource.com/18309 Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Tamir Duberstein authored
Simply checking the exit code of `git rev-parse --git-dir` should suffice here, but that requires deviating from the infrastructure provided by `run`, so I've left that for a future change. Originally by Tamir Duberstein but updated by iant & rsc to add the filepath.Join logic. Fixes #11211 (again). Change-Id: I6d29b5ae39ba456088ae1fb5d41014cb91c86897 Reviewed-on: https://go-review.googlesource.com/18323Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Russ Cox authored
The flag is already named -insecure. Make it more so. If we're willing to accept HTTP, it's not much worse to accept HTTPS man-in-the-middle attacks too. This allows servers with self-signed certificates to work. Fixes #13197. Change-Id: Ia5491410bc886da0a26ef3bce4bf7d732f5e19e4 Reviewed-on: https://go-review.googlesource.com/18324Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Mikio Hara authored
Change-Id: Idf02428591f61dc58f654fdaf0e3a55f8b8a1060 Reviewed-on: https://go-review.googlesource.com/18350Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Russ Cox authored
Read zip files that contain only 64-bit header offset, not 64-bit sizes. Fixes #13367. Read zip files that contain completely unexpected Extra fields, provided we do not need to find 64-bit size or header offset information there. Fixes #13166. Write zip file entries with 0xFFFFFFFF uncompressed data bytes correctly (must use zip64 header, since that's the magic indicator). Fixes new TestZip64EdgeCase. (Noticed while working on the CL.) Change-Id: I84a22b3995fafab8052b99de8094a9f35a25de5b Reviewed-on: https://go-review.googlesource.com/18317Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Russ Cox authored
Fixes #13673. Change-Id: I60d1603ca0dfd2ae136117e0f89cee4b6fc6c3d3 Reviewed-on: https://go-review.googlesource.com/18332Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Russ Cox authored
Fixes #13720. Change-Id: I2e48454696f37db419370630f913590c435cd9f0 Reviewed-on: https://go-review.googlesource.com/18331Reviewed-by: Ian Lance Taylor <iant@golang.org> Run-TryBot: Russ Cox <rsc@golang.org>
-
- 06 Jan, 2016 13 commits
-
-
Ian Lance Taylor authored
Fixes #13845. Change-Id: Ie83179b2d20c47a0296645d9e2fdc43271be495a Reviewed-on: https://go-review.googlesource.com/18307Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Ian Lance Taylor authored
We were setting the signal mask of a new m to the signal mask of the m that created it. That failed when that m happened to be the one created by ensureSigM, which sets its signal mask to only include the signals being caught by os/signal.Notify. Fixes #13164. Update #9896. Change-Id: I705c196fe9d11754e10bab9e9b2e7530ecdfa367 Reviewed-on: https://go-review.googlesource.com/18064Reviewed-by: Russ Cox <rsc@golang.org>
-
Ian Lance Taylor authored
When calling a Go function on a C thread, if the C thread already has an alternate signal stack, use that signal stack instead of installing a new one. Update #9896. Change-Id: I62aa3a6a4a1dc4040fca050757299c8e6736987c Reviewed-on: https://go-review.googlesource.com/18108Reviewed-by: Russ Cox <rsc@golang.org>
-
Brad Fitzpatrick authored
Just saw a few dragonfly failures here. I'm tempted to preemptively add plan9 here too, but I'll wait until I see it fail. Change-Id: Ic99fc088dbfd1aa21f509148aee98ccfe7f640bf Reviewed-on: https://go-review.googlesource.com/18306Reviewed-by: Russ Cox <rsc@golang.org>
-
Russ Cox authored
Fixes #12790. Change-Id: I0f231d198c76632c23692fc1337b57cfeafaf4c7 Reviewed-on: https://go-review.googlesource.com/18338Reviewed-by: Andrew Gerrand <adg@golang.org>
-
Russ Cox authored
Fixes #13269. Change-Id: I960d1825bda9d8873c2a9005872c45e4c7d30111 Reviewed-on: https://go-review.googlesource.com/18339Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Russ Cox authored
Fixes #12059. Change-Id: Ib5caf8133cd3ed888f9102dfbfeca11c506f3b5b Reviewed-on: https://go-review.googlesource.com/18337Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Russ Cox authored
This time with a test. Also adjust another test to skip when hg is not present, and delete no longer needed fixDetachedHead code. Fixes #9032 (again). Change-Id: I481717409e1d44b524f83c70a8dc377699d1a2a5 Reviewed-on: https://go-review.googlesource.com/18334Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Russ Cox authored
Fixes #12542. Change-Id: Icd0fa84d891d6b1feab9b4d4dd319cdf1e6d6c48 Reviewed-on: https://go-review.googlesource.com/18336Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Russ Cox authored
But also cache the previous parsed form and don't reread if the size and modification time are both unchanged from before. On systems with stable /etc/hosts this should result in more stat calls but only a single parsing of /etc/hosts. On systems with variable /etc/hosts files (like some Docker systems) this should result in quicker adoption of changes. Fixes #13340. Change-Id: Iba93b204be73d6d903cd17c58038a4fcfd0952b9 Reviewed-on: https://go-review.googlesource.com/18258Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Brad Fitzpatrick authored
Add a couple more cases where we convert random network I/O errors into errRequestCanceled if the request was forcefully aborted. It failed ~1/1000 times without -race, or very easily with -race. (due to -race randomizing some scheduling) Fixes #11894 Change-Id: Ib1c123ce1eebdd88642da28a5948ca4f30581907 Reviewed-on: https://go-review.googlesource.com/18287Reviewed-by: Russ Cox <rsc@golang.org>
-
Brad Fitzpatrick authored
This shouldn't need to exist in general, but in practice I want something like this a few times per year. Change-Id: I9c220e58be44b7726f75d776f714212c570cf8bb Reviewed-on: https://go-review.googlesource.com/18286Reviewed-by: Russ Cox <rsc@golang.org>
-
Russ Cox authored
The old link died; replace with an archive.org copy. Fixes #13345. Change-Id: Ic4a7fdcf258e1ff3b4a02ecb4f237ae7db2686c7 Reviewed-on: https://go-review.googlesource.com/18335Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-