- 29 Nov, 2016 11 commits
-
-
Dhananjay Nakrani authored
Also refactor common position filling code into a function. Fixes #18011 Change-Id: I76528626da67a7309193fa92af1e361c8e2fcf84 Reviewed-on: https://go-review.googlesource.com/33631 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Hana Kim authored
Skip lines if they are empty or starting with "#" which are valid legacy pprof output format. Fixes #18025 Change-Id: I7aee439171496932637b8ae3188700911f569b16 Reviewed-on: https://go-review.googlesource.com/33454Reviewed-by: Peter Weinberger <pjw@google.com>
-
Michal Bohuslávek authored
Change-Id: I89f276b32015882437e128814573343a4ca53569 Reviewed-on: https://go-review.googlesource.com/33615Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Robert Griesemer authored
Fixes #18092. Change-Id: I54e2da2e0f168c068f5e4a1b22ba508d78259168 Reviewed-on: https://go-review.googlesource.com/33658 TryBot-Result: Gobot Gobot <gobot@golang.org> Run-TryBot: Robert Griesemer <gri@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
-
Austin Clements authored
Android's libc doesn't provide access to auxv, so currently the Go runtime synthesizes a fake, minimal auxv when loaded as a library on Android. This used to be sufficient, but now we depend on auxv to retrieve the system physical page size and panic if we can't retrieve it. Fix this by falling back to reading auxv from /proc/self/auxv if the loader-provided auxv is empty and removing the synthetic auxv vectors. Fixes #18041. Change-Id: Ia2ec2c764a6609331494a5d359032c56cbb83482 Reviewed-on: https://go-review.googlesource.com/33652 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Crawshaw <crawshaw@golang.org>
-
Austin Clements authored
This refactoring is in preparation for handling auxv differently in Android shared libraries. Updates #18041. Change-Id: If0458a309f9c804e7abd0a58b5a224d89f8da257 Reviewed-on: https://go-review.googlesource.com/33651 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Crawshaw <crawshaw@golang.org>
-
Brad Fitzpatrick authored
TBR=See https://golang.org/cl/33244 Updates #17929 Change-Id: I648df63aeb67aa2229c7b4fc23676a78b31140a0 Reviewed-on: https://go-review.googlesource.com/33657Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Brad Fitzpatrick authored
Address Russ's feedback from https://golang.org/cl/33244 TBR=See https://golang.org/cl/33244 Updates #17929 Change-Id: I708d71f519f6414ecec629d3c273d9e737d8ed50 Reviewed-on: https://go-review.googlesource.com/33656Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Ian Lance Taylor authored
Tested by running GOTRACEBACK=2 CGO_CFLAGS="-Wa,--elf-stt-common=yes" go test -ldflags=-linkmode=internal in misc/cgo/test. That failed before this CL, succeeded after. I don't think it's worth doing that as a regular test, though, especially since only recent versions of the GNU binutils support the --elf-stt-common option. Fixes #18088. Change-Id: I893d86181faee217b1504c054b0ed3f7c8d977d3 Reviewed-on: https://go-review.googlesource.com/33653 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Russ Cox authored
Go 1.5 worked with Unicode console input but not ^Z. Go 1.6 did not work with Unicode console input but did handle one ^Z case. Go 1.7 did not work with Unicode console input but did handle one ^Z case. The intent of this CL is for Go 1.8 to work with Unicode console input and also handle all ^Z cases. Here's a simple test program for reading from the console. It prints a "> " prompt, calls read, prints what it gets, and repeats. package main import ( "fmt" "os" ) func main() { p := make([]byte, 100) fmt.Printf("> ") for { n, err := os.Stdin.Read(p) fmt.Printf("[%d %q %v]\n> ", n, p[:n], err) } } On Unix, typing a ^D produces a break in the input stream. If the ^D is at the beginning of a line, then the 0 bytes returned appear as an io.EOF: $ go run /tmp/x.go > hello [6 "hello\n" <nil>] > hello^D[5 "hello" <nil>] > ^D[0 "" EOF] > ^D[0 "" EOF] > hello^Dworld [5 "hello" <nil>] > [6 "world\n" <nil>] > On Windows, the EOF character is ^Z, not ^D, and there has been a long-standing problem that in Go programs, ^Z on Windows does not behave in the expected way, namely like ^D on Unix. Instead, the ^Z come through as literal ^Z characters: C:\>c:\go1.5.4\bin\go run x.go > ^Z [3 "\x1a\r\n" <nil>] > hello^Zworld [13 "hello\x1aworld\r\n" <nil>] > CL 4310 attempted to fix this bug, then known as #6303, by changing the use of ReadConsole to ReadFile. This CL was released as part of Go 1.6 and did fix the case of a ^Z by itself, but not as part of a larger input: C:\>c:\go1.6.3\bin\go run x.go > ^Z [0 "" EOF] > hello^Zworld [13 "hello\x1aworld\r\n" <nil>] > So the fix was incomplete. Worse, the fix broke Unicode console input. ReadFile does not handle Unicode console input correctly. To handle Unicode correctly, programs must use ReadConsole. Early versions of Go used ReadFile to read the console, leading to incorrect Unicode handling, which was filed as #4760 and fixed in CL 7312053, which switched to ReadConsole and was released as part of Go 1.1 and still worked as of Go 1.5: C:\>c:\go1.5.4\bin\go run x.go > hello [7 "hello\r\n" <nil>] > hello world
™ [16 "hello world™ \r\n" <nil>] > But in Go 1.6: C:\>c:\go1.6.3\bin\go run x.go > hello [7 "hello\r\n" <nil>] > hello world™ [0 "" EOF] > That is, changing back to ReadFile in Go 1.6 reintroduced #4760, which has been refiled as #17097. (We have no automated test for this because we don't know how to simulate console input in a test: it appears that one must actually type at a keyboard to use the real APIs. This CL at least adds a comment warning not to reintroduce ReadFile again.) CL 29493 attempted to fix #17097, but it was not a complete fix: the hello world™ example above still fails, as does Shift-JIS input, which was filed as #17939. CL 29493 also broke ^Z handling, which was filed as #17427. This CL attempts the never before successfully performed trick of simultaneously fixing Unicode console input and ^Z handling. It changes the console input to use ReadConsole again, as in Go 1.5, which seemed to work for all known Unicode input. Then it adds explicit handling of ^Z in the input stream. (In the case where standard input is a redirected file, ^Z processing should not happen, and it does not, because this code path is only invoked when standard input is the console.) With this CL: C:\>go run x.go > hello [7 "hello\r\n" <nil>] > hello world™ [16 "hello world™ \r\n" <nil>] > ^Z [0 "" EOF] > [2 "\r\n" <nil>] > hello^Zworld [5 "hello" <nil>] > [0 "" EOF] > [7 "world\r\n" <nil>] This almost matches Unix: $ go run /tmp/x.go > hello [6 "hello\n" <nil>] > hello world™ [15 "hello world™ \n" <nil>] > ^D [0 "" EOF] > [1 "\n" <nil>] > hello^Dworld [5 "hello" <nil>] > [6 "world\n" <nil>] > The difference is in the handling of hello^Dworld / hello^Zworld. On Unix, hello^Dworld terminates the read of hello but does not result in a zero-length read between reading hello and world. This is dictated by the tty driver, not any special Go code. On Windows, in this CL, hello^Zworld inserts a zero length read result between hello and world, which is treated as an interior EOF. This is implemented by the Go code in this CL, but it matches the handling of ^Z on the console in other programs: C:\>copy con x.txt hello^Zworld 1 file(s) copied. C:\>type x.txt hello C:\> A natural question is how to test all this. As noted above, we don't know how to write automated tests using the actual Windows console. CL 29493 introduced the idea of substituting a different syscall.ReadFile implementation for testing; this CL continues that idea but substituting for syscall.ReadConsole instead. To avoid the regression of putting ReadFile back, this CL adds a comment warning against that. Fixes #17427. Fixes #17939. Change-Id: Ibaabd0ceb2d7af501d44ac66d53f64aba3944142 Reviewed-on: https://go-review.googlesource.com/33451 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Quentin Smith <quentin@golang.org> Reviewed-by: Alex Brainman <alex.brainman@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> -
David Crawshaw authored
Fixes the os test on the Android builder. Change-Id: Ibb9db712156a620fcccf515e035475c5e2f535a5 Reviewed-on: https://go-review.googlesource.com/33650 Run-TryBot: David Crawshaw <crawshaw@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
- 28 Nov, 2016 6 commits
-
-
Brad Fitzpatrick authored
Updates #18082 Change-Id: I2e65b115b809c1e1bf813f538989d1a1f96b2876 Reviewed-on: https://go-review.googlesource.com/33636Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Ian Lance Taylor authored
The pprof code discards all heap allocations made by runtime routines. This caused it to discard heap allocations made by functions called by reflect.Call, as the calls are made via the functions `runtime.call32`, `runtime.call64`, etc. Fix the profiler to retain these heap allocations. Fixes #18077. Change-Id: I8962d552f1d0b70fc7e6f7b2dbae8d5bdefb0735 Reviewed-on: https://go-review.googlesource.com/33635 Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Joe Tsai authored
Fixes #18054 Change-Id: I6773943a95b92eebd7e347f8f7a80843b4827243 Reviewed-on: https://go-review.googlesource.com/33630Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Kaviraj authored
Document that key in Header.Get(key) is case insensitive in http.Header, mail.Header, textproto.Header. Fixes #18019 Change-Id: Iba7932491e02e555190b6fce053088b580a853ef Reviewed-on: https://go-review.googlesource.com/33530Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Michael Munday authored
The element index needs to be placed in From3. Before this CL it was impossible to write a VSTE instruction that could be successfully parsed, so this won't affect existing assembly code. Fixes #18075. Change-Id: I5b71be4c6632b1d5a30820a529122f96fd1bc864 Reviewed-on: https://go-review.googlesource.com/33584 Run-TryBot: Michael Munday <munday@ca.ibm.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Bill O'Farrell <billotosyr@gmail.com> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Mikio Hara authored
Change-Id: Ic96fb52f37257e06e77cc08da5c73ea6f9ff158c Reviewed-on: https://go-review.googlesource.com/33592Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com> Run-TryBot: Mikio Hara <mikioh.mikioh@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
- 26 Nov, 2016 1 commit
-
-
Joe Tsai authored
Fixes #17982 Change-Id: I4884a6b57905420ac0e37210c411de98c582de1d Reviewed-on: https://go-review.googlesource.com/33473Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
- 25 Nov, 2016 1 commit
-
-
Daniel Martí authored
The TestMain docs explain that flag.Parse() should be called if TestMain itself depends on command-line flags. The issue here is that the example implementation does not use any flags, and thus the flag.Parse call is unnecessary. This leads to people who use this example as a starting point for their own implementations to forget that the call is not necessary in most cases. Comment it out instead of removing the line to keep it as a reminder, as suggested by Minux Ma. Change-Id: I6ffc5413e7036366ae3cf0f069b7065e832a3b45 Reviewed-on: https://go-review.googlesource.com/33273Reviewed-by: Minux Ma <minux@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
- 24 Nov, 2016 3 commits
-
-
Brad Fitzpatrick authored
Or they can use sql.Param instead. Change-Id: Icf21dbcc87170635c3f5d3f49736429a37abe9da Reviewed-on: https://go-review.googlesource.com/33576 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Daniel Theophanes <kardianos@gmail.com> Reviewed-by: Minux Ma <minux@golang.org>
-
Daniel Theophanes authored
Change-Id: Ib936539946f43556a7dd501f8127054f6a27861f Reviewed-on: https://go-review.googlesource.com/33553Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Dan Peterson authored
Change-Id: Ia27ca728bafcf20d001b477787b21d16ae12960d Reviewed-on: https://go-review.googlesource.com/33552Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
- 23 Nov, 2016 8 commits
-
-
Michael Munday authored
When transitioning from C code to Go code we must respect the C calling convention. On s390x this means that r6-r13, r15 and f8-f15 must be saved and restored by functions that use them. On s390x we were saving the wrong set of floating point registers (f0, f2, f4 and f6) rather than f8-f15 which means that Go code could clobber registers that C code expects to be restored. This CL modifies the crosscall functions on s390x to save/restore the correct floating point registers. Fixes #18035. Change-Id: I5cc6f552c893a4e677669c8891521bf735492e97 Reviewed-on: https://go-review.googlesource.com/33571Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Brad Fitzpatrick authored
It was supposed to be testing SSA, not amd64. For #18024 Change-Id: Ibe65d7eb6bed9bc4b3eda68e1eaec5fa39fe8f76 Reviewed-on: https://go-review.googlesource.com/33491Reviewed-by: Keith Randall <khr@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
-
Russ Cox authored
There is some code value too: types intending to implement Source64 can write a conversion confirming that. For #4254 and the Go 1.8 release notes. Change-Id: I7fc350a84f3a963e4dab317ad228fa340dda5c66 Reviewed-on: https://go-review.googlesource.com/33456 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Brad Fitzpatrick authored
TBR=See https://golang.org/cl/33244 and review there. Updates #17929 Change-Id: I752ec7a6d086f370feaf3cf282708620e891079b Reviewed-on: https://go-review.googlesource.com/33478Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Brad Fitzpatrick authored
Fixes #18026 Change-Id: Id510f427ceffb2441c3d6f5bb5c93244e46c6497 Reviewed-on: https://go-review.googlesource.com/33477 TryBot-Result: Gobot Gobot <gobot@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
-
Elias Naur authored
CL 32796 changes the SIGPIPE behaviour for c-archive and c-shared programs. Add it to go1.8.txt. Change-Id: I31200187033349c642965a4bb077bcc77d5329a3 Reviewed-on: https://go-review.googlesource.com/33397Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Ian Lance Taylor authored
Sigh, forgot to run `git mail`. Change-Id: Idc49be2bb20d6f0e392cb472a63267ffee2ca22c Reviewed-on: https://go-review.googlesource.com/33476Reviewed-by: Michael Hudson-Doyle <michael.hudson@canonical.com>
-
Ian Lance Taylor authored
Update #9401. Fixes #18016. Change-Id: Icc24dd10dab1ad8e5cf295e0727d437afa5025c0 Reviewed-on: https://go-review.googlesource.com/33475 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
-
- 22 Nov, 2016 10 commits
-
-
Daniel Theophanes authored
TestPendingConnsAfterErr showed a failure on slower systems. Wait and check for the database to close all connections before pronouncing failure. A more careful method was attempted but the connection pool behavior is too dependent on the scheduler behavior to be predictable. Fixes #15684 Change-Id: Iafdbc90ba51170c76a079db04c3d5452047433a4 Reviewed-on: https://go-review.googlesource.com/33418Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Joe Tsai authored
Change-Id: I51180e1c685e488f7ea4c51a63fd035148671b05 Reviewed-on: https://go-review.googlesource.com/33470Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Brad Fitzpatrick authored
TBR=See https://golang.org/cl/33244 and review there. Updates #17929 Change-Id: I7cb0b666469dba35426d1f0ae1b185e0bdfeac05 Reviewed-on: https://go-review.googlesource.com/33474Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
David du Colombier authored
This changes makes the output of `go env` the same as on other operating systems. Fixes #18013. Change-Id: I3079e14dcf7b30c75ec3fde6c78cb95721111320 Reviewed-on: https://go-review.googlesource.com/33396Reviewed-by: Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Michael Munday authored
Applies the fix from CL 32920 to the new test TestSampledHeapAllocProfile introduced in CL 33422. The test should be skipped rather than fail if there is only one executable region of memory. Updates #17852. Change-Id: Id8c47b1f17ead14f02a58a024c9a04ebb8ec0429 Reviewed-on: https://go-review.googlesource.com/33453 Run-TryBot: Michael Munday <munday@ca.ibm.com> Reviewed-by: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Russ Cox authored
The expected default behavior (no explicit GOTRACEBACK setting) is for the stack trace to start in user code, eliding unnecessary runtime frames that led up to the actual trace printing code. The idea was that the first line number printed was the one that crashed. For #5832 we added code to show 'panic' frames so that if code panics and then starts running defers and then we trace from there, the panic frame can help explain why the code seems to have made a call not present in the code. But that's only needed for panics between two different call frames, not the panic at the very top of the stack trace. Fix the fix to again elide the runtime code at the very top of the stack trace. Simple panic: package main func main() { var x []int println(x[1]) } Before this CL: panic: runtime error: index out of range goroutine 1 [running]: panic(0x1056980, 0x1091bf0) /Users/rsc/go/src/runtime/panic.go:531 +0x1cf main.main() /tmp/x.go:5 +0x5 After this CL: panic: runtime error: index out of range goroutine 1 [running]: main.main() /tmp/x.go:5 +0x5 Panic inside defer triggered by panic: package main func main() { var x []int defer func() { println(x[1]) }() println(x[2]) } Before this CL: panic: runtime error: index out of range panic: runtime error: index out of range goroutine 1 [running]: panic(0x1056aa0, 0x1091bf0) /Users/rsc/go/src/runtime/panic.go:531 +0x1cf main.main.func1(0x0, 0x0, 0x0) /tmp/y.go:6 +0x62 panic(0x1056aa0, 0x1091bf0) /Users/rsc/go/src/runtime/panic.go:489 +0x2cf main.main() /tmp/y.go:8 +0x59 The middle panic is important: it explains why main.main ended up calling main.main.func1 on a line that looks like a call to println. The top panic is noise. After this CL: panic: runtime error: index out of range panic: runtime error: index out of range goroutine 1 [running]: main.main.func1(0x0, 0x0, 0x0) /tmp/y.go:6 +0x62 panic(0x1056ac0, 0x1091bf0) /Users/rsc/go/src/runtime/panic.go:489 +0x2cf main.main() /tmp/y.go:8 +0x59 Fixes #17901. Change-Id: Id6d7c76373f7a658a537a39ca32b7dc23e1e76aa Reviewed-on: https://go-review.googlesource.com/33165 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Brad Fitzpatrick authored
TBR=See https://golang.org/cl/33244 and review there. Updates #17929 Change-Id: I37b49318a9203b16c0c788926039288b99a36ce5 Reviewed-on: https://go-review.googlesource.com/33450Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Michael Matloob authored
When debug is 0, emit the compressed proto format. The debug>0 format stays the same. Updates #16093 Change-Id: I45aa1874a22d34cf44dd4aa78bbff9302381cb34 Reviewed-on: https://go-review.googlesource.com/33422 Run-TryBot: Michael Matloob <matloob@golang.org> Reviewed-by: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Brad Fitzpatrick authored
Updates #17929 Change-Id: Ibc711d39d9ff83458d213778117493796b678aa7 Reviewed-on: https://go-review.googlesource.com/33437Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Brad Fitzpatrick authored
Updates #17929 Change-Id: Ie90736cfce3fc5f23cbe0a0f1971476705aac5f9 Reviewed-on: https://go-review.googlesource.com/33436Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-