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>
This reverts commit 6f7961da28.
Russ suggests changing the frozon syscall package and obviously it's a
better solution. Perhaps he will also let me know the way how to get the
project owners to agree later.
Fixes#11492.
Change-Id: I98f9f366b72b85db54b4acfc3a604b62fb6d783c
Reviewed-on: https://go-review.googlesource.com/11854
Run-TryBot: Mikio Hara <mikioh.mikioh@gmail.com>
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
As per comments in cl/11834.
Change-Id: I285536b882fa9496e15d77d0d4c16ee913aca581
Reviewed-on: https://go-review.googlesource.com/11861
Reviewed-by: Daniel Theophanes <kardianos@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
On some VMs two events can happen at the same time. For examples:
179827399 GoStart p=2 g=11 off=936359 g=11
179827399 GoUnblock p=2 g=0 off=936355 g=11
If we do non-stable sort, the events can be reordered making the trace inconsistent.
Do stable sort instead.
Batches are dumped in FIFO order, so if these same-time events are split into
separate batches, stable sort still works.
Events on different CPUs go into different batches and can be reordered.
But the intention is that causally-related events on different CPUs
will have larger (non-zero) time diff.
Update #11320
Change-Id: Id1df96af41dff68ea1782ab4b23d5afd63b890c9
Reviewed-on: https://go-review.googlesource.com/11834
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The code formatting mechanism can be applied to partial Go code,
such as a list of statements. The statements are wrapped into a
function definition (to be parsed fine), and unwrapped after formatting.
When the statements contain //line annotations, it may fail,
because not all comments are flushed by the printer before the final '}'.
Formatting "\ta()\n//line :1" results in "\ta() }\n\n//line", which
is wrong.
Tweaked the wrapping/unwrapping code to make sure comments are flushed
before the '}'.
Fixes#11276
Change-Id: Id15c80279b0382ee9ed939cca1647f525c4929f5
Reviewed-on: https://go-review.googlesource.com/11282
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
These were found by grepping the comments from the go code and feeding
the output to aspell.
Change-Id: Id734d6c8d1938ec3c36bd94a4dbbad577e3ad395
Reviewed-on: https://go-review.googlesource.com/10941
Reviewed-by: Aamir Khan <syst3m.w0rm@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
According to MSDN RegQueryValueEx page:
If the data has the REG_SZ, REG_MULTI_SZ or REG_EXPAND_SZ type, the
string may not have been stored with the proper terminating null
characters. Therefore, even if the function returns ERROR_SUCCESS, the
application should ensure that the string is properly terminated before
using it; otherwise, it may overwrite a buffer. (Note that REG_MULTI_SZ
strings should have two terminating null characters.)
Test written by Alex Brainman <alex.brainman@gmail.com>
Change-Id: I8c0852e0527e27ceed949134ed5e6de944189986
Reviewed-on: https://go-review.googlesource.com/9806
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Run-TryBot: Alex Brainman <alex.brainman@gmail.com>
FileConn and FilePacketConn APIs accept user-configured socket
descriptors to make them work together with runtime-integrated network
poller, but there's a limitation. The APIs reject protocol sockets that
are not supported by standard library. It's very hard for the net,
syscall packages to look after all platform, feature-specific sockets.
This change allows various platform, feature-specific socket descriptors
to use runtime-integrated network poller by using SocketConn,
SocketPacketConn APIs that bridge between the net, syscall packages and
platforms.
New exposed APIs:
pkg net, func SocketConn(*os.File, SocketAddr) (Conn, error)
pkg net, func SocketPacketConn(*os.File, SocketAddr) (PacketConn, error)
pkg net, type SocketAddr interface { Addr, Raw }
pkg net, type SocketAddr interface, Addr([]uint8) Addr
pkg net, type SocketAddr interface, Raw(Addr) []uint8
Fixes#10565.
Change-Id: Iec57499b3d84bb5cb0bcf3f664330c535eec11e3
Reviewed-on: https://go-review.googlesource.com/9275
Reviewed-by: Ian Lance Taylor <iant@golang.org>
I have around twenty of such values on a Windows 7 development machine.
regedit displays (translated): "invalid 32-bits DWORD value".
Change-Id: Ib37a414ee4c85e891b0a25fed2ddad9e105f5f4e
Reviewed-on: https://go-review.googlesource.com/9901
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
ExpandString correctly loops on the syscall until it reaches the
required buffer size but truncates it before converting it back to
string. The truncation limit is increased to 2^15 bytes which is the
documented maximum ExpandEnvironmentStrings output size.
This fixes TestExpandString on systems where len($PATH) > 1024.
Change-Id: I2a6f184eeca939121b458bcffe1a436a50f3298e
Reviewed-on: https://go-review.googlesource.com/9805
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Run-TryBot: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This CL copies golang.org/x/sys/windows/registry into
internal/syscall/windows/registry (minus KeyInfo.ModTime to prevent
dependency cycles). New registry package is used in mime and time
packages instead of calling Windows API directly.
Change-Id: I965a5a41d4739b3ba38e539a7b8d96d3223e3d56
Reviewed-on: https://go-review.googlesource.com/9271
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Move the single file from internal/syscall to internal/syscall/unix,
to match the golang.org/x/sys layout.
Change-Id: I2fb2832b4cb22efc7666bd276f5401ac3e73dc40
Reviewed-on: https://go-review.googlesource.com/8972
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Previously, running
$ go get -u -v golang.org/x/tools/cmd/godoc
would results in dozens of HTTP requests for
https://golang.org/x/tools?go-get=1
once per package under x/tools.
Now it caches the results. We still end up doing one HTTP request for
all the packages under x/tools, but this reduces the total number of
HTTP requests in ~half.
This also moves the singleflight package back into an internal
package. singleflight was originally elsewhere as a package, then got
copied into "net" (without its tests). But now that we have internal,
put it in its own package, and restore its test.
Fixes#9249
Change-Id: Ieb5cf04fc4d0a0c188cb957efdc7ea3068c34e3f
Reviewed-on: https://go-review.googlesource.com/8727
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Currently, GC disables preemption between the traceGCStart and
traceGCDone, so it never moves Ps. Consequently, the trace verifier
attaches information about GC to its per-P state and will fail if GC
starts on one P and ends on another.
GC will soon be preemptible and may end on a different P than it
began. Hence, this change lifts this per-P verifier state to global
state.
Change-Id: I82256e2baab1ff3c4453fec312079018423b4b51
Reviewed-on: https://go-review.googlesource.com/8714
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
Reviewed-by: Rick Hudson <rlh@golang.org>
Rename now uses MoveFileEx which was previously not available to
use because it is not supported on Windows 2000.
Change-Id: I583d029c4467c9be6d1574a790c423559b441e87
Reviewed-on: https://go-review.googlesource.com/6140
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
cmd/gofmt and go/format had 3 functions (parse, format and isSpace)
that had to be kept in-sync.
This CL extracts these 3 functions and refactors them into a new
internal/format package.
This CL is just code reorganization with no behavior nor semantic
change.
Change-Id: I593f24e9d3cadbbd9559a67e3b1d2ff190b4fd90
Reviewed-on: https://go-review.googlesource.com/6760
Reviewed-by: Robert Griesemer <gri@golang.org>
cl8167 introduced internal/syscall/windows.GetVersion, but we already
have that function in syscall.GetVersion. Use that instead.
Also revert all internal/syscall/windows cl8167 changes.
Change-Id: I512a5bf4b3b696e93aaf69e9e8b7df7022670ec0
Reviewed-on: https://go-review.googlesource.com/8302
Reviewed-by: Daniel Theophanes <kardianos@gmail.com>
Reviewed-by: Minux Ma <minux@golang.org>
Windows XP SP2 and Windows 2003 do not support SHA2.
Change-Id: Ica5faed040e9ced8b79fe78d512586e0e8788b3f
Reviewed-on: https://go-review.googlesource.com/8167
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Channels and sync.Mutex'es allow another goroutine to acquire resource
ahead of an unblocked goroutine. This is good for performance, but
leads to futile wakeups (the unblocked goroutine needs to block again).
Futile wakeups caused user confusion during the very first evaluation
of tracing functionality on a real server (a goroutine as if acquires a mutex
in a loop, while there is no loop in user code).
This change detects futile wakeups on channels and emits a special event
to denote the fact. Later parser finds entire wakeup sequences
(unblock->start->block) and removes them.
sync.Mutex will be supported in a separate change.
Change-Id: Iaaaee9d5c0921afc62b449a97447445030ac19d3
Reviewed-on: https://go-review.googlesource.com/7380
Reviewed-by: Keith Randall <khr@golang.org>
This allows to test goroutine analysis code in runtime/pprof tests.
Also fix a nil-deref crash in goroutine analysis code that happens on runtime/pprof tests.
Change-Id: Id7884aa29f7fe4a8d7042482a86fe434e030461e
Reviewed-on: https://go-review.googlesource.com/7301
Run-TryBot: Dmitry Vyukov <dvyukov@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>
Augment ProcStart events with OS thread id.
This helps in scheduler locality analysis.
Change-Id: I93fea75d3072cf68de66110d0b59d07101badcb5
Reviewed-on: https://go-review.googlesource.com/7302
Reviewed-by: Keith Randall <khr@golang.org>
Stip uninteresting bottom and top frames from trace stacks.
This makes both binary and json trace files smaller,
and also makes stacks shorter and more readable in the viewer.
Change-Id: Ib9c80ccc280504f0e235f867f53f1d2652c41583
Reviewed-on: https://go-review.googlesource.com/5523
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Dmitry Vyukov <dvyukov@google.com>
The existing Hostname function uses the GetComputerName system
function in windows to determine the hostname. It has some downsides:
- The name is limited to 15 characters.
- The name returned is for NetBIOS, other OS's return a DNS name
This change adds to the internal/syscall/windows package a
GetComputerNameEx function, and related enum constants. They are used
instead of the syscall.ComputerName function to implement os.Hostname
on windows.
Fixes#9982
Change-Id: Idc8782785eb1eea37e64022bd201699ce9c4b39c
Reviewed-on: https://go-review.googlesource.com/5852
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Run-TryBot: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Carlos Castillo <cookieo9@gmail.com>
Reviewed-by: Yasuhiro MATSUMOTO <mattn.jp@gmail.com>
The code concerning quoted-printable encoding (RFC 2045) and its
variant for MIME headers (RFC 2047) is currently spread in
mime/multipart and net/mail. It is also not exported.
This commit is the second step to fix that issue. It moves the
RFC 2047 encoding and decoding functions from net/mail to
internal/mime. The exported API is unchanged.
Updates #4943
Change-Id: I5f58aa58e74bbe4ec91b2e9b8c81921338053b00
Reviewed-on: https://go-review.googlesource.com/2101
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Trace command allows to visualize and analyze traces.
Run as:
$ go tool trace binary trace.file
The commands opens web browser with the main page,
which contains links for trace visualization,
blocking profiler, network IO profiler and per-goroutine
traces.
Also move trace parser from runtime/pprof/trace_parser_test.go
to internal/trace/parser.go, so that it can be shared between
tests and the command.
Change-Id: Ic97ed59ad6e4c7e1dc9eca5e979701a2b4aed7cf
Reviewed-on: https://go-review.googlesource.com/3601
Reviewed-by: Andrew Gerrand <adg@golang.org>
