Robert Griesemer [Fri, 2 Oct 2015 17:55:27 +0000 (10:55 -0700)]
readme: emphasize issue tracker is for bugs/proposals
Removed direct link to issue tracker in the README - it makes it too
easy to use it for a question - and it's abused multiple times a day
for questions. It's easy enough to find it if there's a real issue
to report.
Added sentence to point people at golang-nuts and the new forum.
Michael Hudson-Doyle [Tue, 22 Sep 2015 10:35:52 +0000 (22:35 +1200)]
runtime: adjust the ppc64x memmove and memclr to copy by word as much as it can
Issue #12552 can happen on ppc64 too, although much less frequently in my
testing. I'm fairly sure this fixes it (2 out of 200 runs of oracle.test failed
without this change and 0 of 200 failed with it). It's also a lot faster for
large moves/clears:
runtime: drop sigfwd from signal forwarding unsupported platforms
This change splits signal_unix.go into signal_unix.go and
signal2_unix.go and removes the fake symbol sigfwd from signal
forwarding unsupported platforms for clarification purpose.
Change-Id: I205eab5cf1930fda8a68659b35cfa9f3a0e67ca6
Reviewed-on: https://go-review.googlesource.com/12062 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Burcu Dogan [Thu, 1 Oct 2015 19:01:50 +0000 (15:01 -0400)]
net: make /etc/hosts lookups case-insensitive
The native Go host resolver was behaving differently than libc
and the entries in the /etc/hosts were handled in a case sensitive
way. In order to be compatible with libc's resolver, /etc/hosts
lookups must be case-insensitive.
Joel Sing [Sat, 26 Sep 2015 17:56:05 +0000 (03:56 +1000)]
runtime: handle sysReserve failure in mHeap_SysAlloc
sysReserve will return nil on failure - correctly handle this case and return
nil to the caller. Currently, a failure will result in h.arena_end being set
to psize, h.arena_used being set to zero and fun times ensue.
On the openbsd/arm builder this has resulted in:
runtime: address space conflict: map(0x0) = 0x40946000
fatal error: runtime: address space conflict
When it should be reporting out of memory instead.
Joe Tsai [Mon, 28 Sep 2015 23:38:16 +0000 (16:38 -0700)]
archive/tar: fix bugs with sparseFileReader
The sparseFileReader is prone to two different forms of
denial-of-service attacks:
* A malicious tar file can cause an infinite loop
* A malicious tar file can cause arbitrary panics
This results because of poor error checking/handling, which this
CL fixes. While we are at it, add a plethora of unit tests to
test for possible malicious inputs.
Change-Id: I2f9446539d189f3c1738a1608b0ad4859c1be929
Reviewed-on: https://go-review.googlesource.com/15115 Reviewed-by: Andrew Gerrand <adg@golang.org>
Run-TryBot: Andrew Gerrand <adg@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Ian Lance Taylor [Wed, 30 Sep 2015 04:24:13 +0000 (21:24 -0700)]
runtime, runtime/cgo: support using msan on cgo code
The memory sanitizer (msan) is a nice compiler feature that can
dynamically check for memory errors in C code. It's not useful for Go
code, since Go is memory safe. But it is useful to be able to use the
memory sanitizer on C code that is linked into a Go program via cgo.
Without this change it does not work, as msan considers memory passed
from Go to C as uninitialized.
To make this work, change the runtime to call the C mmap function when
using cgo. When using msan the mmap call will be intercepted and marked
as returning initialized memory.
Work around what appears to be an msan bug by calling malloc before we
call mmap.
Change-Id: I8ab7286d7595ae84782f68a98bef6d3688b946f9
Reviewed-on: https://go-review.googlesource.com/15170
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Crawshaw <crawshaw@golang.org>
Austin Clements [Wed, 5 Aug 2015 15:35:28 +0000 (11:35 -0400)]
runtime: test that periodic GC works
We've broken periodic GC a few times without noticing because there's
no test for it, partly because you have to wait two minutes to see if
it happens. This exposes control of the periodic GC timeout to runtime
tests and adds a test that cranks it down to zero and sleeps for a bit
to make sure periodic GCs happen.
Adam Langley [Mon, 27 Jul 2015 23:54:30 +0000 (16:54 -0700)]
crypto/x509: parse CSRs with a critical flag in the requested extensions.
The format for a CSR is horribly underspecified and we had a mistake.
The code was parsing the attributes from the CSR as a
pkix.AttributeTypeAndValueSET, which is only almost correct: it works so
long as the requested extensions don't contain the optional “critical”
flag.
Unfortunately this mistake is exported somewhat in the API and the
Attributes field of a CSR actually has the wrong type. I've moved this
field to the bottom of the structure and updated the comment to reflect
this.
The Extensions and other fields of the CSR structure can be saved
however and this change does that.
Fixes #11897.
Change-Id: If8e2f5c21934800b72b041e38691efc3e897ecf1
Reviewed-on: https://go-review.googlesource.com/12717 Reviewed-by: Rob Pike <r@golang.org>
Adam Langley [Sun, 30 Aug 2015 16:45:26 +0000 (09:45 -0700)]
crypto/x509: make verification of an empty certificate consistent across platforms.
Platform-specific verification needs the ASN.1 contents of a certificate
but that might not be provided if the Certificate was not created by
ParseCertificate. In order to avoid a panic on Windows, and to make
behaviour consistent across platforms, this change causes verification
to fail when the ASN.1 contents of a certificate are not available.
Adam Langley [Sun, 30 Aug 2015 16:21:35 +0000 (09:21 -0700)]
math/big: correct documentation for ProbablyPrime.
As akalin points out in the bug, the comment previously claimed that the
probability that the input is prime given that the function returned
true is 1 - ¼ⁿ. But that's wrong: the correct statement is that the
probability of the function returning false given a composite input is
1 - ¼ⁿ.
This is not nearly as helpful, but at least it's truthful. A number of
other (correct) expressions are suggested on the bug, but I think that
the simplier one is preferable.
This change also notes that the function is not suitable for
adversarial inputs since it's deterministic.
Adam Langley [Sun, 30 Aug 2015 17:23:30 +0000 (10:23 -0700)]
crypto/tls: better error messages when PEM inputs are switched.
This change causes the types of skipped PEM blocks to be recorded when
no certificate or private-key data is found in a PEM input. This allows
for better error messages to be return in the case of common errors like
switching the certifiate and key inputs to X509KeyPair.
Rob Pike [Mon, 28 Sep 2015 20:45:57 +0000 (13:45 -0700)]
cmd/doc: fix pretty printing of paths
The code to strip GOROOT and GOPATH had a bug: it assumed there
were bytes after the GOROOT prefix but there might not be.
Fix this and other issues by taking care the prefix is really a
file name prefix for the path, not just a string prefix, and
handle the case where GOROOT==path.
Change-Id: I8066865fd05f938bb6dbf3bb8ab1fc58e5cf6bb5
Reviewed-on: https://go-review.googlesource.com/15112
Run-TryBot: Rob Pike <r@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Andrew Gerrand <adg@golang.org>
Read implements the standard Read interface: it reads data from the pipe,
blocking until a writer arrives or the write end is closed. If the write end
is closed with an error, that error is returned as err; otherwise err is
EOF.
func (s *SectionReader) Read(p []byte) (n int, err error)
>
to
<
func (l *LimitedReader) Read(p []byte) (n int, err error)
func (r *PipeReader) Read(data []byte) (n int, err error)
Read implements the standard Read interface: it reads data from the pipe,
blocking until a writer arrives or the write end is closed. If the write end
is closed with an error, that error is returned as err; otherwise err is
EOF.
func (s *SectionReader) Read(p []byte) (n int, err error)
>
Now the comment about PipeReader.Read doesn't look like it's about
SectionReader.
Based on a suggestion by dsnet@, a slight tweak from a CL he suggested
and abandoned.
Fixes #12756,
Change-Id: Iaf60ee9ae7f644c83c32d5e130acab0312b0c926
Reviewed-on: https://go-review.googlesource.com/14999 Reviewed-by: Andrew Gerrand <adg@golang.org>
Andrew Gerrand [Fri, 28 Aug 2015 05:31:51 +0000 (15:31 +1000)]
text/template, html/template: add block keyword and permit template redefinition
This change adds a new "block" keyword that permits the definition
of templates inline inside existing templates, and loosens the
restriction on template redefinition. Templates may now be redefined,
but in the html/template package they may only be redefined before
the template is executed (and therefore escaped).
The intention is that such inline templates can be redefined by
subsequent template definitions, permitting a kind of template
"inheritance" or "overlay". (See the example for details.)
Fixes #3812
Change-Id: I733cb5332c1c201c235f759cc64333462e70dc27
Reviewed-on: https://go-review.googlesource.com/14005 Reviewed-by: Rob Pike <r@golang.org>
Ian Lance Taylor [Sun, 27 Sep 2015 01:37:06 +0000 (18:37 -0700)]
cmd/cgo: only declare real function in gccgo exported header file
When exporting a function using gccgo, we generate two functions: a Go
function with a leading Cgoexp_ prefix, and a C function that calls the
Go function. The Go function has a name that can not be represented in
C, so the C code needs a declaration with an __asm__ qualifier giving
the name of the Go function.
Before this CL we put that declaration in the exported header file.
Because code would sometimes #include "_cgo_export.h", we added a macro
definition for the C function giving it the name of the declaration. We
then added a macro undefine in the actual C code, so that we could
declare the C function we wanted.
This rounadabout process worked OK until we started exporting the header
file for use with -buildmode=c-archive and c-shared. Doing that caused
the code to see the define and thus call the Go function rather than the
C function. That often works fine, but the C function calls
_cgo_wait_runtime_init_done before calling the Go function, and that
sometimes matters. This didn't show up in tests because we don't test
using gccgo. That is something we should fix, but not now.
Fix that by simplifying the code to declare the C function in the header
file as one would expect, and move the __asm__ declaration to the C
code.
Change-Id: I33547e028152ff98e332630994b4f33285feec32
Reviewed-on: https://go-review.googlesource.com/15043 Reviewed-by: Minux Ma <minux@golang.org>
Joel Sing [Sun, 27 Sep 2015 18:39:01 +0000 (04:39 +1000)]
tests/fixedbugs: make test for issue11656 run known instruction
As detailed in #11910, the current implementation attempts to execute an area
of memory with unknown content. If the memory is executable, the result is
unpredictable - instead, make the test deterministic by attempting to execute
an instruction that is known to trigger a trap on the given architecture.
The new implementation is written by iant@ and provided via #11910.
Update issue #11910
Change-Id: Ia698c36e0dd98a9d9d16a701f60f6748c6faf896
Reviewed-on: https://go-review.googlesource.com/15058
Run-TryBot: Joel Sing <jsing@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Joel Sing [Sat, 26 Sep 2015 16:33:00 +0000 (02:33 +1000)]
cmd/go: Skip note reading test with linkmode external on openbsd/arm
openbsd/arm does not support external linking - skip the note reading test that
uses linkmode external on this platform. While here, cleanup the code and
consistently use t.Skipf for all platforms that cannot run this test.
Change-Id: I64f0d9e038bc4c993c3d843fc069a0b723a924d6
Reviewed-on: https://go-review.googlesource.com/15054 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Robert Griesemer [Fri, 25 Sep 2015 17:09:04 +0000 (10:09 -0700)]
math/big: removed more unnecessary string conversions
- renamed (nat) itoa to utoa (since that's what it is)
- added (nat) itoa that takes a sign parameter; this helps removing a few string copies
- used buffers instead of string+ in Rat conversions
Change-Id: I6b37a6b39557ae311cafdfe5c4a26e9246bde1a9
Reviewed-on: https://go-review.googlesource.com/14995 Reviewed-by: Alan Donovan <adonovan@google.com>
syscall: fix alignment check for link-layer information on BSD variants
When link-layer information is wrapped with sockaddr_dl, we need to
follow the len field of sockaddr_dl. When link-layer information is
naked, we need to use the length of whole link-layer information.
Fixes #12641.
Change-Id: I4d377f64cbab1760b993fc55c719288616042bbb
Reviewed-on: https://go-review.googlesource.com/14939 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Rob Pike [Thu, 24 Sep 2015 20:10:00 +0000 (13:10 -0700)]
bufio: fix scanning with a final empty token.
The Scan function's interface to the split function was not sufficient
to handle an empty final token in a pure function; state was required.
This was ugly.
We introduce a special error value that a split function can return
that signals that this token is OK, but is the last one and scanning
should stop immediately _after_ this token.
The same effect could be achieved using the same trick (a special
error value) and checking for that error after Scan finishes, but it's
a little clumsy. Providing a published sentinel value in bufio is
cleaner and means everyone can use the same trick. The result
is an error-free scan.
Rewrite the test (that was only barely working) to use the value
and be more robust.
Also write a new example showing how to do it.
Fixes #11836
Change-Id: Iaae77d0f95b4a2efa0175ced94d93c66353079e8
Reviewed-on: https://go-review.googlesource.com/14924 Reviewed-by: Ian Lance Taylor <iant@golang.org>
cmd/go: elide -rpath when not applicable and used via LDFLAGS
Some linker flags should only be applied when performing the final
linking step for a shared library or executable, etc. In other
contexts, they're either invalid, or meaningless to apply (so should
not be specified).
When an external linker is used (either directly by Go or by the
compiler driver used by cgo), -rpath and -rpath-link should only be
specified in the final linking step. On platforms such as Solaris,
ld(1) will reject its use in any other scenario (such as when linking
relocatable objects).
This change is necessary because Go does not currently offer a way to
specify LDFLAGS based on when they should be applied.
Fixes #12115
Change-Id: If35a18d8eee8ec7ddcca2d4ccd41ab6ffcf93b41
Reviewed-on: https://go-review.googlesource.com/14674 Reviewed-by: Minux Ma <minux@golang.org>
Run-TryBot: Minux Ma <minux@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Robert Griesemer [Thu, 24 Sep 2015 22:10:47 +0000 (15:10 -0700)]
math/big: faster string conversion routines
Eliminated unnecessary string conversions throughout and removed
(internal) capability for arbitrary character sets in conversion
routines (functionality was not exported and not used internally).
Rob Pike [Wed, 23 Sep 2015 23:49:30 +0000 (16:49 -0700)]
cmd/doc: don't stop after first package if the symbol is not found
The test case is
go doc rand.Float64
The first package it finds is crypto/rand, which does not have a Float64.
Before this change, cmd/doc would stop there even though math/rand
has the symbol. After this change, we get:
% go doc rand.Float64
package rand // import "math/rand"
func Float64() float64
Float64 returns, as a float64, a pseudo-random number in [0.0,1.0) from the
default Source.
%
Another nice consequence is that if a symbol is not found, we might get
a longer list of packages that were examined:
% go doc rand.Int64
doc: no symbol Int64 in packages crypto/rand, math/rand
exit status 1
%
This change introduces a coroutine to scan the file system so that if
the symbol is not found, the coroutine can deliver another path to try.
(This is darned close to the original motivation for coroutines.)
Paths are delivered on an unbuffered channel so the scanner does
not proceed until candidate paths are needed.
The scanner is attached to a new type, called Dirs, that caches the results
so if we need to scan a second time, we don't walk the file system
again. This is significantly more efficient than the existing code, which
could scan the tree multiple times looking for a package with
the symbol.
Change-Id: I2789505b9992cf04c19376c51ae09af3bc305f7f
Reviewed-on: https://go-review.googlesource.com/14921 Reviewed-by: Andrew Gerrand <adg@golang.org>
cmd/link/internal/ld: removed some uses of stringsCompare
Only one use of stringsCompare is left. Cannot simply be replaced by
strings.Compare for bootstrapping reasons I guess.
Moving the function away from util.go to the actual destination data.go
also would not help much. So I left this one unchanged for readability and convenience.
Francisco Claude [Wed, 16 Sep 2015 15:56:06 +0000 (12:56 -0300)]
multipart: fixes problem parsing mime/multipart of certain lengths
When parsing the multipart data, if the delimiter appears but doesn't
finish with -- or \n or \r\n, it assumes the data can be consumed. This
is incorrect when the peeking buffer finishes with --delimiter-
Joe Tsai [Thu, 17 Sep 2015 23:07:38 +0000 (16:07 -0700)]
archive/tar: remove dead code with USTAR path splitting
Convert splitUSTARPath to return a bool rather than an error since
the caller never ever uses the error other than to check if it is
nil. Thus, we can remove errNameTooLong as well.
Also, fold the checking of the length <= fileNameSize and whether
the string is ASCII into the split function itself.
Lastly, remove logic to set the MAGIC since that's already done on
L200. Thus, setting the magic is redundant.
There is no overall logic change.
Updates #12638
Change-Id: I26b6992578199abad723c2a2af7f4fc078af9c17
Reviewed-on: https://go-review.googlesource.com/14723 Reviewed-by: David Symonds <dsymonds@golang.org>
Run-TryBot: David Symonds <dsymonds@golang.org>
Shenghou Ma [Wed, 23 Sep 2015 22:53:16 +0000 (18:53 -0400)]
cmd/dist: fix build after "go test" argument order change
Change-Id: I332cd4a4b48cbb52d2beeb16c4a24833bb7069d7
Reviewed-on: https://go-review.googlesource.com/14890 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Robert Griesemer [Wed, 23 Sep 2015 00:47:38 +0000 (17:47 -0700)]
spec: minor adjustment of prose in composite literal section
The prose discussing composite literals referred to the composite
literal type with 'LiteralType', denoting the literal type's EBNF
production explicitly. Changed 'LiteralType' to 'literal type' to
remove the literal (no pun intended) connection and instead mean
the underlying type. Seems a simpler and more readable change
than referring to the underlying type everywhere explicitly.
Fixes #12717.
Change-Id: I225df95f9ece2664b19068525ea8bda5ca05a44a
Reviewed-on: https://go-review.googlesource.com/14851 Reviewed-by: Rob Pike <r@golang.org>
Rob Pike [Tue, 22 Sep 2015 21:23:32 +0000 (14:23 -0700)]
cmd/go: fix processing of flags for test binaries.
The usage message says:
test [-c] [-i] [build and test flags] [packages] [flags for test binary]
but this was not what was implemented. Instead, after packages are named,
flag processing continues, which makes it impossible, for example, to pass
to the binary a flag with the same name as a test flag. This was triggered
by the -v flag in glog.
Attempting to run this test with go test pkg -v=7 would give a usage
message. This change allows it. In fact it allows
go test -v pkg -v=7
The solution is to implement the usage message. One compatibility
issue is that flags after the package name are no longer processed
as test flags, so this no longer works:
go test foo -cover
One must write
go test -cover foo
I do not think this is onerous but it must be called out in the
release notes.
Fixes #12177.
Change-Id: Ib9267884b47a6b0c183efa888ec78333272113aa
Reviewed-on: https://go-review.googlesource.com/14826 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Robert Griesemer [Wed, 23 Sep 2015 17:05:44 +0000 (10:05 -0700)]
math/big: factored out an internal accessor method (cleanup), added benchmark
Current result of DecimalConversion benchmark (for future reference):
BenchmarkDecimalConversion-8 10000 204770 ns/op
Measured on Mac Mini (late 2012) running OS X 10.10.5,
2.3 GHz Intel Core i7, 8 GB 1333 MHz DDR3.
Also: Removed comment suggesting to implement decimal by representing
digits as numbers 0..9 rather than ASCII chars '0'..'9' to avoid
repeated +/-'0' operations. Tried and it appears (per above benchmark)
that the +/-'0' operations are neglibile but the addition conversion
passes around it are not and that it makes things significantly slower.
Change-Id: I6ee033b1172043248093cc5d02abff5fc54c2e7a
Reviewed-on: https://go-review.googlesource.com/14857 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Alan Donovan <adonovan@google.com>
The existing comment for regex.Split contains a plain text example,
while many of the other regex functions have runnable examples. This
change provides a runnable example for Split.
Change-Id: I5373f57f532fe843d7d0adcf4b513061ec797047
Reviewed-on: https://go-review.googlesource.com/14737 Reviewed-by: Andrew Gerrand <adg@golang.org>
Run-TryBot: Andrew Gerrand <adg@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Robert Griesemer [Tue, 22 Sep 2015 16:37:56 +0000 (09:37 -0700)]
test/fixedbugs: update overly restrictive test case
See discussion in https://go-review.googlesource.com/14830 .
Change-Id: I94f25f92b8cdaa509d2c335865a645228425804d
Reviewed-on: https://go-review.googlesource.com/14837 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Robert Griesemer [Sun, 20 Sep 2015 01:24:16 +0000 (18:24 -0700)]
math/big: optimize Float.Parse by reducing powers of 10 to powers of 2 and 5
Instead of computing the final adjustment factor as a power of 10,
it's more efficient to split 10**e into 2**e * 5**e . Powers of 2
are trivially added to the Float exponent, and powers of 5 are
smaller and thus faster to compute.
Also, use a table of uint64 values rather than float64 values for
initial power value. uint64 values appear to be faster to convert
to Floats (useful for small exponents).
Added two small benchmarks to confirm that there's no regresssion.
benchmark old ns/op new ns/op delta
BenchmarkParseFloatSmallExp-8 17543 16220 -7.54%
BenchmarkParseFloatLargeExp-8 60865 59996 -1.43%
Change-Id: I3efd7556b023316f86f334137a67fe0c6d52f8ef
Reviewed-on: https://go-review.googlesource.com/14782 Reviewed-by: Alan Donovan <adonovan@google.com>
This change addresses an integer underflow appearing only on systems
using a 32-bit int type. The patch addresses the problem by limiting the
length of unknown chunks to 0x7fffffff. This value appears to already be
checked for when parsing other chunk types, so the bug shouldn't appear
elsewhere in the package. The PNG spec recommends the maximum size for
any chunk to remain under 2^31, so this shouldn't cause errors with
valid images.
Fixes #12687
Change-Id: I17f0e1683515532c661cf2b0b2bc65309d1b7bb7
Reviewed-on: https://go-review.googlesource.com/14766 Reviewed-by: Nigel Tao <nigeltao@golang.org>
Rob Pike [Mon, 21 Sep 2015 18:06:43 +0000 (11:06 -0700)]
cmd/vet: build the binary only once in the test
Recent changes caused vet to build the binary for each Test function.
This is wasteful and will become only more so as more tests are added.
Use testing.Main to build only once.
Verified that compilation errors still appear if the binary cannot be
built.
Before:
real 0m11.169s
user 0m18.328s
sys 0m2.152s
After:
real 0m5.132s
user 0m9.404s
sys 0m1.168s
Of course if the compiler were fast we might not notice, but vet is
a big program and growing bigger all the time, as are the tests.
The fields step and redoState of struct scanner are now defined as
`func(s *scanner, c byte) int` instead of
`func(s *scanner, c int) int`, since bytes are sufficient.
Further changes improve the consistency in the scanner.go file.
Change-Id: Ifb85f2130d728d2b936d79914d87a1f0b5c6ee7d
Reviewed-on: https://go-review.googlesource.com/14801 Reviewed-by: Andrew Gerrand <adg@golang.org>
Run-TryBot: Andrew Gerrand <adg@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Sometimes this read is instrumented by compiler when it creates
a temp to take address, but sometimes it is not (e.g. for global vars
compiler takes address of the global directly).
Instrument convT2E/I similarly to chansend and mapaccess.
Dave Cheney [Fri, 18 Sep 2015 08:56:47 +0000 (18:56 +1000)]
cmd/compile/internal/gc: move intLiteral to gc.Node
intLiteral is used by the gins wrappers in arm64, ppc64 and
mips64. Refactor the function to a method on gc.Node and update
the callers to use the common copy.
Change-Id: I2db90d801a9cb18f8526eb921e13daa75ca1cf6f
Reviewed-on: https://go-review.googlesource.com/14744 Reviewed-by: Aram Hăvărneanu <aram@mgk.ro> Reviewed-by: Dave Cheney <dave@cheney.net>
Run-TryBot: Dave Cheney <dave@cheney.net>
TryBot-Result: Gobot Gobot <gobot@golang.org>
runtime: remove flaky TestInvalidptrCrash to fix build
This test fails on arm64 and some amd64 OSs and fails on Linux/amd64
if you remove the first runtime.GC(), which should be unnecessary, and
run it in all.bash (but not if you run it in isolation). I don't
understand any of these failures, so for now just remove this test.
Currently when the GC prints an object for debugging (e.g., for a
failed invalidptr or checkmark check), it dumps the entire object. To
avoid inundating the user with output for really large objects, limit
this to printing just the first 128 words (which are most likely to be
useful in identifying the type of an object) and the 32 words around
the problematic field.
Change-Id: Id94a5c9d8162f8bd9b2a63bf0b1bfb0adde83c68
Reviewed-on: https://go-review.googlesource.com/14764 Reviewed-by: Rick Hudson <rlh@golang.org>
By default, the runtime panics if it detects a pointer to an
unallocated span. At this point, this usually catches bad uses of
unsafe or cgo in user code (though it could also catch runtime bugs).
Unfortunately, the rather cryptic error misleads users, offers users
little help with debugging their own problem, and offers the Go
developers little help with root-causing.
Improve the error message in various ways. First, the wording is
improved to make it clearer what condition was detected and to suggest
that this may be the result of incorrect use of unsafe or cgo. Second,
we add a dump of the object containing the bad pointer so that there's
at least some hope of figuring out why a bad pointer was stored in the
Go heap.
Change-Id: I57b91b12bc3cb04476399d7706679e096ce594b9
Reviewed-on: https://go-review.googlesource.com/14763 Reviewed-by: Rick Hudson <rlh@golang.org>