1. 11 Sep, 2014 1 commit
  2. 10 Sep, 2014 4 commits
    • Keith Randall's avatar
      reflect: use runtime's memmove instead of its own · b78d7b75
      Keith Randall authored
      They will both need write barriers at some point.
      But until then, no reason why we shouldn't share.
      
      LGTM=rsc
      R=golang-codereviews, rsc
      CC=golang-codereviews
      https://golang.org/cl/141330043
      b78d7b75
    • Anthony Martin's avatar
      runtime: stop plan9/amd64 build from crashing · 2302b21b
      Anthony Martin authored
      LGTM=iant
      R=rsc, 0intro, alex.brainman, iant
      CC=golang-codereviews
      https://golang.org/cl/140460044
      2302b21b
    • Matthew Dempsky's avatar
      runtime: cleanup openbsd semasleep implementation · d955dfb0
      Matthew Dempsky authored
      The previous implementation had several subtle issues.  It's not
      clear if any of these could actually be causing the flakiness
      problems on openbsd/386, but fixing them should only help.
      
      1. thrsleep() is implemented internally as unlock, then test *abort
      (if abort != nil), then tsleep().  Under the current code, that makes
      it theoretically possible that semasleep()/thrsleep() could release
      waitsemalock, then a racing semawakeup() could acquire the lock,
      increment waitsemacount, and call thrwakeup()/wakeup() before
      thrsleep() reaches tsleep().  (In practice, OpenBSD's big kernel lock
      seems unlikely to let this actually happen.)
      
      The proper way to avoid this is to pass &waitsemacount as the abort
      pointer to thrsleep so thrsleep knows to re-check it before going to
      sleep, and to wakeup if it's non-zero.  Then we avoid any races.
      (I actually suspect openbsd's sema{sleep,wakeup}() could be further
      simplified using cas/xadd instead of locks, but I don't want to be
      more intrusive than necessary so late in the 1.4 release cycle.)
      
      2. semasleep() takes a relative sleep duration, but thrsleep() needs
      an absolute sleep deadline.  Instead of recomputing the deadline each
      iteration, compute it once up front and use (*Timespec)(nil) to signify
      no deadline.  Ensures we retry properly if there's a spurious wakeup.
      
      3. Instead of assuming if thrsleep() woke up and waitsemacount wasn't
      available that we must have hit the deadline, check that the system
      call returned EWOULDBLOCK.
      
      4. Instead of assuming that 64-bit systems are little-endian, compute
      timediv() using a temporary int32 nsec and then assign it to tv_nsec.
      
      LGTM=iant
      R=jsing, iant
      CC=golang-codereviews
      https://golang.org/cl/137960043
      d955dfb0
    • Anthony Martin's avatar
      runtime: call rfork on scheduler stack on Plan 9 · 9f012e10
      Anthony Martin authored
      A race exists between the parent and child processes after a fork.
      The child needs to access the new M pointer passed as an argument
      but the parent may have already returned and clobbered it.
      
      Previously, we avoided this by saving the necessary data into
      registers before the rfork system call but this isn't guaranteed
      to work because Plan 9 makes no promises about the register state
      after a system call. Only the 386 kernel seems to save them.
      For amd64 and arm, this method won't work.
      
      We eliminate the race by allocating stack space for the scheduler
      goroutines (g0) in the per-process copy-on-write stack segment and
      by only calling rfork on the scheduler stack.
      
      LGTM=aram, 0intro, rsc
      R=aram, 0intro, mischief, rsc
      CC=golang-codereviews
      https://golang.org/cl/110680044
      9f012e10
  3. 09 Sep, 2014 17 commits
  4. 08 Sep, 2014 18 commits
    • Andrew Gerrand's avatar
      A+C: John Olds (individual CLA) · 0133e0a2
      Andrew Gerrand authored
      Generated by a+c.
      
      LGTM=jtolds, jbd
      R=gobot, jbd, jtolds
      CC=golang-codereviews
      https://golang.org/cl/137300043
      0133e0a2
    • Keith Randall's avatar
      runtime: note the double-releasem isn't an error. · 1d88f9dd
      Keith Randall authored
      LGTM=bradfitz
      R=dave, bradfitz
      CC=golang-codereviews
      https://golang.org/cl/136390043
      1d88f9dd
    • Mikio Hara's avatar
      net: don't set wrong option for controlling tcp keepalive on openbsd · 1fadd9e1
      Mikio Hara authored
      Fixes #8679.
      
      LGTM=iant
      R=golang-codereviews, iant
      CC=golang-codereviews
      https://golang.org/cl/141730043
      1fadd9e1
    • Russ Cox's avatar
      runtime: turn off StackCopyAlways · 176020e1
      Russ Cox authored
      windows/amd64 failure:
      http://build.golang.org/log/1ded5e3ef4bd1226f976e3180772f87e6c918255
      
      # ..\misc\cgo\testso
      runtime: copystack: locals size info only for syscall.Syscall
      fatal error: split stack not allowed
      
      runtime stack:
      runtime.throw(0xa64cc7)
              c:/go/src/runtime/panic.go:395 +0xad fp=0x6fde0 sp=0x6fdb0
      runtime.newstack()
              c:/go/src/runtime/stack.c:1001 +0x750 fp=0x6ff20 sp=0x6fde0
      runtime.morestack()
              c:/go/src/runtime/asm_amd64.s:306 +0x73 fp=0x6ff28 sp=0x6ff20
      
      goroutine 1 [stack growth, locked to thread]:
      runtime.freedefer(0xc0820ce120)
              c:/go/src/runtime/panic.go:162 fp=0xc08201b1a0 sp=0xc08201b198
      runtime.deferreturn(0xa69420)
              c:/go/src/runtime/panic.go:211 +0xa8 fp=0xc08201b1e8 sp=0xc08201b1a0
      runtime.cgocall_errno(0x498c00, 0xc08201b228, 0x0)
              c:/go/src/runtime/cgocall.go:134 +0x10e fp=0xc08201b210 sp=0xc08201b1e8
      syscall.Syscall(0x7786b1d0, 0x2, 0xc0820c85b0, 0xc08201b2d8, 0x0, 0x0, 0x0, 0x0)
              c:/go/src/runtime/syscall_windows.c:74 +0x3c fp=0xc08201b260 sp=0xc08201b210
      syscall.findFirstFile1(0xc0820c85b0, 0xc08201b2d8, 0x500000000000000, 0x0, 0x0)
              c:/go/src/syscall/zsyscall_windows.go:340 +0x76 fp=0xc08201b2b0 sp=0xc08201b260
      syscall.FindFirstFile(0xc0820c85b0, 0xc08210c500, 0xc0820c85b0, 0x0, 0x0)
              c:/go/src/syscall/syscall_windows.go:907 +0x6a fp=0xc08201b530 sp=0xc08201b2b0
      os.openDir(0xc0820b2e40, 0x33, 0x0, 0x0, 0x0)
              c:/go/src/os/file_windows.go:96 +0x110 fp=0xc08201b5e0 sp=0xc08201b530
      os.OpenFile(0xc0820b2e40, 0x33, 0x0, 0x0, 0x41, 0x0, 0x0)
              c:/go/src/os/file_windows.go:143 +0x1e9 fp=0xc08201b650 sp=0xc08201b5e0
      
      TBR=khr
      CC=golang-codereviews
      https://golang.org/cl/138230043
      176020e1
    • Russ Cox's avatar
      runtime: mark endcgo go:nosplit · 5103500d
      Russ Cox authored
      Should help windows/amd64.
      
      TBR=khr
      CC=golang-codereviews
      https://golang.org/cl/134660043
      5103500d
    • Robert Griesemer's avatar
      go/parser: fix (pathological) corner case · ec96795b
      Robert Griesemer authored
      Inside a control clause (if ... {}), composite
      literals starting with a type name must be parenthesized.
      A composite literal used in the array length expression
      of an array composite literal is already parenthesized.
      Not a valid program, but syntactically is should
      be accepted.
      
      LGTM=adonovan
      R=adonovan
      CC=golang-codereviews
      https://golang.org/cl/142760043
      ec96795b
    • Russ Cox's avatar
      runtime: mark freedefer and deferclass go:nosplit · 857d55a3
      Russ Cox authored
      This should make deferreturn nosplit all the way down,
      which should fix the current windows/amd64 failure.
      If not, I will change StackCopyAlways back to 0.
      
      TBR=khr
      CC=golang-codereviews
      https://golang.org/cl/135600043
      857d55a3
    • Andrew Gerrand's avatar
      doc: amend installation instructions · dc089574
      Andrew Gerrand authored
      Fixes #8674.
      
      LGTM=r
      R=r
      CC=golang-codereviews
      https://golang.org/cl/139320044
      dc089574
    • Russ Cox's avatar
      runtime: enable StackCopyAlways · 31829428
      Russ Cox authored
      Let's see how close we are to this being ready.
      Will roll back if it breaks any builds in non-trivial ways.
      
      LGTM=r, khr
      R=iant, khr, r
      CC=golang-codereviews
      https://golang.org/cl/138200043
      31829428
    • Russ Cox's avatar
      runtime: undo stray edit from CL 140380043 · 9e7c2293
      Russ Cox authored
      Was having serious editor problems on Windows.
      
      TBR=brainman, iant
      CC=golang-codereviews
      https://golang.org/cl/137370043
      9e7c2293
    • Russ Cox's avatar
      syscall: keep allocated C string live across call to Syscall · cf622d75
      Russ Cox authored
      Given:
      
              p := alloc()
              fn_taking_ptr(p)
      
      p is NOT recorded as live at the call to fn_taking_ptr:
      it's not needed by the code following the call.
      p was passed to fn_taking_ptr, and fn_taking_ptr must keep
      it alive as long as it needs it.
      In practice, fn_taking_ptr will keep its own arguments live
      for as long as the function is executing.
      
      But if instead you have:
      
              p := alloc()
              i := uintptr(unsafe.Pointer(p))
              fn_taking_int(i)
      
      p is STILL NOT recorded as live at the call to fn_taking_int:
      it's not needed by the code following the call.
      fn_taking_int is responsible for keeping its own arguments
      live, but fn_taking_int is written to take an integer, so even
      though fn_taking_int does keep its argument live, that argument
      does not keep the allocated memory live, because the garbage
      collector does not dereference integers.
      
      The shorter form:
      
              p := alloc()
              fn_taking_int(uintptr(unsafe.Pointer(p)))
      
      and the even shorter form:
      
              fn_taking_int(uintptr(unsafe.Pointer(alloc())))
      
      are both the same as the 3-line form above.
      
      syscall.Syscall is like fn_taking_int: it is written to take a list
      of integers, and yet those integers are sometimes pointers.
      If there is no other copy of those pointers being kept live,
      the memory they point at may be garbage collected during
      the call to syscall.Syscall.
      
      This is happening on Solaris: for whatever reason, the timing
      is such that the garbage collector manages to free the string
      argument to the open(2) system call before the system call
      has been invoked.
      
      Change the system call wrappers to insert explicit references
      that will keep the allocations alive in the original frame
      (and therefore preserve the memory) until after syscall.Syscall
      has returned.
      
      Should fix Solaris flakiness.
      
      This is not a problem for cgo, because cgo wrappers have
      correctly typed arguments.
      
      LGTM=iant, khr, aram, rlh
      R=iant, khr, bradfitz, aram, rlh
      CC=dvyukov, golang-codereviews, r
      https://golang.org/cl/139360044
      cf622d75
    • Russ Cox's avatar
      runtime: run sighandler on g0 stack on windows · 201cfe4a
      Russ Cox authored
      The sighander has been run at the bottom of the
      currently executing goroutine stack, but it's in C,
      and we don't want C on our ordinary goroutine stacks.
      Worse, it does a lot of stuff, and it might need more
      stack space. There is scary code in traceback_windows.go
      that talks about stack splits during sighandler.
      Moving sighandler to g0 will eliminate the possibility
      of stack splits and such, and then we can delete
      traceback_windows.go entirely. Win win.
      
      On the builder, all.bat passes with GOARCH=amd64
      and all.bat gets most of the way with GOARCH=386
      except for a DLL-loading test that I think is unrelated.
      
      Fixes windows build.
      
      TBR=brainman, iant
      CC=golang-codereviews
      https://golang.org/cl/140380043
      201cfe4a
    • Keith Randall's avatar
      runtime: merge panic1.go back into panic.go · 3a3d47db
      Keith Randall authored
      LGTM=rsc
      R=rsc
      CC=golang-codereviews
      https://golang.org/cl/139370043
      3a3d47db
    • Russ Cox's avatar
      liblink, runtime: diagnose and fix C code running on Go stack · c81a0ed3
      Russ Cox authored
      This CL contains compiler+runtime changes that detect C code
      running on Go (not g0, not gsignal) stacks, and it contains
      corrections for what it detected.
      
      The detection works by changing the C prologue to use a different
      stack guard word in the G than Go prologue does. On the g0 and
      gsignal stacks, that stack guard word is set to the usual
      stack guard value. But on ordinary Go stacks, that stack
      guard word is set to ^0, which will make any stack split
      check fail. The C prologue then calls morestackc instead
      of morestack, and morestackc aborts the program with
      a message about running C code on a Go stack.
      
      This check catches all C code running on the Go stack
      except NOSPLIT code. The NOSPLIT code is allowed,
      so the check is complete. Since it is a dynamic check,
      the code must execute to be caught. But unlike the static
      checks we've been using in cmd/ld, the dynamic check
      works with function pointers and other indirect calls.
      For example it caught sigpanic being pushed onto Go
      stacks in the signal handlers.
      
      Fixes #8667.
      
      LGTM=khr, iant
      R=golang-codereviews, khr, iant
      CC=golang-codereviews, r
      https://golang.org/cl/133700043
      c81a0ed3
    • Keith Randall's avatar
      runtime: a few cleanups. · 52631983
      Keith Randall authored
      LGTM=bradfitz
      R=golang-codereviews, bradfitz
      CC=golang-codereviews
      https://golang.org/cl/134630043
      52631983
    • David Crawshaw's avatar
      androidtest.bash: adjustment for move from src/pkg to src · 4c05d32f
      David Crawshaw authored
      LGTM=rsc
      R=rsc
      CC=golang-codereviews
      https://golang.org/cl/142740043
      4c05d32f
    • Dave Cheney's avatar
      cmd/cc: fix undefined behaviour warning in bv.c · 4a40fb19
      Dave Cheney authored
      Fixes warning
      
      # _/home/dfc/go/misc/cgo/test/backdoor
      /home/dfc/go/src/cmd/cc/bv.c:43:11: runtime error: left shift of 1 by 31 places cannot be represented in type 'int'
      
      LGTM=rsc
      R=rsc
      CC=golang-codereviews
      https://golang.org/cl/136330043
      4a40fb19
    • Dave Cheney's avatar
      cmd/gc: fix undefined behaviour warning in subr.c · 6a2e844f
      Dave Cheney authored
      Fixes warning
      
      /home/dfc/go/src/cmd/gc/subr.c:3469:8: runtime error: negation of -9223372036854775808 cannot be represented in type 'int64' (aka 'long'); cast to an unsigned type to negate this value to itself
      
      LGTM=rsc
      R=rsc
      CC=golang-codereviews
      https://golang.org/cl/141220043
      6a2e844f