LGTM=rsc
R=rsc, dave, iant, khr
CC=golang-codereviews
https://golang.org/cl/75820044

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

See the comment for description.

LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/75670044

LGTM=rsc
R=golang-codereviews
CC=golang-codereviews, khr, rsc
https://golang.org/cl/76070043

Fixes #7262

LGTM=iant
R=golang-codereviews, iant
CC=golang-codereviews
https://golang.org/cl/76110043

Fixes #6405

LGTM=rsc
R=rsc, iant
CC=golang-codereviews
https://golang.org/cl/72920046

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

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

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

LGTM=rsc
R=rsc, 0intro, aram, jeremyjackins, iant
CC=golang-codereviews, lucio.dere, minux.ma, paurea, r
https://golang.org/cl/9796043

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

LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/75350043

This check would allowed to easily prevent issue 7511.
Update #7511

LGTM=rsc
R=rsc, aram
CC=golang-codereviews
https://golang.org/cl/75260043

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

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

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

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

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

Fixes #7528.

LGTM=jsing
R=jsing
CC=golang-codereviews
https://golang.org/cl/75140045

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

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

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

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

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

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

LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/72640043

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

LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/74800043

We were fontifying the wrong part of method declarations

LGTM=adonovan
R=adonovan
CC=golang-codereviews
https://golang.org/cl/66120043

Fixes #7048.

LGTM=dominik.honnef
R=golang-codereviews, dominik.honnef
CC=golang-codereviews
https://golang.org/cl/74280044

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

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

Fixes #6882

LGTM=iant
R=rsc, iant
CC=golang-codereviews
https://golang.org/cl/72080043

Per RFC 3875 section 6 rules.

Fixes #7198

LGTM=adg
R=adg
CC=golang-codereviews
https://golang.org/cl/68960049

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

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

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

LGTM=iant
R=golang-codereviews, iant, bradfitz
CC=golang-codereviews, math-nuts
https://golang.org/cl/72820044

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

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