Skip to content

G
golang
Switch branch/tag
  1. 15 Nov, 2016 8 commits
  3. 14 Nov, 2016 6 commits
  5. 13 Nov, 2016 7 commits
  7. 12 Nov, 2016 12 commits
  9. 11 Nov, 2016 7 commits
    • Brad Fitzpatrick's avatar
      net: deflake TestTCPSupriousConnSetupCompletion [sic] · 9a78eade
      Brad Fitzpatrick authored 
      And rename it.

Fixes #17703

Change-Id: I73c82a9b3f96180699c6d33c069a666018eb30f9
Reviewed-on: https://go-review.googlesource.com/33149
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
      9a78eade
    • Quentin Smith's avatar
      cmd/go: skip TestCgoPkgConfig if pkg-config is too old · 02d79e95
      Quentin Smith authored 
      pkg-config 0.24 adds support for quoting and escaping whitespace;
distros like CentOS 6 are still shipping pkg-config 0.23. Skip the test
there since there's no way to get whitespace into the pkg-config output.

Fixes #17846.

Change-Id: Ie4ea17e9b709372a20178b539498929754bcd51f
Reviewed-on: https://go-review.googlesource.com/33027
Run-TryBot: Quentin Smith <quentin@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: 's avatarRuss Cox <rsc@golang.org>
      02d79e95
    • Brad Fitzpatrick's avatar
      time: don't panic stringifying the zero Month · a18b4b3f
      Brad Fitzpatrick authored 
      Fixes #17720

Change-Id: Ib95c230deef3934db729856c17908f8e5a1e2b7f
Reviewed-on: https://go-review.googlesource.com/33145
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
Reviewed-by: 's avatarRob Pike <r@golang.org>
      a18b4b3f
    • Rhys Hiltner's avatar
      runtime: include pre-panic/throw logs in core dumps · e0aedfb4
      Rhys Hiltner authored 
      When a Go program crashes with GOTRACEBACK=crash, the OS creates a
core dump. Include the text-formatted output of some of the cause of
that crash in the core dump.

Output printed by the runtime before crashing is maintained in a
circular buffer to allow access to messages that may be printed
immediately before calling runtime.throw.

The stack traces printed by the runtime as it crashes are not stored.
The information required to recreate them should be included in the
core file.

Updates #16893

There are no tests covering the generation of core dumps; this change
has not added any.

This adds (reentrant) locking to runtime.gwrite, which may have an
undesired performance impact.

Change-Id: Ia2463be3c12429354d290bdec5f3c8d565d1a2c3
Reviewed-on: https://go-review.googlesource.com/32013
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: 's avatarRuss Cox <rsc@golang.org>
      e0aedfb4
    • Brad Fitzpatrick's avatar
      net/smtp: make Client.Auth trim final space if Auth.Start toServer is empty · 10d2efd0
      Brad Fitzpatrick authored 
      Users can implement the smtp.Auth interface and return zero bytes in
the "toServer []byte" return value from the Auth.Start method. People
apparently do this to implement the SMTP "LOGIN" method.

But we were then sending "AUTH LOGIN \r\n" to the server, which some
servers apparently choke on. So, trim it when the toServer value is
empty.

Fixes #17794

Change-Id: I83662dba9e0f61b1c5000396c096cf7110f78361
Reviewed-on: https://go-review.googlesource.com/33143
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
      10d2efd0
    • Russ Cox's avatar
      runtime: fix Windows profiling crash · e6da64b6
      Russ Cox authored 
      I don't have any way to test or reproduce this problem,
but the current code is clearly wrong for Windows.
Make it better.

As I said on #17165:

