os package and path/filepath package have duplicated code for
checking symlink supports in test code.
This CL tries to simplify such test code.
Change-Id: I0371488337f5e951eca699852daab9ccb16ddd62
Reviewed-on: https://go-review.googlesource.com/27331
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
When tracing is started in the middle of program execution,
we already have a number of runnable goroutines and a number
of blocked/in syscall goroutines. In order to reflect these
goroutines in the trace, we emit EvGoCreate for all existing
goroutines. Then for blocked/in syscall goroutines we additionally
emit EvGoWaiting/EvGoInSyscall events. These events don't reset g.ev
during trace analysis. So next EvGoStart finds g.ev set to the
previous EvGoCreate. As the result time between EvGoCreate and
EvGoStart is accounted as scheduler latency. While in reality
it is blocking/syscall time.
Properly reset g.ev for EvGoWaiting/EvGoInSyscall events.
Change-Id: I0615ba31ed7567600a0667ebb27458481da73adb
Reviewed-on: https://go-review.googlesource.com/25572
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
The httptrace.ConnectStart and ConnectDone hooks are just about the
post-DNS connection to the host. We were accidentally also firing on
the UDP dials to DNS. Exclude those for now. We can add them back
later as separate hooks if desired. (but they'd only work for pure Go
DNS)
This wasn't noticed earlier because I was developing on a Mac at the
time, which always uses cgo for DNS. When running other tests on
Linux, I started seeing UDP dials.
Updates #12580
Change-Id: I2b2403f2483e227308fe008019f1100f6300250b
Reviewed-on: https://go-review.googlesource.com/23069
Reviewed-by: Andrew Gerrand <adg@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
We run the external network tests on builders, but some of our
builders have less-than-ideal DNS connectivity. This change continues
to run the tests on all builders, but marks certain builders as flaky
(network-wise), and only validates their DNS results if they got DNS
results.
Change-Id: I826dc2a6f6da55add89ae9c6db892b3b2f7b526b
Reviewed-on: https://go-review.googlesource.com/22852
Reviewed-by: Ian Lance Taylor <iant@golang.org>
On some processors cputicks (used to generate trace timestamps)
produce non-monotonic timestamps. It is important that the parser
distinguishes logically inconsistent traces (e.g. missing, excessive
or misordered events) from broken timestamps. The former is a bug
in tracer, the latter is a machine issue.
Test that (1) parser does not return a logical error in case of
broken timestamps and (2) broken timestamps are eventually detected
and reported.
Change-Id: Ib4b1eb43ce128b268e754400ed8b5e8def04bd78
Reviewed-on: https://go-review.googlesource.com/21608
Reviewed-by: Austin Clements <austin@google.com>
Currently tracer uses global sequencer and it introduces
significant slowdown on parallel machines (up to 10x).
Replace the global sequencer with per-goroutine sequencer.
If we assign per-goroutine sequence numbers to only 3 types
of events (start, unblock and syscall exit), it is enough to
restore consistent partial ordering of all events. Even these
events don't need sequence numbers all the time (if goroutine
starts on the same P where it was unblocked, then start does
not need sequence number).
The burden of restoring the order is put on trace parser.
Details of the algorithm are described in the comments.
On http benchmark with GOMAXPROCS=48:
no tracing: 5026 ns/op
tracing: 27803 ns/op (+453%)
with this change: 6369 ns/op (+26%, mostly for traceback)
Also trace size is reduced by ~22%. Average event size before: 4.63
bytes/event, after: 3.62 bytes/event.
Besides running trace tests, I've also tested with manually broken
cputicks (random skew for each event, per-P skew and episodic random skew).
In all cases broken timestamps were detected and no test failures.
Change-Id: I078bde421ccc386a66f6c2051ab207bcd5613efa
Reviewed-on: https://go-review.googlesource.com/21512
Run-TryBot: Dmitry Vyukov <dvyukov@google.com>
Reviewed-by: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This makes traces self-contained and simplifies trace workflow
in modern cloud environments where it is simpler to reach
a service via HTTP than to obtain the binary.
Change-Id: I6ff3ca694dc698270f1e29da37d5efaf4e843a0d
Reviewed-on: https://go-review.googlesource.com/21732
Run-TryBot: Dmitry Vyukov <dvyukov@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Flaky tests are a distraction and cover up real problems.
File bugs instead and mark them as flaky.
This moves the net/http flaky test flagging mechanism to internal/testenv.
Updates #15156
Updates #15157
Updates #15158
Change-Id: I0e561cd2a09c0dec369cd4ed93bc5a2b40233dfe
Reviewed-on: https://go-review.googlesource.com/21614
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Make sure that for any DLL that Go uses itself, we only look for the
DLL in the Windows System32 directory, guarding against DLL preloading
attacks.
(Unless the Windows version is ancient and LoadLibraryEx is
unavailable, in which case the user probably has bigger security
problems anyway.)
This does not change the behavior of syscall.LoadLibrary or NewLazyDLL
if the DLL name is something unused by Go itself.
This change also intentionally does not add any new API surface. Instead,
x/sys is updated with a LoadLibraryEx function and LazyDLL.Flags in:
https://golang.org/cl/21388
Updates #14959
Change-Id: I8d29200559cc19edf8dcf41dbdd39a389cd6aeb9
Reviewed-on: https://go-review.googlesource.com/21140
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Partial revert of https://golang.org/cl/20967 which
I can't reproduce and actually breaks me more.
Fixes#14901
Change-Id: I8cce443fbd95f5f6f2a5b6a4b9f2faab36167a12
Reviewed-on: https://go-review.googlesource.com/21292
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
This is a subset of https://golang.org/cl/20022 with only the copyright
header lines, so the next CL will be smaller and more reviewable.
Go policy has been single space after periods in comments for some time.
The copyright header template at:
https://golang.org/doc/contribute.html#copyright
also uses a single space.
Make them all consistent.
Change-Id: Icc26c6b8495c3820da6b171ca96a74701b4a01b0
Reviewed-on: https://go-review.googlesource.com/20111
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Go already supports Linux's getrandom, which is a slightly modified
version of getentropy.
getentropy was added in OpenBSD 5.6. All supported versions of OpenBSD
include it so, unlike with Linux and getrandom, we don't need to test
for its presence.
Fixes#13785.
Change-Id: Ib536b96675f257cd8c5de1e3a36165e15c9abac9
Reviewed-on: https://go-review.googlesource.com/18219
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
CL 4310 introduced these functions, but their
implementation does not match with their published
documentation. Correct the implementation.
Change-Id: I285e41f9c7c5fc4e550ff59b0adb8b2bcbf6737a
Reviewed-on: https://go-review.googlesource.com/17997
Reviewed-by: Yasuhiro MATSUMOTO <mattn.jp@gmail.com>
Reviewed-by: Russ Cox <rsc@golang.org>
The current implementation including Go 1.5 through 1.5.2 misuses
Windows API and mishandles the returned values from GetAdapterAddresses
on Windows. This change fixes various issues related to network facility
information by readjusting interface and interface address parsers.
Updates #5395.
Updates #10530.
Updates #12301.
Updates #12551.
Updates #13542.
Fixes#12691.
Fixes#12811.
Fixes#13476.
Fixes#13544.
Also fixes fragile screen scraping test cases in net_windows_test.go.
Additional information for reviewers:
It seems like almost all the issues above have the same root cause and
it is misunderstanding of Windows API. If my interpretation of the
information on MSDN is correctly, current implementation contains the
following bugs:
- SIO_GET_INTERFACE_LIST should not be used for IPv6. The behavior of
SIO_GET_INTERFACE_LIST is different on kernels and probably it doesn't
work correctly for IPv6 on old kernels such as Windows XP w/ SP2.
Unfortunately MSDN doesn't describe the detail of
SIO_GET_INTERFACE_LIST, but information on the net suggests so.
- Fetching IP_ADAPTER_ADDRESSES structures with fixed size area may not
work when using IPv6. IPv6 generates ton of interface addresses for
various addressing scopes. We need to adjust the area appropriately.
- PhysicalAddress field of IP_ADAPTER_ADDRESSES structure may have extra
space. We cannot ignore PhysicalAddressLength field of
IP_ADAPTER_ADDRESS structure.
- Flags field of IP_ADAPTER_ADDRESSES structure doesn't represent any of
administratively and operatinal statuses. It just represents settings
for windows network adapter.
- MTU field of IP_ADAPTER_ADDRESSES structure may have a uint32(-1) on
64-bit platform. We need to convert the value to interger
appropriately.
- IfType field of IP_ADAPTER_ADDRESSES structure is not a bit field.
Bitwire operation for the field is completely wrong.
- OperStatus field of IP_ADAPTER_ADDRESSES structure is not a bit field.
Bitwire operation for the field is completely wrong.
- IPv6IfIndex field of IP_ADAPTER_ADDRESSES structure is just a
substitute for IfIndex field. We cannot prefer IPv6IfIndex to IfIndex.
- Windows XP, 2003 server and below don't set OnLinkPrefixLength field
of IP_ADAPTER_UNICAST_ADDRESS structure. We cannot rely on the field
on old kernels. We can use FirstPrefix field of IP_ADAPTER_ADDRESSES
structure and IP_ADAPTER_PREFIX structure instead.
- Length field of IP_ADAPTER_{UNICAST,ANYCAST,MULTICAST}_ADDRESS
sturecures doesn't represent an address prefix length. It just
represents a socket address length.
Change-Id: Icabdaf7bd1d41360a981d2dad0b830b02b584528
Reviewed-on: https://go-review.googlesource.com/17412
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Factor out duplicated race thunks from sync, syscall net
and fmt packages into a separate package and use it.
Fixes#8593
Change-Id: I156869c50946277809f6b509463752e7f7d28cdb
Reviewed-on: https://go-review.googlesource.com/14870
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Dmitry Vyukov <dvyukov@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Change-Id: Ib6f168b6a2daf3befbf75b4b95967ff91ac95d12
Reviewed-on: https://go-review.googlesource.com/14456
Reviewed-by: Minux Ma <minux@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
While here, enable getrandom on arm64 too (using the value found in
include/uapi/asm-generic/unistd.h, which seems to match up with other
GOARCH=arm64 syscall numbers).
Updates #10848.
Change-Id: I5ab36ccf6ee8d5cc6f0e1a61d09f0da7410288b9
Reviewed-on: https://go-review.googlesource.com/16662
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Simplify slice/map literal expressions.
Caught with gofmt -d -s, fixed with gofmt -w -s
Checked that the result can still be compiled with Go 1.4.
Change-Id: I06bce110bb5f46ee2f45113681294475aa6968bc
Reviewed-on: https://go-review.googlesource.com/13839
Reviewed-by: Andrew Gerrand <adg@golang.org>
Allow registry blobs to be as large as 500MB
Update #12493
Change-Id: I1d0e5c10772d25f8e7e17fed6e2e7dd12ca4e7cf
Reviewed-on: https://go-review.googlesource.com/14287
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
GetMUIStringValue tries as a convenience to resolve string values even for pathless
resource DLLs by searching the system directory (one of several paths used
by the system's standard DLL search order algorithm). This would not be
needed if regLoadMUIString searched for pathless DLLs itself, but it
doesn't, instead it needs an absolute path, otherwise it will fail.
This approach works fine for solving issue #12015 (handle localized time
zone names; for which GetMUIStringValue was created) since tzres.dll that
is used to resolve localized time zone names has no path in the registry
but is located under the system directory.
However, this approach will fail if a pathless DLL is located somewhere
else than the system directory.
Because of this limitation GetMUIStringValue may have to be revised in the
future to allow for custom paths, possibly through another version of the
function.
See also:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms724890%28v=vs.85%29.aspxhttps://msdn.microsoft.com/en-us/library/windows/desktop/ms682586%28v=vs.85%29.aspx
Change-Id: Ida66a0ef1928e0461ce248c795827902d785e6cd
Reviewed-on: https://go-review.googlesource.com/13929
Reviewed-by: Rob Pike <r@golang.org>
The existing implementation fails to determine the correct time zone
abbreviations when the display language is non-English. This change adds
support for localized time zone names (standard- and daylightname)
by using the function RegLoadMUIString.
Fixes#12015
Change-Id: Ic0dc89c50993af8f292b199c20bc5932903e7e87
Reviewed-on: https://go-review.googlesource.com/13854
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Run-TryBot: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Could go in 1.5, although not critical.
See also #12107
Change-Id: I7f1608b58581d21df4db58f0db654fef79e33a90
Reviewed-on: https://go-review.googlesource.com/13481
Reviewed-by: Dave Cheney <dave@cheney.net>
This works after golang.org/cl/13120 is running on the
coordinator (maybe it already is).
Change-Id: I4053d8e2f32fafd47b927203a6f66d5858e23376
Reviewed-on: https://go-review.googlesource.com/13165
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This should fix the solaris/amd64 builder.
Change-Id: Idd6460cc9e842f7b874c9757379986aa723c974c
Reviewed-on: https://go-review.googlesource.com/12922
Reviewed-by: Austin Clements <austin@google.com>
Nearly all the flaky failures we've seen in trace tests have been
due to the use of time stamps to determine relative event ordering.
This is tricky for many reasons, including:
- different cores might not have exactly synchronized clocks
- VMs are worse than real hardware
- non-x86 chips have different timer resolution than x86 chips
- on fast systems two events can end up with the same time stamp
Stop trying to make time reliable. It's clearly not going to be for Go 1.5.
Instead, record an explicit event sequence number for ordering.
Using our own counter solves all of the above problems.
The trace still contains time stamps, of course. The sequence number
is just used for ordering.
Should alleviate #10554 somewhat. Then tickDiv can be chosen to
be a useful time unit instead of having to be exact for ordering.
Separating ordering and time stamps lets the trace parser diagnose
systems where the time stamp order and actual order do not match
for one reason or another. This CL adds that check to the end of
trace.Parse, after all other sequence order-based checking.
If that error is found, we skip the test instead of failing it.
Putting the check in trace.Parse means that cmd/trace will pick
up the same check, refusing to display a trace where the time stamps
do not match actual ordering.
Using net/http's BenchmarkClientServerParallel4 on various CPU counts,
not tracing vs tracing:
name old time/op new time/op delta
ClientServerParallel4 50.4µs ± 4% 80.2µs ± 4% +59.06% (p=0.000 n=10+10)
ClientServerParallel4-2 33.1µs ± 7% 57.8µs ± 5% +74.53% (p=0.000 n=10+10)
ClientServerParallel4-4 18.5µs ± 4% 32.6µs ± 3% +75.77% (p=0.000 n=10+10)
ClientServerParallel4-6 12.9µs ± 5% 24.4µs ± 2% +89.33% (p=0.000 n=10+10)
ClientServerParallel4-8 11.4µs ± 6% 21.0µs ± 3% +83.40% (p=0.000 n=10+10)
ClientServerParallel4-12 14.4µs ± 4% 23.8µs ± 4% +65.67% (p=0.000 n=10+10)
Fixes#10512.
Change-Id: I173eecf8191e86feefd728a5aad25bf1bc094b12
Reviewed-on: https://go-review.googlesource.com/12579
Reviewed-by: Austin Clements <austin@google.com>
Currently TestDoDupSuppress can fail if the goroutines created by its
loop run sequentially. This is rare, but it has caused failures on the
dashboard and in stress testing.
While I think there's no way to eliminate all possible thread
schedules that could make this test fail because it depends on waiting
until a Group.Do blocks, it is possible to make it much more robust.
This commit deflakes this test by forcing at least one invocation of
fn to start and all goroutines to reach the line just before the Do
call before allowing fn to proceed. fn then waits 10 milliseconds
before returning to allow the goroutines to pass through the Do.
With this change, in 50,000 runs of the stress testing configuration,
the number of calls to fn never even exceeded 1.
Fixes#11784.
Change-Id: Ie5adf5764545050ec407619769a656251c4cff04
Reviewed-on: https://go-review.googlesource.com/12681
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
