- 14 Mar, 2014 8 commits
-
-
Rémy Oudompheng authored
LGTM=rsc R=rsc, dave, iant, khr CC=golang-codereviews https://golang.org/cl/75820044
-
Dmitriy Vyukov authored
Currently processes crash with obscure message. Say that it's "out of memory". LGTM=rsc R=golang-codereviews CC=golang-codereviews, khr, rsc https://golang.org/cl/75820045
-
Dmitriy Vyukov authored
See the comment for description. LGTM=rsc R=rsc CC=golang-codereviews https://golang.org/cl/75670044
-
Dmitriy Vyukov authored
LGTM=rsc R=golang-codereviews CC=golang-codereviews, khr, rsc https://golang.org/cl/76070043
-
Jan Ziak authored
Fixes #7262 LGTM=iant R=golang-codereviews, iant CC=golang-codereviews https://golang.org/cl/76110043
-
Jan Ziak authored
Fixes #6405 LGTM=rsc R=rsc, iant CC=golang-codereviews https://golang.org/cl/72920046
-
Shenghou Ma authored
Old versions of DTrace (as those shipped in OS X and FreeBSD) don't support unicode characters in symbol names. Replace '·' to '.' to make DTrace happy. Fixes #7493 LGTM=aram, rsc R=aram, rsc, gobot, iant CC=golang-codereviews https://golang.org/cl/72280043
-
Aram Hăvărneanu authored
The Solaris network poller uses event ports, which are level-triggered. As such, it has to re-arm itself after each wakeup. The arming mechanism (which runs in its own thread) raced with the closing of a file descriptor happening in a different thread. When a network file descriptor is about to be closed, the network poller is awaken to give it a chance to remove its association with the file descriptor. Because the poller always re-armed itself, it raced with code that closed the descriptor. This change makes the network poller check before re-arming if the file descriptor is about to be closed, in which case it will ignore the re-arming request. It uses the per-PollDesc lock in order to serialize access to the PollDesc. This change also adds extensive documentation describing the Solaris implementation of the network poller. Fixes #7410. LGTM=dvyukov, iant R=golang-codereviews, bradfitz, iant, dvyukov, aram.h, gobot CC=golang-codereviews https://golang.org/cl/69190044
-
- 13 Mar, 2014 17 commits
-
-
Keith Randall authored
debug/elf does the same thing, use []byte{} for any missing sections. Fixes #7510 LGTM=rsc R=golang-codereviews, iant CC=golang-codereviews, rsc https://golang.org/cl/75230043
-
Anthony Martin authored
LGTM=rsc R=rsc, 0intro, aram, jeremyjackins, iant CC=golang-codereviews, lucio.dere, minux.ma, paurea, r https://golang.org/cl/9796043
-
Dmitriy Vyukov authored
Mark free memory blocks as unused. On amd64 it allows the process to eat all 128 GB of heap without killing the machine. LGTM=rsc R=rsc CC=golang-codereviews https://golang.org/cl/74070043
-
Dmitriy Vyukov authored
LGTM=bradfitz R=golang-codereviews, bradfitz CC=golang-codereviews https://golang.org/cl/75350043
-
Dmitriy Vyukov authored
This check would allowed to easily prevent issue 7511. Update #7511 LGTM=rsc R=rsc, aram CC=golang-codereviews https://golang.org/cl/75260043
-
Dmitriy Vyukov authored
This is especially important for SetPanicOnCrash, but also useful for e.g. nil deref in mallocgc. Panics on such crashes can't lead to anything useful, only to deadlocks, hangs and obscure crashes. This is a copy of broken but already LGTMed https://golang.org/cl/68540043/ TBR=rsc R=rsc CC=golang-codereviews https://golang.org/cl/75320043
-
Dmitriy Vyukov authored
When we copy stack, we check only new size of the top segment. This is incorrect, because we can have other segments below it. LGTM=khr R=golang-codereviews, khr CC=golang-codereviews, rsc https://golang.org/cl/73980045
-
Aram Hăvărneanu authored
Calling runtime·cgocall could trigger a GC in the child while gclock was held by the parent. Fixes #7511 LGTM=bradfitz, dvyukov, dave R=golang-codereviews, bradfitz, dvyukov, dave CC=golang-codereviews, rsc https://golang.org/cl/75210044
-
Rémy Oudompheng authored
The lowering to runtime calls introduces hidden pointers to the arguments of select clauses. When implicit conversions were involved it could end up with incompatible pointers. Since the pointed-to types have the same representation, we can introduce a forced conversion. Fixes #6847. LGTM=rsc R=rsc, iant, khr CC=golang-codereviews https://golang.org/cl/72380043
-
Rémy Oudompheng authored
It was using a REP STOSQ but putting in CX the number of 32-bit words to clear. LGTM=dave R=rsc, dave CC=golang-codereviews https://golang.org/cl/75240043
-
Mikio Hara authored
Fixes #7528. LGTM=jsing R=jsing CC=golang-codereviews https://golang.org/cl/75140045
-
Michael Hudson-Doyle authored
Under some circumstances, gccgoToolchain's ld can pass the path of build outputs that have been deleted to the link command. Fixes #7303. LGTM=rsc R=golang-codereviews, dave, michael.hudson, rsc CC=golang-codereviews https://golang.org/cl/61970044
-
Anthony Martin authored
Otherwise, we won't get a stack trace in some of the early init. Here's one example: http://build.golang.org/log/a96d10f6aee1fa3e3ae51f41da46d414a7ab02de After walking the stack by hand in acid, I was able to determine that the stackalloc inside mpreinit was causing the throw. LGTM=rsc R=rsc, dvyukov CC=golang-codereviews https://golang.org/cl/72450044
-
Anthony Martin authored
The compilers expect to not be interrupted by floating point exceptions. On Plan 9, every process starts with interrupts enabled for invalid operation, stack overflow, and divide by zero exceptions. LGTM=rsc R=rsc, 0intro CC=golang-codereviews https://golang.org/cl/72750043
-
Anthony Martin authored
Previously, we wrote "kill" to the process control file to kill a program. This is problematic because it doesn't let the program gracefully exit. This matters especially if the process we're killing is a Go program. On Unix, sending SIGKILL to a Go program will automatically kill all runtime threads. On Plan 9, there are no threads so when the program wants to exit it has to somehow signal all of the runtime processes. It can't do this if we mercilessly kill it by writing to it's control file. Instead, we now send it a note to invoke it's note handler and let it perform any cleanup before exiting. LGTM=rsc R=rsc, 0intro CC=golang-codereviews https://golang.org/cl/74440044
-
Anthony Martin authored
On Plan 9, the kernel disallows the use of floating point instructions while handling a note. Previously, we worked around this by using a simple loop in place of memmove. When I added that work-around, I verified that all paths from the note handler didn't end up calling memmove. Now that memclr is using SSE instructions, the same process will have to be done again. Instead of doing that, however, this CL just punts and uses unoptimized functions everywhere on Plan 9. LGTM=rsc R=rsc, 0intro CC=golang-codereviews https://golang.org/cl/73830044
-
Anthony Martin authored
Acid can't produce a stack trace without .frame symbols. Of course, it can only unwind through linear stacks but this is still better than nothing. (I wrote an acid func to do the full unwind a long time ago but lost it and haven't worked up the courage to write it again). Note that these will only be present in the native symbol table for Plan 9 binaries. LGTM=rsc R=rsc CC=golang-codereviews https://golang.org/cl/72450045
-
- 12 Mar, 2014 15 commits
-
-
Brad Fitzpatrick authored
LGTM=rsc R=rsc CC=golang-codereviews https://golang.org/cl/72640043
-
Dave Cheney authored
syscall.naclWrite was missing from sys_nacl_386.s This gets ./make.bash passing, but doesn't pass validation. I'm not sure if this is the fault of this change, or validation was broken anyway. LGTM=rsc R=minux.ma, rsc CC=golang-codereviews https://golang.org/cl/74510043
-
Russ Cox authored
LGTM=bradfitz R=golang-codereviews, bradfitz CC=golang-codereviews https://golang.org/cl/74800043
-
Dominik Honnef authored
We were fontifying the wrong part of method declarations LGTM=adonovan R=adonovan CC=golang-codereviews https://golang.org/cl/66120043
-
Rob Pike authored
Fixes #7048. LGTM=dominik.honnef R=golang-codereviews, dominik.honnef CC=golang-codereviews https://golang.org/cl/74280044
-
Dmitriy Vyukov authored
1. Fix the bug that shrinkstack returns memory to heap. This causes growslice to misbehave (it manually initialized blocks, and in efence mode shrinkstack's free leads to partially-initialized blocks coming out of growslice. Which in turn causes GC to crash while treating the garbage as Eface/Iface. 2. Enable efence for stack segments. LGTM=rsc R=golang-codereviews, rsc CC=golang-codereviews, khr https://golang.org/cl/74080043
-
Dmitriy Vyukov authored
Currently the test fails as: $ go test -v -cpu 1,1,1,1 runtime -test.run=TestStack stack_test.go:1584: Stack inuse: want 4194304, got 18446744073709547520 Update #7468 LGTM=rsc R=golang-codereviews, bradfitz CC=golang-codereviews, khr, rsc https://golang.org/cl/74010043
-
Jan Ziak authored
Fixes #6882 LGTM=iant R=rsc, iant CC=golang-codereviews https://golang.org/cl/72080043
-
Brad Fitzpatrick authored
Per RFC 3875 section 6 rules. Fixes #7198 LGTM=adg R=adg CC=golang-codereviews https://golang.org/cl/68960049
-
Russ Cox authored
The garbage collector uses type information to guide the traversal of the heap. If it sees a field that should be a string, it marks the object pointed at by the string data pointer as visited but does not bother to look at the data, because strings contain bytes, not pointers. If you save s[len(s):] somewhere, though, the string data pointer actually points just beyond the string data; if the string data were exactly the size of an allocated block, the string data pointer would actually point at the next block. It is incorrect to mark that next block as visited and not bother to look at the data, because the next block may be some other type entirely. The fix is to ignore strings with zero length during collection: they are empty and can never become non-empty: the base pointer will never be used again. The handling of slices already does this (but using cap instead of len). This was not a bug in Go 1.2, because until January all string allocations included a trailing NUL byte not included in the length, so s[len(s):] still pointed inside the string allocation (at the NUL). This bug was causing the crashes in test/run.go. Specifically, the parsing of a regexp in package regexp/syntax allocated a []syntax.Inst with rounded size 1152 bytes. In fact it allocated many such slices, because during the processing of test/index2.go it creates thousands of regexps that are all approximately the same complexity. That takes a long time, and test/run works on other tests in other goroutines. One such other test is chan/perm.go, which uses an 1152-byte source file. test/run reads that file into a []byte and then calls strings.Split(string(src), "\n"). The string(src) creates an 1152-byte string - and there's a very good chance of it landing next to one of the many many regexp slices already allocated - and then because the file ends in a \n, strings.Split records the tail empty string as the final element in the slice. A garbage collection happens at this point, the collection finds that string before encountering the []syntax.Inst data it now inadvertently points to, and the []syntax.Inst data is not scanned for the pointers that it contains. Each syntax.Inst contains a []rune, those are missed, and the backing rune arrays are freed for reuse. When the regexp is later executed, the runes being searched for are no longer runes at all, and there is no match, even on text that should match. On 64-bit machines the pointer in the []rune inside the syntax.Inst is larger (along with a few other pointers), pushing the []syntax.Inst backing array into a larger size class, avoiding the collision with chan/perm.go's inadvertently sized file. I expect this was more prevalent on OS X than on Linux or Windows because those managed to run faster or slower and didn't overlap index2.go with chan/perm.go as often. On the ARM systems, we only run one errorcheck test at a time, so index2 and chan/perm would never overlap. It is possible that this bug is the root cause of other crashes as well. For now we only know it is the cause of the test/run crash. Many thanks to Dmitriy for help debugging. Fixes #7344. Fixes #7455. LGTM=r, dvyukov, dave, iant R=golang-codereviews, dave, r, dvyukov, delpontej, iant CC=golang-codereviews, khr https://golang.org/cl/74250043
-
Russ Cox authored
Some of the errorcheck tests have many many identical regexps. Use a map to avoid storing the compiled form many many times in memory. Change the filterRe to a simple string to avoid the expense of those regexps as well. Cuts the time for run.go on index2.go by almost 50x. Noticed during debugging of issue 7344. LGTM=bradfitz R=bradfitz, josharian CC=golang-codereviews https://golang.org/cl/74380043
-
Russ Cox authored
debuglive >= 1 is not the condition under which we start recording messages (we avoid printing for init functions even if debuglive is set). LGTM=bradfitz, iant R=golang-codereviews, bradfitz CC=golang-codereviews, iant, khr https://golang.org/cl/74390043
-
Dhiru Kholia authored
LGTM=iant R=golang-codereviews, iant, bradfitz CC=golang-codereviews, math-nuts https://golang.org/cl/72820044
-
Mikio Hara authored
For now Note, futexsleep and futexwakeup are designed for threads, not for processes. The explicit use of UMTX_OP_WAIT_UINT_PRIVATE and UMTX_OP_WAKE_PRIVATE can avoid unnecessary traversals of VM objects, to hit undiscovered bugs related to VM system on SMP/SMT/NUMA environment. Update #7496 LGTM=iant R=golang-codereviews, gobot, iant, bradfitz CC=golang-codereviews https://golang.org/cl/72760043
-
Mikio Hara authored
Solaris doesn't have struct ip_mreqn, instead it uses struct ip_mreq and struct group_req with struct sockaddr_storage. Also fixes incorrect SockaddrDatalink. Update #7399 LGTM=aram, iant R=golang-codereviews, aram, gobot, iant CC=golang-codereviews https://golang.org/cl/73920043
-