But the borrowing of M's and the profiling of M's by the CPU profiler
seem not synchronized enough. This code implements the CPU profiler
on Windows:

	func profileloop1(param uintptr) uint32 {
		stdcall2(_SetThreadPriority, currentThread, _THREAD_PRIORITY_HIGHEST)

		for {
			stdcall2(_WaitForSingleObject, profiletimer, _INFINITE)
			first := (*m)(atomic.Loadp(unsafe.Pointer(&allm)))
			for mp := first; mp != nil; mp = mp.alllink {
				thread := atomic.Loaduintptr(&mp.thread)
				// Do not profile threads blocked on Notes,
				// this includes idle worker threads,
				// idle timer thread, idle heap scavenger, etc.
				if thread == 0 || mp.profilehz == 0 || mp.blocked {
					continue
				}
				stdcall1(_SuspendThread, thread)
				if mp.profilehz != 0 && !mp.blocked {
					profilem(mp)
				}
				stdcall1(_ResumeThread, thread)
			}
		}
	}

	func profilem(mp *m) {
		var r *context
		rbuf := make([]byte, unsafe.Sizeof(*r)+15)

		tls := &mp.tls[0]
		gp := *((**g)(unsafe.Pointer(tls)))

		// align Context to 16 bytes
		r = (*context)(unsafe.Pointer((uintptr(unsafe.Pointer(&rbuf[15]))) &^ 15))
		r.contextflags = _CONTEXT_CONTROL
		stdcall2(_GetThreadContext, mp.thread, uintptr(unsafe.Pointer(r)))
		sigprof(r.ip(), r.sp(), 0, gp, mp)
	}

	func sigprof(pc, sp, lr uintptr, gp *g, mp *m) {
		if prof.hz == 0 {
			return
		}

		// Profiling runs concurrently with GC, so it must not allocate.
		mp.mallocing++

		... lots of code ...

		mp.mallocing--
	}

A borrowed M may migrate between threads. Between the
atomic.Loaduintptr(&mp.thread) and the SuspendThread, mp may have
moved to a new thread, so that it's in active use. In particular
it might be calling malloc, as in the crash stack trace. If so, the
mp.mallocing++ in sigprof would provoke the crash.

Those lines are trying to guard against allocation during sigprof.
But on Windows, mp is the thread being traced, not the current
thread. Those lines should really be using getg().m.mallocing, which
is the same on Unix but not on Windows. With that change, it's
possible the race on the actual thread is not a problem: the traceback
would get confused and eventually return an error, but that's fine.
The code expects that possibility.

Fixes #17165.

Change-Id: If6619731910d65ca4b1a6e7de761fa2518ef339e
Reviewed-on: https://go-review.googlesource.com/33132
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
      e6da64b6
    • Bill O'Farrell's avatar
      math: use SIMD to accelerate some scalar math functions on s390x · b6a15683
      Bill O'Farrell authored 
      Note, most math functions are structured to use stubs, so that they can
be accelerated with assembly on any platform.
Sinh, cosh, and tanh were not structued with stubs, so this CL does
that. This set of routines was chosen as likely to produce good speedups
with assembly on any platform.

Technique used was minimax polynomial approximation using tables of
polynomial coefficients, with argument range reduction.
A table of scaling factors was also used for cosh and log10.

                     before       after      speedup
BenchmarkCos         22.1 ns/op   6.79 ns/op  3.25x
BenchmarkCosh       125   ns/op  11.7  ns/op 10.68x
BenchmarkLog10       48.4 ns/op  12.5  ns/op  3.87x
BenchmarkSin         22.2 ns/op   6.55 ns/op  3.39x
BenchmarkSinh       125   ns/op  14.2  ns/op  8.80x
BenchmarkTanh        65.0 ns/op  15.1  ns/op  4.30x

Accuracy was tested against a high precision
reference function to determine maximum error.
Approximately 4,000,000 points were tested for each function,
producing the following result.
Note: ulperr is error in "units in the last place"

       max
      ulperr
sin    1.43 (returns NaN beyond +-2^50)
cos    1.79 (returns NaN beyond +-2^50)
cosh   1.05
sinh   3.02
tanh   3.69
log10  1.75

Also includes a set of tests to test non-vector functions even
when SIMD is enabled

Change-Id: Icb45f14d00864ee19ed973d209c3af21e4df4edc
Reviewed-on: https://go-review.googlesource.com/32352
Run-TryBot: Michael Munday <munday@ca.ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: 's avatarMichael Munday <munday@ca.ibm.com>
      b6a15683