- 24 Sep, 2014 7 commits
-
-
Russ Cox authored
Fixes #8585. Removes some little-used code paths. LGTM=josharian R=golang-codereviews, minux, josharian CC=golang-codereviews, iant, r https://golang.org/cl/132970043
-
Russ Cox authored
CC=golang-codereviews https://golang.org/cl/145890046
-
Russ Cox authored
Those C files would have been compiled with 6c. It's close to impossible to use C correctly anymore, and the C compilers are going away eventually. Make them unavailable now. go1.4.txt change in CL 145890046 LGTM=iant R=iant CC=golang-codereviews, r https://golang.org/cl/149720043
-
Russ Cox authored
I have no idea what "absolute time" means. LGTM=dvyukov, r R=r, dvyukov CC=golang-codereviews https://golang.org/cl/144320043
-
Hector Martin Cantero authored
Normally, the caller to runtime.entersyscall() must not return before calling runtime.exitsyscall(), lest g->syscallsp become a dangling pointer. runtime.cgocallbackg() violates this constraint. To work around this, save g->syscallsp and g->syscallpc around cgo->Go callbacks, then restore them after calling runtime.entersyscall(), which restores the syscall stack frame pointer saved by cgocall. This allows the GC to correctly trace a goroutine that is currently returning from a Go->cgo->Go chain. This also adds a check to proc.c that panics if g->syscallsp is clearly invalid. It is not 100% foolproof, as it will not catch a case where the stack was popped then pushed back beyond g->syscallsp, but it does catch the present cgo issue and makes existing tests fail without the bugfix. Fixes #7978. LGTM=dvyukov, rsc R=golang-codereviews, dvyukov, minux, bradfitz, iant, gobot, rsc CC=golang-codereviews, rsc https://golang.org/cl/131910043
-
Russ Cox authored
Generated by a+c. R=gobot CC=golang-codereviews https://golang.org/cl/147080043
-
Rob Pike authored
There were at least two bugs: 1) It would overwrite a non-archive. 2) It would truncate a non-archive and then fail. In general the file handling was too clever to be correct. Make it more straightforward, doing the creation separately from archive management. Fixes #8369. LGTM=adg, iant R=golang-codereviews, adg, iant CC=golang-codereviews https://golang.org/cl/147010046
-
- 23 Sep, 2014 5 commits
-
-
Brad Fitzpatrick authored
LGTM=r R=r CC=golang-codereviews https://golang.org/cl/149950043
-
Brad Fitzpatrick authored
This hopefully fixes issue 8793. Fixes #8793 LGTM=iant R=rsc, iant CC=golang-codereviews https://golang.org/cl/150860046
-
Dave Cheney authored
Fixes #8775. Use the illegal instruction suggested by Ian in https://golang.org/cl/144180043/#msg4 on all arm arches. LGTM=minux R=golang-codereviews, gobot, rsc CC=golang-codereviews, iant, minux https://golang.org/cl/146130043
-
Dmitriy Vyukov authored
LGTM=bradfitz R=golang-codereviews, bradfitz CC=golang-codereviews https://golang.org/cl/145970043
-
Rob Pike authored
Was just a missing case (literally) in the type checker. Fixes #8473. LGTM=adg R=golang-codereviews, adg CC=golang-codereviews https://golang.org/cl/142460043
-
- 22 Sep, 2014 7 commits
-
-
Rob Pike authored
Fixes #8241. LGTM=iant R=golang-codereviews, iant CC=golang-codereviews https://golang.org/cl/144420043
-
Rob Pike authored
CC=golang-codereviews https://golang.org/cl/142450043
-
Rob Pike authored
Inspired by a remark by Leonard Holz, use constants for division BenchmarkSprintfEmpty 130 132 +1.54% BenchmarkSprintfString 438 437 -0.23% BenchmarkSprintfInt 417 414 -0.72% BenchmarkSprintfIntInt 663 691 +4.22% BenchmarkSprintfPrefixedInt 791 774 -2.15% BenchmarkSprintfFloat 701 686 -2.14% BenchmarkManyArgs 2584 2469 -4.45% BenchmarkFprintInt 488 357 -26.84% BenchmarkFprintIntNoAlloc 402 265 -34.08% BenchmarkScanInts 1244346 1267574 +1.87% BenchmarkScanRecursiveInt 1748741 1724138 -1.41% Update #3463 LGTM=josharian, rsc R=golang-codereviews, josharian, rsc CC=golang-codereviews https://golang.org/cl/144250043
-
Rob Pike authored
Previously, signed and unsigned integers could not be compared, but this has problems with things like comparing 'x' with a byte in a string. Since signed and unsigned integers have a well-defined ordering, even though their types are different, and since we already allow comparison regardless of the size of the integers, why not allow it regardless of the sign? Integers only, a fine place to draw the line. Fixes #7489. LGTM=adg R=golang-codereviews, adg CC=golang-codereviews https://golang.org/cl/149780043
-
Marko Tiikkaja authored
LGTM=bradfitz R=golang-codereviews, bradfitz, mattn.jp CC=golang-codereviews https://golang.org/cl/131650043
-
Brad Fitzpatrick authored
LGTM=adg R=rsc, adg CC=golang-codereviews https://golang.org/cl/144240043
-
Nigel Tao authored
palette. Fixes #7993. LGTM=r R=r CC=golang-codereviews, james.jdunne https://golang.org/cl/138600043
-
- 21 Sep, 2014 1 commit
-
-
Keith Randall authored
Saw this on a test: runtime: bad pointer in frame runtime_test.testSetPanicOnFault at 0xc20801c6b0: 0xfff fatal error: bad pointer! runtime stack: ... copystack(0xc2081bf7a0, 0x1000) /root/work/solaris-amd64-smartos-2dde8b453d26/go/src/runtime/stack.c:621 +0x173 fp=0xfffffd7ffd5ffee0 sp=0xfffffd7ffd5ffe20 runtime.newstack() /root/work/solaris-amd64-smartos-2dde8b453d26/go/src/runtime/stack.c:774 +0x552 fp=0xfffffd7ffd5fff90 sp=0xfffffd7ffd5ffee0 runtime.morestack() /root/work/solaris-amd64-smartos-2dde8b453d26/go/src/runtime/asm_amd64.s:324 +0x90 fp=0xfffffd7ffd5fff98 sp=0xfffffd7ffd5fff90 goroutine 163354 [stack growth]: ... runtime.convT2E(0x587000, 0xc20807bea8, 0x0, 0x0) /root/work/solaris-amd64-smartos-2dde8b453d26/go/src/runtime/iface.go:141 +0xd2 fp=0xc20801c678 sp=0xc20801c640 runtime_test.testSetPanicOnFault(0xc20822c510, 0xfff, 0xc20801c748) /root/work/solaris-amd64-smartos-2dde8b453d26/go/src/runtime/runtime_test.go:211 +0xc6 fp=0xc20801c718 sp=0xc20801c678 ... This test is testing bad pointers. It loads the bad pointer into a pointer variable, but before it gets a chance to dereference it, calls convT2E. That call causes a stack copy, which exposes that live but bad pointer variable. LGTM=dvyukov R=golang-codereviews, dvyukov CC=golang-codereviews https://golang.org/cl/146880043
-
- 19 Sep, 2014 20 commits
-
-
Keith Randall authored
When running defers, we must check whether the defer has already been marked as started so we don't run it twice. Fixes #8774. LGTM=rsc R=rsc CC=golang-codereviews https://golang.org/cl/142280044
-
Rob Pike authored
The proposed text in the last CL had a comma that was missing from the submitted spec. LGTM=gri R=gri CC=golang-codereviews https://golang.org/cl/150720043
-
Robert Griesemer authored
Fixes #8107. LGTM=iant, rsc, r R=r, rsc, iant, ken CC=golang-codereviews https://golang.org/cl/145960043
-
Sameer Ajmani authored
LGTM=rsc R=rsc CC=golang-codereviews https://golang.org/cl/138700043
-
Russ Cox authored
Fixes #8594. LGTM=bradfitz R=bradfitz CC=golang-codereviews https://golang.org/cl/145760043
-
Russ Cox authored
Pure renaming. This will make an upcoming CL have smaller diffs. LGTM=dvyukov, iant R=iant, dvyukov CC=golang-codereviews https://golang.org/cl/142280043
-
Russ Cox authored
Fixes #8202. LGTM=r, bradfitz R=r, josharian, bradfitz CC=golang-codereviews https://golang.org/cl/148770043
-
John Tuley authored
Fixes #8755. LGTM=bradfitz R=bradfitz CC=golang-codereviews, jtuley https://golang.org/cl/136710044
-
Russ Cox authored
CL 144940043 renamed it from Sched to SchedType to avoid a lowercasing conflict in the Go code with the variable named sched. We've been using just T resolve those conflicts, not Type. The FooType pattern is already taken for the kind-specific variants of the runtime Type structure: ChanType, MapType, and so on. SchedType isn't a Type. LGTM=bradfitz, khr R=khr, bradfitz CC=golang-codereviews https://golang.org/cl/145180043
-
Russ Cox authored
Fixes #6163. LGTM=adg R=golang-codereviews, adg, dvyukov CC=golang-codereviews https://golang.org/cl/141600043
-
Russ Cox authored
Fixes #8517. LGTM=dvyukov, alex.brainman R=golang-codereviews, dvyukov, alex.brainman CC=golang-codereviews https://golang.org/cl/145890044
-
Dave Cheney authored
Update #8690 If liblink determines that the host doesn't support TLS it replaces the MRC call with a BL runtime.tls_read_fallback. The problem is save_g doesn't expect anyone to make any BL calls and hasn't setup its own link register properly so when runtime.tls_read_fallback returns the LR points to save_g, not save_g's caller so the RET at the end of the function turns into an infinite loop. This fix is only a proof of concept, I think the real fix should go into liblink as its MRC substitution is not as transparent as expected. LGTM=rsc R=rsc, minux CC=golang-codereviews https://golang.org/cl/143050043
-
Russ Cox authored
Fixes #8008. LGTM=adg R=golang-codereviews, nightlyone, adg CC=golang-codereviews https://golang.org/cl/138630045
-
Russ Cox authored
We can't assume all those addresses are unmapped. But at least one should be. What we're really testing is that the program doesn't crash. Fixes #8542. LGTM=iant R=golang-codereviews, iant, minux CC=golang-codereviews https://golang.org/cl/144120043
-
Alex Brainman authored
We mark DBG_PRINTEXCEPTION_C messages in VEH handler as handled, thus preventing debugger from seeing them. I don't see reason for doing that. The comment warns of crashes, but I added test and don't see any crashes. This is also simplify VEH handler before making changes to fix issue 8006. Update #8006 LGTM=rsc R=golang-codereviews, rsc CC=golang-codereviews https://golang.org/cl/146800043
-
Russ Cox authored
Fixes #7859. LGTM=r R=adonovan, r CC=golang-codereviews https://golang.org/cl/136710043
-
David du Colombier authored
It fixes the TestRemoveAllRace test introduced in CL 145860043. LGTM=bradfitz R=rsc, bradfitz CC=golang-codereviews https://golang.org/cl/147820044
-
Alex Brainman authored
This is to simplify VEH handler before making changes to fix issue 8006. Update #8006 LGTM=adg, rsc R=golang-codereviews, adg, rsc CC=golang-codereviews https://golang.org/cl/138630043
-
Russ Cox authored
Same fix as for SysUnused. Fixes #8038. LGTM=iant, alex.brainman R=golang-codereviews, iant, alex.brainman CC=golang-codereviews https://golang.org/cl/147820043
-
Russ Cox authored
The current Windows build failure happens because by default runtime frames are excluded from stack traces. Apparently the Windows breakpoint path dies with an ordinary panic, while the Unix path dies with a throw. Breakpoint is a strange function and I don't mind that it's a little different on the two operating systems. The panic squelches runtime frames but the throw shows them, because throw is considered something that shouldn't have happened at all, so as much detail as possible is wanted. The runtime exclusion is meant to prevents printing too much noise about internal runtime details. But exported functions are not internal details, so show exported functions. If the program dies because you called runtime.Breakpoint, it's okay to see that frame. This makes the Breakpoint test show Breakpoint in the stack trace no matter how it is handled. Should fix Windows build. Tested on Unix by changing Breakpoint to fault instead of doing a breakpoint. TBR=brainman CC=golang-codereviews https://golang.org/cl/143300043
-