sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: PowerToys
Issue: [KBM] Shift Right remains logically pressed in this particular scenario
Labels: Issue-Bug,Product-Keyboard Shortcut Manager,Priority-3

**Computer Information**

* PowerToys version: v0.20.1
* PowerToy Utility: Keyboard Manager
* Running PowerToys as Admin: no
* Windows build number: 2004 (Build 19041.450)

**Steps to Reproduce**
![image](https://user-images.githubusercontent.com/3206696/104110724-b81a1f80-52da-11eb-91cf-7a278868c8f3.png)

**NOTE:** it only reproduces remapping `Shift`, it doesn't reproduce remapping `Shift (right)` or `Shift (left)`

1. Create a shortcut in Keyboard Manager mapping SHIFT + F1 to F13
2. Create a shortcut in Keyboard Manager mapping SHIFT + F2 to F14
3. Go to https://keycode.info/ in Firefox or Edge. Verify that F1 and F2 work correctly.
4. Press and hold SHIFT Right and F1. Verify the web page is seeing an F13 keycode.
5. While **still holding** SHIFT Right, release F1 and press F2.
6. Verify the web page is seeing an F14 keycode.
7. Release all buttons.

Result:
- F1 and F2 are still being seen as F13 and F14 without shift being held.
- Windows Key no longer works on desktop, even when PowerToys is exited.
- F1 and F2 are also being seen as F13 and F14 in other apps.
- Unplug and replug in keyboard. Issues still persist, verifying that this is not hardware related.

NOTE: see comment below by @enricogior

**Expected Behavior**

* F1 should be sending an F1 keycode
* F2 should be sending an F2 keycode
* Windows Key should still function
Repository: TypeScript
Issue: [PROPOSAL] Support @augments/@extends attached to an Object types
Labels: Suggestion,Awaiting More Feedback

<!-- 🚨 STOP 🚨 𝗦𝗧𝗢𝗣 🚨 𝑺𝑻𝑶𝑷 🚨

Half of all issues filed here are duplicates, answered in the FAQ, or not appropriate for the bug tracker.

Please help us by doing the following steps before logging an issue:
  * Search: https://github.com/Microsoft/TypeScript/search?type=Issues
  * Read the FAQ, especially the "Common Feature Requests" section: https://github.com/Microsoft/TypeScript/wiki/FAQ

-->

## Search Terms

jsdoc extends object 

## Suggestion

Support `@augments`/`@extends` attached to an Object types.

Actually, *Storm IDEs are following it, on intellisense but `tsc` complains by
```
JSDoc '@augments' is not attached to a class.
```

## Use Cases

Provide a way to type the derivating (merged) result of any objects to a single one.

## Examples

```js
    /**
     * @typedef Obj
     * @type {Object}
     */
    
    /**
     * @typedef Properties
     * @type {Object}
     */
    
    /**
     * @typedef Return
     * @type {Object}
     * @augments Obj
     * @augments Properties
     */
    
    /**
     * @type {Obj} obj
     */
    const obj = {
      /**
       * @param {Properties} [properties]
       * @returns {Return}
       */
      derivate ({ ...properties } = {}) {
        return { ...this, ...properties }
      }
    }
```

## Checklist

My suggestion meets these guidelines:

* [x] This wouldn't be a breaking change in existing TypeScript/JavaScript code

* [x] This wouldn't change the runtime behavior of existing JavaScript code
* [x] This could be implemented without emitting different JS based on the types of the expressions
* [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
* [x] This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).
Repository: pytorch
Issue: Missing caffe2_pybind11_state in pip install after cmake.
Labels: module: build,triaged,module: pybind

## 🐛 Bug

Our build workflow is to
1. build by with CMake (and put in whatever args we need)
2. install it as a standalone lib
3. install (1) again with basically `pip install .`, which will be very fast as it's already built and contains all args we need.

Recently we noticed something is broken (may not be a recent regression but we just found it):
- `build/caffe2/python/caffe2_pybind11_state.<some python ext>.so` and its gpu versions are not installed by pip
- pip log shows
```
#9 4978.   Copying extension caffe2.python.caffe2_pybind11_state
#9 4978.   torch/lib/python3/dist-packages/caffe2/python/caffe2_pybind11_state.cpython-36m-x86_64-linux-gnu.so does not exist
#9 4978.
#9 4978.   Copying extension caffe2.python.caffe2_pybind11_state_gpu
#9 4978.   torch/lib/python3/dist-packages/caffe2/python/caffe2_pybind11_state_gpu.cpython-36m-x86_64-linux-gnu.so does not exist
```
- `ls -la build/caffe2/python` shows `.so` files are there prior to `pip install`.
- This breaks `import caffe2.python.caffe2_pybind11_state`, used somewhere by our onnx conversion workflow for detectron2 models.
- I think this line makes the wrong assumption about lib path https://github.com/pytorch/pytorch/blob/c30bc6d4d7b54296179d717c15cd7507ba520bae/setup.py#L472

## To Reproduce

This is basically all you need about our builds
https://github.com/xkszltl/Roaster/blob/e0b0110b07bb7d4119bb23e4e5c78d8187a81ae2/pkgs/pytorch.sh#L75-L152

## Environment

 - PyTorch Version (e.g., 1.0): master
 - OS (e.g., Linux): Ubuntu 18.04/CentOS 7
 - How you installed PyTorch (`conda`, `pip`, source): source
 - Build command you used (if compiling from source): cmake+ninja+gcc-8+pip install
 - Python version: 3.6.9

cc @malfet
Repository: pytorch
Issue: out kwargs are sometimes inconsistent with returned named tuple field name (and in some cases, cannot be made consistent)
Labels: triaged,module: codegen

For multi-return functions (functions that return multiple tensors), one reasonable invariant one might expect for the keyword argument name for passing in an explicit out tensor to match the named field of the named record returned by the function in question.

Unfortunately, this is not the case for the following functions:

```
- func: max.dim_max(Tensor self, int dim, bool keepdim=False, *, Tensor(a!) max, Tensor(b!) max_values) -> (Tensor(a!) values, Tensor(b!) indices)

- func: max.names_dim_max(Tensor self, Dimname dim, bool keepdim=False, *, Tensor(a!) max, Tensor(b!) max_values) -> (Tensor(a!) values, Tensor(b!) indices)

- func: min.dim_min(Tensor self, int dim, bool keepdim=False, *, Tensor(a!) min, Tensor(b!) min_indices) -> (Tensor(a!) values, Tensor(b!) indices)

- func: min.names_dim_min(Tensor self, Dimname dim, bool keepdim=False, *, Tensor(a!) min, Tensor(b!) min_indices) -> (Tensor(a!) values, Tensor(b!) indices)

- func: lstsq.X(Tensor self, Tensor A, *, Tensor(a!) solution, Tensor(b!) QR) -> (Tensor(a!) solution, Tensor(b!) QR)

- func: triangular_solve.X(Tensor self, Tensor A, bool upper=True, bool transpose=False, bool unitriangular=False, *, Tensor(a!) solution, Tensor(b!) cloned_coefficient) -> (Tensor(a!) solution, Tensor(b!) cloned_coefficient)

- func: symeig.e(Tensor self, bool eigenvectors=False, bool upper=True, *, Tensor(a!) eigenvalues, Tensor(b!) eigenvectors) -> (Tensor(a!) eigenvalues, Tensor(b!) eigenvectors)

- func: solve.solution(Tensor self, Tensor A, *, Tensor(a!) solution, Tensor(b!) lu) -> (Tensor(a!) solution, Tensor(b!) LU)

- func: eig.e(Tensor self, bool eigenvectors=False, *, Tensor(a!) e, Tensor(b!) v) -> (Tensor(a!) eigenvalues, Tensor(b!) eigenvectors)
```

To make matters worse, it is impossible to directly change the keyword arguments to match the output named tensor fields, as in the case of `eig.e` and `symeig.e` there is a name conflict between `bool eigenvectors` and the desired named output field `eigenvalues`.

cc @zasdfgbnm @gchanan
Repository: pytorch
Issue: torch.multinomial with replacement=True produces inaccurate results for large number of categories
Labels: module: numerical-stability,module: distributions,triaged

## 🐛 Bug

`torch.multinomial` with `replacement=True` produces very inaccurate results when number of categories is large (and/or probabilities have very different values)

## To Reproduce
One of the ways to reproduce (there could be multiple ways to construct adversarial examples):
```
import torch
for ncat in (2**8, 2**22, 2**24):
    probs=torch.empty(ncat) 
    half = ncat//2    
    probs[half:]=1
    probs[:half-1]=2
    out=torch.multinomial(probs, num_samples=10**5, replacement=True) 
    print("number of categories {:10}, number of samples in upper half {:8} ".format(ncat, (out>=half).sum().item())) #would expect 1/3 (~33333) of generated values to be >=half, true for ncat 2**8, 2**22, 0 for ncat 2**24
```
## Additional context

This is due to how multinomial sampling with replacement is implemented - we compute cumsum of the probs values, then normalize the sum to 1 and compute boundaries as cumsum(probs)/sum(probs). If there are many categories (or particularly small probabilities) boundaries will collapse to be the same value. 
We disallow more than 2**24 categories for that reason, but large inaccuracies can start before that. 
Related: #2576



cc @vincentqb @fritzo @neerajprad @alicanb @vishwakftw
Repository: pytorch
Issue: Accessing tensor by element is super slow
Labels: module: performance,triaged

Benchmark:
```python
import torch
import numpy

N = 128

a = torch.zeros((N, N))
b = torch.zeros((N, N))
c = torch.zeros((N, N))
d = numpy.zeros((N, N))
e = numpy.zeros((N, N))
f = numpy.zeros((N, N))

def manual_add(a, b, c):
    for i in range(N):
        for j in range(N):
            a[i,j] = b[i,j] + c[i,j]
            
%timeit manual_add(a, b, c)
%timeit a = b + c
%timeit manual_add(d, e, f)
%timeit d = e + f
```
time
```
232 ms ± 1.69 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)
15.4 µs ± 76.5 ns per loop (mean ± std. dev. of 7 runs, 100000 loops each)
8.25 ms ± 20.9 µs per loop (mean ± std. dev. of 7 runs, 100 loops each)
5.9 µs ± 52.9 ns per loop (mean ± std. dev. of 7 runs, 100000 loops each)
```
It is so bad that manual_add on PyTorch is so much slower than numpy.

cc @VitalyFedyunin @ngimel
Repository: go
Issue: x/tools/gopls: add regression tests for file watching
Labels: Testing,gopls,Tools

Some cases that lack coverage:

- [ ] Moving a declaration to a new file
- [ ] Adding a new declaration to the same file
- [ ] Adding a new declaration a different file
- [ ] Check that closing a buffer clears errors
   * Real-life example: You switch branches with 1 open file in your editor and see errors because that file is now an overlay. You close the file and its errors clear.
Repository: rust
Issue: Thread 'rustc' has overflowed its stack on dumb program
Labels: I-ICE,E-needs-test,T-compiler,C-bug,S-has-mcve

It's me again! Back this time with something that throws a spanner in the works for rustc without it taking multiple hundred gigabytes of memory and several days to compile. It's an Advent of Code challenge once more - and this time I tried to solve everything at compile time with macro abuse and types. [Here](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=4bca3ce00bffd6135a55beedb8dd97ab)'s a small example using the setup I made in the playground (input is on line 181), and [here](https://gist.github.com/AuroransSolis/3dd0fc30e558e3864ee99af814c84422)'s the large example that causes the error (as a gist since it times out in the playground). I have just a little bit of a hunch that `#![recursion_limit="50000"]` basically being required has something to do with the error:
```
auro@auro-desktop ~/projects/aoc_2018_d5_ct $ time cargo run
   Compiling aoc_2018_d5_ct v0.1.0 (/home/auro/projects/aoc_2018_d5_ct)

thread 'rustc' has overflowed its stack
fatal runtime error: stack overflow
error: could not compile `aoc_2018_d5_ct`.

Caused by:
  process didn't exit successfully: `rustc --crate-name aoc_2018_d5_ct --edition=2018 src/main.rs --error-format=json --json=diagnostic-rendered-ansi --crate-type bin --emit=dep-info,link -Cembed-bitcode=no -C debuginfo=2 -C metadata=8d4922b265418474 -C extra-filename=-8d4922b265418474 --out-dir /home/auro/projects/aoc_2018_d5_ct/target/debug/deps -C incremental=/home/auro/projects/aoc_2018_d5_ct/target/debug/incremental -L dependency=/home/auro/projects/aoc_2018_d5_ct/target/debug/deps --extern paste=/home/auro/projects/aoc_2018_d5_ct/target/debug/deps/libpaste-56ec6c5ce13200bb.so` (signal: 6, SIGABRT: process abort signal)
```
I feel like an apology is in order for anyone who tries figuring out what's going wrong here, so: I'm deeply, deeply, sorry.

<!-- TRIAGEBOT_START -->

<!-- TRIAGEBOT_ASSIGN_START -->

<!-- TRIAGEBOT_ASSIGN_DATA_START$${"user":"chansuke"}$$TRIAGEBOT_ASSIGN_DATA_END -->

<!-- TRIAGEBOT_ASSIGN_END -->
<!-- TRIAGEBOT_END -->
Repository: pytorch
Issue: Tracing can leak CUDA memory when using tensor constants
Labels: oncall: jit,months

```
import torch
import gc

from torch.testing._internal.common_cuda import initialize_cuda_context_rng
initialize_cuda_context_rng()

gc.collect()
start = torch.cuda.memory_allocated(0)


def fn(t):
    result = torch.ger(t, torch.tensor([-0.1117, -0.4966,  0.1631, -0.8817,  0.2891,  0.4899, -0.3853, -0.7120,
                                        0.6369, -0.7141, -1.0831, -0.5547, -1.3248,  0.6970, -0.6631,  1.2158,
                                        -2.5273,  1.4778, -0.1696, -0.9919], device='cuda:0'))
    return result


t = torch.randn(20).cuda()
traced = torch.jit.trace(fn, (t,))
traced(t)

del traced
del t

gc.collect()
end = torch.cuda.memory_allocated(0)

print(start)  // prints 0
print(end)    // prints 1024
```

cc @ezyang @gchanan @zou3519 @suo @gmagogsfm
Repository: godot
Issue: Error on startup
Labels: platform:windows,topic:rendering

Please help I'm on Godot version 3.2 and I can't pass the error

It went on like this:

```
0(6) : error C7538:OpenGL doesn't allow "highp" after "inout"
0(35) :error C7538:OpenGL doesn't allow "highp" after "inout"
0(51) : error C7538:OpenGL doesn't allow "highp" after "inout"
0(52) :0(6) : error C7538:OpenGL doesn't allow "highp" after "inout"

At: drivers/gles3/shader_gles.cpp:164
ERROR: get_current_version: Method Failed. Returning: _null
At: drivers/gles3/shader_gles.cpp:347
ERROR: bind: Condition "!version" is true.  Returned:  false
At: drivers/gles3/shader_gles3.cpp:123
ERROR: get_uniform: Condition "!version" is true. Returned:-1
At: drivers/gles3/shader_gles3.cpp:389
ERROR: get_uniform: Condition "!version" is true. Returned:-1
At: drivers/gles3/shader_gles3.cpp:389
ERROR: get_uniform: Condition "!version" is true. Returned:-1
At: drivers/gles3/shader_gles3.cpp:389
ERROR: get_uniform: Condition "!version" is true. Returned:-1
At: drivers/gles3/shader_gles3.cpp:389
ERROR: get_uniform: Condition "!version" is true. Returned:-1
At: drivers/gles3/shader_gles3.cpp:389
ERROR: get_uniform: Condition "!version" is true. Returned:-1
```
Repository: go
Issue: cmd/cgo: cgo + static const int results in "undefined reference" on linux
Labels: help wanted,NeedsInvestigation,compiler/runtime

<!--
Please answer these questions before submitting your issue. Thanks!
For questions please use one of our forums: https://github.com/golang/go/wiki/Questions
-->

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.14.7 linux/amd64
</pre>

### Does this issue reproduce with the latest release?
Have not tried

### What operating system and processor architecture are you using (`go env`)?

<details><summary><code>go env</code> Output</summary><br><pre>
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/root/.cache/go-build"
GOENV="/root/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build954734301=/tmp/go-build -gno-record-gcc-switches"
root@06ba4e8d3414:/go/src/bitbucket.org/threattrack/vipre-mac/foo#
</pre></details>

### What did you do?

<!--
If possible, provide a recipe for reproducing the error.
A complete runnable program is good.
A link on play.golang.org is best.
-->
Linking of a program referring to `static const int` fails with `undefined reference`:

`foo.h`
```
static const int BAR = 1;
```
`foo.go`
```
package main

/*
#include "foo.h"
*/
import "C"
import "fmt"

const (
  BAR = int(C.BAR)
)

func main() {
  fmt.Println(BAR)
}

```
### What did you expect to see?

Compilation succeeds on **linux** as it does on **darwin**

### What did you see instead?

```
go build
/usr/bin/ld: $WORK/b001/_cgo_main.o:/tmp/go-build/cgo-generated-wrappers:2: undefined reference to `BAR'
collect2: error: ld returned 1 exit status
```
Repository: node
Issue: Crash at node::AsyncWrap::QueueDestroyAsyncId(const v8::FunctionCallbackInfo<v8::Value>&)
Labels: async_hooks

* **Version**:
v14.7.0

* **Platform**:
ubuntu 19.04

### What steps will reproduce the bug?

I cannot sure, but for me, It needs repl environment for reproduce.
It's unstable, because of related function called by garbage collector.

![KakaoTalk_20200816_145432145](https://user-images.githubusercontent.com/61380567/90327627-70fc5c80-dfd0-11ea-929b-617b331fe169.png)


### How often does it reproduce? Is there a required condition?
nothing

### What is the expected behavior?
no error

### What do you see instead?
crash

[core.zip](https://github.com/nodejs/node/files/5080063/core.zip)
Repository: pytorch
Issue: Add CutMix transform to torchvision.transforms
Labels: triaged,module: vision

## 🚀 Feature
<!-- A clear and concise description of the feature proposal -->
**CutMix** augmentation strategy: patches are cut and pasted among training images where the ground truth labels are also mixed proportionally to the area of the patches.

## Motivation
<!-- Please outline the motivation for the proposal. Is your feature request related to a problem? e.g., I'm always frustrated when [...]. If this is related to another GitHub issue, please link here too -->

Its seems like this regularization increasing performance on visual tasks.
![img](https://raw.githubusercontent.com/clovaai/CutMix-PyTorch/master/img1.PNG)

## Pitch
<!-- A clear and concise description of what you want to happen. -->
Can you add this transformation into torchvision.transforms?
And if I can somehow help to make it happen, let me know.

## Additional context
<!-- Add any other context or screenshots about the feature request here. -->

Source: [CutMix regularizer implementation for pytorch](https://github.com/clovaai/CutMix-PyTorch)


cc @fmassa @vfdev-5
Repository: rust
Issue: x.py tidy doesn't ignore untracked files
Labels: C-enhancement,T-bootstrap

Tidy exists as an external tool that `x.py` calls, and it has a fixed set of paths that it ignores. Which is unlike other `x.py` commands which ignore untracked files.

This causes problems when some of the ignored paths get moved. eg: as part of https://github.com/rust-lang/rust/commit/2c31b45ae878b821975c4ebd94cc1e49f6073fd0 src/stdarch was moved to library/stdarch.

<details>
<summary>
Error log
</summary>

```
tidy error: /users/a52arora/rust/src/stdarch/ci/android-install-ndk.sh:2: copyright notices attributed to the Rust Project Developers are deprecated
tidy error: /users/a52arora/rust/src/stdarch/ci/android-install-sdk.sh:2: copyright notices attributed to the Rust Project Developers are deprecated
tidy error: /users/a52arora/rust/src/stdarch/ci/android-install-sdk.sh:49: line longer than 100 chars
tidy error: /users/a52arora/rust/src/stdarch/ci/android-sysimage.sh:3: copyright notices attributed to the Rust Project Developers are deprecated
tidy error: /users/a52arora/rust/src/stdarch/ci/run.sh:29: tab character
tidy error: /users/a52arora/rust/src/stdarch/ci/run.sh:30: tab character
```
</details>

On one hand I appreciate this, because it tells me to go remove files that aren't required anymore. But on the otherhand I usually run tests in a detached screen session only to come find tests didn't run because of tidy error due to moved submodules.

I'd prefer if the untracked files were ignored and instead at the end of the build log I got a warning saying "Tidy error in untracked directory/file" or someother way of letting me know that a submodule was moved and I should clean up.
Repository: pytorch
Issue: Non-conforming variable identifiers in JIT code errors / printouts: e.g. "Tensor 0"
Labels: oncall: jit

**UPD**: Original title: "slice(None)  and maybe slice in general is not supported in JIT"
Originally reported in https://github.com/pytorch/pytorch/issues/41625#issuecomment-662064959

```python
def tensor_dim_slice(tensor, dim, dim_slice):
    return tensor[(dim if dim >= 0 else dim + tensor.dim()) * (slice(None), ) + (dim_slice, )]
```
fails torch.jit.script when called from a scripted function:

```
    fn = torch._C._jit_script_compile(qualified_name, ast, _rcb, get_default_args(obj))
  File "/miniconda/lib/python3.7/site-packages/torch/jit/_recursive.py", line 568, in try_compile_fn
    return torch.jit.script(fn, _rcb=rcb)
  File "/miniconda/lib/python3.7/site-packages/torch/jit/__init__.py", line 1290, in script
    fn = torch._C._jit_script_compile(qualified_name, ast, _rcb, get_default_args(obj))
RuntimeError:

slice(Tensor 0) -> (Tensor 0):
Expected a value of type 'Tensor' for argument '0' but instead found type 'None'.
:
  File "/root/convasr/ctc.py", line 45
def tensor_dim_slice(tensor, dim, dim_slice):
        return tensor[(dim if dim >= 0 else dim + tensor.dim()) * (slice(None), ) + (dim_slice, )]
                                                            ~~~~~ <--- HERE
```

Also `Tensor 0` is strange. 

cc @suo @gmagogsfm
Repository: go
Issue: runtime/pprof: panic in appendLocsForStack on fuchsia-arm64
Labels: NeedsInvestigation,OS-Fuchsia,compiler/runtime

We've been seeing this issue for a while; filing this bug now that we've upgraded to go1.15. (See https://fxbug.dev/52575).

This happens sometimes when running the runtime/pprof tests:
```
panic: runtime error: slice bounds out of range [3:2]

goroutine 6 [running]:
runtime/pprof.(*profileBuilder).appendLocsForStack(0x3e93c15c160, 0x3e93c130840, 0x0, 0x8, 0x3e93c0560b0, 0x2, 0x2, 0x0, 0x2, 0x8) 
/b/s/w/ir/x/w/fuchsia/out/not-default/host-tools/goroot/src/runtime/pprof/proto.go:410 +0x5d4
runtime/pprof.(*profileBuilder).build(0x3e93c15c160)
/b/s/w/ir/x/w/fuchsia/out/not-default/host-tools/goroot/src/runtime/pprof/proto.go:365 +0xf4
runtime/pprof.profileWriter(0xb4050418c0, 0x3e93c386030)
/b/s/w/ir/x/w/fuchsia/out/not-default/host-tools/goroot/src/runtime/pprof/pprof.go:813 +0xd4
created by runtime/pprof.StartCPUProfile
/b/s/w/ir/x/w/fuchsia/out/not-default/host-tools/goroot/src/runtime/pprof/pprof.go:784 +0x114
```

There's no diff between Fuchsia's fork and go1.15 in src/runtime/pprof. See https://fuchsia.googlesource.com/third_party/go/+diff/go1.15..master.

Possibly a regression of #35538, related to #37446 and its fix in https://golang.org/cl/221577.

@prattmic