sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: pytorch
Issue: Abort Caused by Virtual Function
Labels: module: build,triaged,module: regression

### 🐛 Describe the bug

`Abort` happens when PyTorch releasing its resources (i.e., when Python terminates) in

```cpp
 struct TORCH_API OperatorKernel : public c10::intrusive_ptr_target {
-  // Abort triggered.
-  ~OperatorKernel() override = default;
+  // Old thing works well.
+  virtual ~OperatorKernel() = default;
 };
```

After reverting `f172feae0d6e6e510d2133ed10dd76dbcaf0f0fe` (#93069), it works again. My build command is `DEBUG=1 VERBOSE=1 USE_KINETO=0 TORCH_CUDA_ARCH_LIST="7.0;7.2" PATH=/cuda-11.8/lib64:/cuda-11.8/include:/cuda-11.8/bin:$PATH CUDACXX=/cuda-11.8/bin/nvcc ONNX_NAMESPACE=onnx1 BUILD_SHARED_LIBS=1 BUILD_CAFFE2=0 BUILD_CAFFE2_OPS=0 USE_GLOO=1 USE_NCCL=0 USE_NUMPY=1 USE_OBSERVERS=1 USE_OPENMP=1 USE_DISTRIBUTED=1 USE_MPI=1 BUILD_PYTHON=1 USE_MKLDNN=0 USE_CUDA=1 BUILD_TEST=1 USE_FBGEMM=1 USE_NNPACK=1 USE_QNNPACK=0 USE_XNNPACK=1 python3 setup.py develop 2>&1 | tee build.log`.

### Versions

Latest master branch.

cc @malfet @seemethere
Repository: godot
Issue: 3D model deforms when playing animations in Godot 4
Labels: bug,topic:rendering,topic:import

### Godot version

4.0.rc1

### System information

Windows 10, Vulkan, NVIDIA GeForce GTX 1060 6GB driver version: 27.21.14.5751

### Issue description

When opening a glb. file exported from Blender, the animation works correctly on multiple versions of Godot 3, but deforms in Godot 4. 
I tried changing some exporting settings in Blender and import settings in Godot, but nothing helped. 
![issue_2](https://user-images.githubusercontent.com/91782210/217948411-8043b4f8-4fcc-42f1-ae7d-7db97e1328a4.png)
![issue_1](https://user-images.githubusercontent.com/91782210/217948415-054005d8-ca7b-45fb-b532-5120ebe3a00e.png)


### Steps to reproduce

1. Open the model as a new inherited scene
2. Play the animation


### Minimal reproduction project

[Issue_project.zip](https://github.com/godotengine/godot/files/10701889/Issue_project.zip)
Repository: go
Issue: path/filepath: reject Windows volume names containing `..` components
Labels: OS-Windows,NeedsInvestigation

(New issue branching off discussion on #56336.)

https://go.dev/cl/444280 changed Windows volume name detection to be more accurate, correctly detecting a number of previously unrecognized volume name prefixes such as `\\.\?\UNC\a\b`. (Yes, that's a valid volume name.)

This change also results in us treating some invalid filenames as containing a prefix. For example, `\\` is not a valid Windows filename, but we now consider it to have a `\\` volume name on the grounds that preserving the semantically-significant `\\` prefix is better than ignoring it.

A consequence of this change is that on Windows `filepath.Clean` can produce a path that can contain `..` elements. For example, `filepath.Clean("//../../a")` is `\\..\..\a`. I'm not sure if `\\..\..` is a valid Windows volume name or not, but a consequence of this is that code like

```go
// Incorrect: Please do not write this.
path = filepath.Join(root, filepath.Clean("/" + slashSeparatedPath))
```

can produce a result that escapes the intended root when `slashSeparatedPath` is something like `/../../foo`.

While this code should be written as something like

```go
// Using path.Clean rather than filepath.Clean avoids applying Windows volume semantics to the input path.
path = filepath.Join(root, path.Clean("/" + slashSeparatedPath))
```

we can still do a better job of defending against vulnerabilities caused by this misuse of `filepath.Clean` by rejecting volume names that contain `..` as a component. So far as I know, `..` never appears in Windows volume names.

Concretely:

```
filepath.Clean(`\\..\..\a`) = `\a`
filepath.VolumeName(`\\..\..\a`) = ``
```
Repository: stable-diffusion-webui
Issue: [Feature Request]: parallelize batch upscaling
Labels: enhancement

### Is there an existing issue for this?

- [X] I have searched the existing issues and checked the recent builds/commits

### What would your feature do ?

Upscale huge batches of images faster by feeding multiple images to the upscaler nets such as esrgan or swinrl in increased batch sizes directly.

Right now, the upscalers process only a single image at the time and it's a huge loss of time accumulating for large sequences, for example, Deforum's output videos.

For comparison, upscalers eta for ~1 min Deforum videos reaches around 1h, meanwhile Topaz video (where upscalers are obviously parallelized, if not run on multiple gpus) has only ~5 mins.

### Proposed workflow

1. Go to extras/launch upscalers from an extension using scripts api
2. Select desired params.
3. Select the batch size that fits in your GPU. (esp with SD unloaded from memory)
4. Press generate
5. ...
6. Profit! The process should be much faster now


### Additional information

_No response_
Repository: go
Issue: proposal: io: allocate copy buffers from a pool
Labels: Proposal

https://go.dev/cl/456555 changed `io.Copy` to allocate its copy buffers from a `sync.Pool`. This exposed a race condition in the HTTP/2 `ResponseWriter` #58446, which can be fixed, but I'm taking this as a sign that any change should be made more judiciously; https://go.dev/cl/467095 will revert that change.

`io.Copy`, prior to CL 456555, allocates a 32k `[]byte` buffer (or a smaller one if the source is an `*io.LimitedReader` with a size less than 32k). Allocating these buffers from a pool reduces GC allocations and notably improves `io.Copy` performance; see benchmarks in that CL's description. The `net/http` package maintains its own pool of copy buffers for this reason. Having every package that uses `io.Copy` maintain its own buffer pool seems unfortunate.

If the destination of a `Copy` retains the buffer passed to the `Write` call after returning, this results in a race condition where the buffer may be recycled through the pool while the `Write` is still in progress. This behavior is a violation of the `io.Writer` contract, but as #58446 demonstrates, this does happen in practice.

Perhaps we should start by detecting `io.Writer`s that retain the buffer. When the race detector is enabled, `io.Copy` could write over the copy buffer after each call to `Write`. This will help the race detector to identify cases where another goroutine continues to access the buffer, as well as invalidating the buffer contents. https://go.dev/cl/466865 contains this change.
Repository: godot
Issue: Less strict design for typed arrays
Labels: discussion,topic:gdscript

Currently typed arrays do work: there should be no memory corruptions, unexpected overwrites on variable assignments, unexpected inferred element types and so on. But they do so in a very strict manner, a typed array has a type info during runtime and any potential element of the array is tested for a match with the type. It allows to speed up type safe read access - `var a: int = ints[i]` - since an element type is guaranteed a type check can be skipped on such assignment. But it comes with the cost of performance for writing and, more importantly, with loss of flexibility of types.

Inflexibility comes from a need to have all type info present at runtime, from how those types are represented and from underlying incompatibility between typed and untyped arrays. Some examples of such problems:

1) Inability to specify deep nested element type - `Array[Array[int]]`. Right now this is only about arrays, but then other built-in types can get type parameters and the limitation will be more clear.
2) Should `array.map(to_int)` return a typed array or not? That's a choice and because with current design they are incompatible it will always lead to clumsiness in some cases.
3) Should typed arrays with different typed but same elements be considered equal and have the same hash or not? Again, that's a choice and strong incompatibility can be ignored but will lead to inconsistent behavior.
4) Same array literal produces incompatible types depending on context. Which creates confusion for users.

Those problems would go away with more relaxed design. Instead of storing type information in the array itself keep type enforcement only to usage sites.

So, yes, the type will become less enforced:
```gdscript
var ints: Array[int] = []
var untyped: Variant = ints
var strings: Array[String] = untyped
```
Assignment of `untyped` to `strings` will not lead to an error by itself (like right now) but any consequent place where an element will be accessed and its type will be expected to be a string will produce an error. And with properly typed code many wrong assignments will still be caught during the analysis - so `strings = ints` will not need to get to runtime to see the problem.

Maybe it is too late to have a discussion about such change since the release candidate is here, but at least it should be noted that there was such possibility.
Repository: stable-diffusion-webui
Issue: [Bug]: error when training embedding
Labels: bug-report

### Is there an existing issue for this?

- [X] I have searched the existing issues and checked the recent builds/commits

### What happened?

Applying cross attention optimization (Doggettx).
Training at rate of 0.05 until step 25000
Preparing dataset...
100%|██████████████████████████████████████████████████████████████████████████████████| 10/10 [00:01<00:00,  5.29it/s]
  0%|                                                                                         | 0/5891 [00:00<?, ?it/s]Traceback (most recent call last):
  File "F:\sd\modules\textual_inversion\textual_inversion.py", line 506, in train_embedding
    scaler.step(optimizer)
  File "F:\sd\venv\lib\site-packages\torch\cuda\amp\grad_scaler.py", line 336, in step
    assert len(optimizer_state["found_inf_per_device"]) > 0, "No inf checks were recorded for this optimizer."
AssertionError: No inf checks were recorded for this optimizer.

Applying cross attention optimization (Doggettx).

### Steps to reproduce the problem

1. just train embedding

It happens randomly but when it happens its hard to get it working, and i have no clue why its happening so no idea how to make it go away
im on win10 gtx 1080ti

### What should have happened?

it should train normally cause it trained seconds ago

### Commit where the problem happens

https://github.com/AUTOMATIC1111/stable-diffusion-webui/commits/master

### What platforms do you use to access the UI ?

Windows

### What browsers do you use to access the UI ?

Google Chrome

### Command Line Arguments

```Shell
none
```


### List of extensions

none

### Console logs

```Shell
none
```


### Additional information

_No response_
Repository: flutter
Issue: [Deeplink Automation] Deeplink web validation tool
Labels: c: proposal,d: devtools,P2,team-framework,triaged-framework

As described in internal design doc [go/flutter-deeplink-web-validator](http://goto.google.com/flutter-deeplink-web-validator) (non-public accessible)

The tool should be in devtool. The tool is to use ALVS and ULVS to validate web file integrity.
Repository: svelte
Issue: Danger suggestion in basic recommendations
Labels: awaiting submitter

### Describe the bug

When you have `<video>` tag in your component we have suggestion to add `<track>` inside as recommended.
But from [support table at MDN](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/track) you can find that Safari doesn't support `<track>` Actually WebRTC video doesn't work in safari if you have `<track>` inside.

### Reproduction

Unfortunately don't have now. Already fixed on prod

### Expected behaviour

Remove that recommendation, or say that it's dangerous to use it in svelte.

### System Info

- OS: Safari 16

### Which package is the issue about?

svelte-check

### Additional Information, eg. Screenshots

_No response_
Repository: godot
Issue: OpenXR: Requested OpenGL version does not meet the minimum version
Labels: discussion,topic:xr

### Godot version

4.0.rc1

### System information

win 11 , hp-reverb-g2

### Issue description

When running a simplest VR app, this output is shown. I dont know if it is bad/good  , but as i dont know , if my app is running correct because of this output, i think its a kind of a bug :)

I use win 11, hp-reverb-g2 VR headset, wmr and steamvr set to use openxr


here the output:

--- Debugging process started ---
Godot Engine v4.0.rc.custom_build.630dd191c - https://godotengine.org
OpenXR: Running on OpenXR runtime:  SteamVR/OpenXR   0.1.0
OpenGL API 3.3.0 NVIDIA 522.06 - Compatibility - Using Device: NVIDIA Corporation - NVIDIA GeForce RTX 3080 Laptop GPU
 
OpenXR: Requested OpenGL version does not meet the minimum version this runtime supports.
- desired_version  3.3.0
- minApiVersionSupported  4.3.0
- maxApiVersionSupported  4.6.0
OpenXR: Trying to initialize with OpenGL anyway...
openxr is init
--- Debugging process stopped ---

### Steps to reproduce

simplest VR app with win 11 and hp-reverb-g2

### Minimal reproduction project

above
Repository: node
Issue: Confused setTimout behaviour in NodeJS
Labels: timers

### Version

14, 18

### Platform

22.2.0 Darwin Kernel arm64

### Subsystem

_No response_

### What steps will reproduce the bug?

```js
setTimeout(() => {
  console.log('calling 1st timeout')
}, 1)

setTimeout(() => {
  console.log('calling 2rd timeout')
}, 0)

// in nodejs
// calling 1st timeout
// calling 2rd timeout

// however, in chrome browser
// calling 2rd timeout
// calling 1st timeout
```

### How often does it reproduce? Is there a required condition?

_No response_

### What is the expected behavior?

Would expect the second time to be called first

### What do you see instead?

The first time out is called then the second timeout in NodeJS

### Additional information

_No response_
Repository: vscode
Issue: Task problemMatcher with fileLocation method set to "search" only seems to work for background task
Labels: bug,tasks

VSCode Version: 1.75.0
OS Version: Linux x64 3.10.0-1160.31.1.el7.x86_64

Following config does not seem to work for me
```            
            "problemMatcher": {
                "owner": "build_error",
                "fileLocation": [
                    "search",
                    {
                        "include": [
                            "${workspaceFolder}"
                        ],
                        "exclude": []
                    }
                ],
                "pattern": {
                    "regexp": "^(.*):(\\d+):(\\d+):\\s+(warning|error):\\s+(.*)$",
                    "file": 1,
                    "line": 2,
                    "column": 3,
                    "severity": 4,
                    "message": 5,
                    "kind": "location"
                },
```

It's not an issue with the regexp since the same pattern works if I set "fileLocation" to "absolute" or "relative" (Of course without being able to go to the appropriate location since the filename matches are neither absolute nor relative).

However changing the task to background (even though the task is not a continuously running task), and adding background patterns to simply match the first and last line of the output suddenly works.

```
            "isBackground": true,
            "problemMatcher": {
                "owner": "build_error",
                "fileLocation": [
                    "search",
                    {
                        "include": [
                            "${workspaceFolder}"
                        ],
                        "exclude": []
                    }
                ],
                "pattern": {
                    "regexp": "^(.*):(\\d+):(\\d+):\\s+(warning|error):\\s+(.*)$",
                    "file": 1,
                    "line": 2,
                    "column": 3,
                    "severity": 4,
                    "message": 5,
                    "kind": "location"
                },
                "background": {
                    "activeOnStart": true,
                    "beginsPattern": "^Error starts$",
                    "endsPattern": "^Error ends$"
                }
```
Repository: rust
Issue: ran into known ICE issue#84970
Labels: I-ICE,T-compiler,C-bug

<!--
Thank you for finding an Internal Compiler Error! 🧊  If possible, try to provide
a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for
how to create smaller examples.
http://blog.pnkfx.org/blog/2019/11/18/rust-bug-minimization-patterns/
-->

I got a [known internal compiler error](https://github.com/rust-lang/rust/issues/84970) and it asked me to make a bug report. I am not sure how to reduce the code, so i I'm going to link commits on a repository and upload zip files of the target directory with and without the change that caused the ICE. (I believe the target directories could be of help because it said this is an issue with incremental compilation)

in this commit:
https://github.com/gardrek/sayre-ws/commit/f970dc6d1325f5ce8ec0e7c402b1045d95655d7b

it builds fine with the target dir in `before_ice.zip`

but then change vector.rs by removing lines 20 through 27 (functions `new_2d` and `new_3d`) and try to build and you end up with a compiler error (and get the target dir in `after_ice.zip`)

this commit has that change:
https://github.com/gardrek/sayre-ws/commit/d29cb4e1bc55a6f638fc42826e63360d8255491d

target directory with no ice:
[after_ice.zip](https://github.com/rust-lang/rust/files/10703058/after_ice.zip)

target directory after getting ice:
[before_ice.zip](https://github.com/rust-lang/rust/files/10703060/before_ice.zip)

### Code

no ice:
https://github.com/gardrek/sayre-ws/commit/f970dc6d1325f5ce8ec0e7c402b1045d95655d7b

ice:
https://github.com/gardrek/sayre-ws/commit/d29cb4e1bc55a6f638fc42826e63360d8255491d


### Meta
<!--
If you're using the stable version of the compiler, you should also check if the
bug also exists in the beta or nightly versions.
-->

`rustc --version --verbose`:
```
rustc 1.67.1 (d5a82bbd2 2023-02-07)
binary: rustc
commit-hash: d5a82bbd26e1ad8b7401f6a718a9c57c96905483
commit-date: 2023-02-07
host: x86_64-unknown-linux-gnu
release: 1.67.1
LLVM version: 15.0.6
```

### Error output

[error_log.txt](https://github.com/rust-lang/rust/files/10703057/error_log.txt)


<!--
Include a backtrace in the code block by setting `` in your
environment. E.g. `RUST_BACKTRACE=1 cargo build`.
-->
<details><summary><strong>Backtrace</strong></summary>
<p>

[error_log_with_backtrace.txt](https://github.com/rust-lang/rust/files/10703078/error_log_with_backtrace.txt)

</p>
</details>
Repository: godot
Issue: Setting Window.current_screen fails to change the current screen in fullscreen
Labels: bug,platform:linuxbsd

### Godot version

v4.0.rc1.official [8843d9ad3]

### System information

archlinux 5.18.9-zen1-1-zen x86_64 Advanced Micro Devices, Inc. [AMD/ATI] Ellesmere Micro-Star International Co., Ltd. [MSI] Radeon RX 580 Armor 4G OC amdgpu

### Issue description

When setting Window.current_screen in fullscreen mode to another screen, it ignores the call and does not change current_screen.

### Steps to reproduce

1. Create a project and add a node with a script.
2. Set the project in projects settings to either fullscreen mode.
3. In the created node's _ready method put `get_viewport().get_window().current_screen = 1` if you have a second monitor.
4. Run project, notice game does not move to the second screen and `get_viewport().get_window().current_screen` still returns 0.

### Minimal reproduction project

[FullscreenFailureTest.zip](https://github.com/godotengine/godot/files/10703364/FullscreenFailureTest.zip)
Repository: go
Issue: crypto/ecdsa: GenerateKey infinite loop/reader EOF with all zero reader
Labels: NeedsInvestigation

<!--
Please answer these questions before submitting your issue. Thanks!
-->

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.20 darwin/amd64
</pre>

### Does this issue reproduce with the latest release?
Yes


### What operating system and processor architecture are you using (`go env`)?

<details><summary><code>go env</code> Output</summary><br><pre>
$ go env
GO111MODULE="on"
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/user/Library/Caches/go-build"
GOENV="/Users/user/Library/Application Support/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/user/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/user/go"
GOPRIVATE=""
GOPROXY="direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GOVCS=""
GOVERSION="go1.20"
GCCGO="gccgo"
GOAMD64="v1"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/user/workplace/aws-sdk-go-v2/go.mod"
GOWORK=""
CGO_CFLAGS="-O2 -g"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-O2 -g"
CGO_FFLAGS="-O2 -g"
CGO_LDFLAGS="-O2 -g"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -arch x86_64 -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/bl/1vrx92z52vlbnzw22s5_vv9nfc7g3n/T/go-build2434718469=/tmp/go-build -gno-record-gcc-switches -fno-common"
</pre></details>

### What did you do?
Ran tests on a package after upgrading to Go 1.20. It had a test passing a reader with all zero bytes to GenerateKey. I've distilled it down to two examples in the Go playground:
* [EOF](https://go.dev/play/p/2u_XoVvbxVO)
* [Infinite Loop](https://go.dev/play/p/QEDecfQWv27)

### What did you expect to see?
In 1.19, the call succeeded. The new code in 1.20 has tests to reject this, so perhaps an appropriate error after a certain number of loops/bytes read? This is a highly unlikely scenario, but figured it was probably worth at least reporting.

### What did you see instead?
With a limited reader, I receive "unexpected EOF", since it hits the end of the reader. With a reader that keeps returning data, an infinite loop happens.