1. 30 Jul, 2014 6 commits
  2. 29 Jul, 2014 12 commits
  3. 28 Jul, 2014 4 commits
  4. 26 Jul, 2014 5 commits
  5. 25 Jul, 2014 5 commits
  6. 24 Jul, 2014 4 commits
  7. 23 Jul, 2014 4 commits
    • ChaiShushan's avatar
      misc/pprof: support web profiles on windows/MinGW · 8cb04077
      ChaiShushan authored
      LGTM=bradfitz
      R=golang-codereviews, bradfitz
      CC=golang-codereviews
      https://golang.org/cl/117060043
      8cb04077
    • Dmitriy Vyukov's avatar
      runtime: don't lock mheap on user goroutine · e91704af
      Dmitriy Vyukov authored
      This is bad for 2 reasons:
      1. if the code under lock ever grows stack,
      it will deadlock as stack growing acquires mheap lock.
      2. It currently deadlocks with SetCPUProfileRate:
      scavenger locks mheap, receives prof signal and tries to lock prof lock;
      meanwhile SetCPUProfileRate locks prof lock and tries to grow stack
      (presumably in runtime.unlock->futexwakeup). Boom.
      Let's assume that it
      Fixes #8407.
      
      LGTM=rsc
      R=golang-codereviews, rsc
      CC=golang-codereviews, khr
      https://golang.org/cl/112640043
      e91704af
    • Dmitriy Vyukov's avatar
      runtime: fix unexpected return pc for runtime.newstackcall · 0603fbb0
      Dmitriy Vyukov authored
      With cl/112640043 TestCgoDeadlockCrash episodically print:
      unexpected return pc for runtime.newstackcall
      After adding debug output I see the following trace:
      
      runtime: unexpected return pc for runtime.newstackcall called from 0xc208011b00
      runtime.throw(0x414da86)
              src/pkg/runtime/panic.c:523 +0x77
      runtime.gentraceback(0x40165fc, 0xba440c28, 0x0, 0xc208d15200, 0xc200000000, 0xc208ddfd20, 0x20, 0x0, 0x0, 0x300)
      	src/pkg/runtime/traceback_x86.c:185 +0xca4
      runtime.callers(0x1, 0xc208ddfd20, 0x20)
      	src/pkg/runtime/traceback_x86.c:438 +0x98
      mcommoninit(0xc208ddfc00)
      	src/pkg/runtime/proc.c:369 +0x5c
      runtime.allocm(0xc208052000)
      	src/pkg/runtime/proc.c:686 +0xa6
      newm(0x4017850, 0xc208052000)
      	src/pkg/runtime/proc.c:933 +0x27
      startm(0xc208052000, 0x100000001)
      	src/pkg/runtime/proc.c:1011 +0xba
      wakep()
      	src/pkg/runtime/proc.c:1071 +0x57
      resetspinning()
      	src/pkg/runtime/proc.c:1297 +0xa1
      schedule()
      	src/pkg/runtime/proc.c:1366 +0x14b
      runtime.gosched0(0xc20808e240)
      	src/pkg/runtime/proc.c:1465 +0x5b
      runtime.newstack()
      	src/pkg/runtime/stack.c:891 +0x44d
      runtime: unexpected return pc for runtime.newstackcall called from 0xc208011b00
      runtime.newstackcall(0x4000cbd, 0x4000b80)
      	src/pkg/runtime/asm_amd64.s:278 +0x6f
      
      I suspect that it can happen on any stack split.
      So don't unwind g0 stack.
      Also, that comment is lying -- we can traceback w/o mcache,
      CPU profiler does that.
      
      LGTM=rsc
      R=golang-codereviews
      CC=golang-codereviews, khr, rsc
      https://golang.org/cl/120040043
      0603fbb0
    • Russ Cox's avatar
      liblink: more precise literal word comparison on arm · b916dc19
      Russ Cox authored
      There are fields in the Addr that do not matter for the
      purpose of deciding that the same word is already
      in the current literal pool. Copy only the fields that
      do matter.
      
      This came up when comparing against the Go version
      because the way it is invoked doesn't copy a few fields
      (like node) that are never directly used by liblink itself.
      
      Also remove a stray print that is not well-defined in
      the new liblink. (Cannot use %D outside of %P, because
      %D needs the outer Prog*.)
      
      LGTM=minux
      R=minux
      CC=golang-codereviews
      https://golang.org/cl/119000043
      b916dc19