sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: pytorch
Issue: OSError libstdc++.so.6 at import
Labels: needs reproduction,module: binaries,triaged

### 🐛 Describe the bug

I have a fresh virtual environment with pytorch installed from `pip install -r requirements.txt` which contain 
```
tensorly
numpy
torch
torchvision
torchtyping
scipy
opt_einsum
matplotlib
tqdm
prettytable
antares
numba
-e .
```
I then run a simple `import torch` which gives the following output:
```
python3
Python 3.10.6 (main, Aug  1 2022, 20:38:21) [GCC 5.4.0 20160609] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import torch
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/sebwood/workspace/MemSE/.env/lib/python3.10/site-packages/torch/__init__.py", line 201, in <module>
    _load_global_deps()
  File "/home/sebwood/workspace/MemSE/.env/lib/python3.10/site-packages/torch/__init__.py", line 154, in _load_global_deps
    ctypes.CDLL(lib_path, mode=ctypes.RTLD_GLOBAL)
  File "/home/linuxbrew/.linuxbrew/opt/python@3.10/lib/python3.10/ctypes/__init__.py", line 374, in __init__
    self._handle = _dlopen(self._name, mode)
OSError: libstdc++.so.6: cannot open shared object file: No such file or directory
```

### Versions

```
python collect_env.py 
Collecting environment information...
PyTorch version: N/A
Is debug build: N/A
CUDA used to build PyTorch: N/A
ROCM used to build PyTorch: N/A

OS: Ubuntu 20.04.5 LTS (x86_64)
GCC version: (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0
Clang version: Could not collect
CMake version: Could not collect
Libc version: glibc-2.35

Python version: 3.10.6 (main, Aug  1 2022, 20:38:21) [GCC 5.4.0 20160609] (64-bit runtime)
Python platform: Linux-5.10.102.1-microsoft-standard-WSL2-x86_64-with-glibc2.35
Is CUDA available: N/A
CUDA runtime version: Could not collect
GPU models and configuration: GPU 0: NVIDIA GeForce GTX 1650 SUPER
Nvidia driver version: 516.94
cuDNN version: Could not collect
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: N/A

Versions of relevant libraries:
[pip3] numpy==1.23.3
[pip3] torch==1.12.1
[pip3] torchtyping==0.1.4
[pip3] torchvision==0.13.1
[conda] Could not collect
```

cc @seemethere @malfet @osalpekar @atalman @ezyang
Repository: pytorch
Issue: Segmentation fault in mkldnn_reorder_conv2d_weight and mkldnn_reorder_conv3d_weight
Labels: module: crash,triaged,module: mkldnn,module: edge cases

### 🐛 Describe the bug

Segmentation fault in `mkldnn_reorder_conv2d_weight` and  `mkldnn_reorder_conv3d_weight`.

### Example to reproduce

```python
import torch

self = torch.full((3, 3, 1, 1,), 1, dtype=torch.float32, requires_grad=False).to_mkldnn()
padding = []
stride = [65534, 65534]
dilation = [65534, 65534]
groups = 0
torch._C._nn.mkldnn_reorder_conv2d_weight(self, padding, stride, dilation, groups)


import torch

self = torch.full((32, 3, 3, 3, 3,), 1, dtype=torch.float32, requires_grad=False).to_mkldnn()
padding = []
stride = [1250999896764, 1250999896764, 1250999896764]
dilation = [1250999896764, 1250999896764, 1250999896764]
groups = 0
torch._C._nn.mkldnn_reorder_conv3d_weight(self, padding, stride, dilation, groups)
```

### Result
```segmentation fault```

### Expected behavior
Graceful termination or a RuntimeError to be thrown.

### Note
This bug was discovered using fuzz testing.

### Versions

PyTorch version: N/A
Is debug build: N/A
CUDA used to build PyTorch: N/A
ROCM used to build PyTorch: N/A

OS: Debian GNU/Linux 11 (bullseye) (x86_64)
GCC version: (Debian 10.2.1-6) 10.2.1 20210110
Clang version: 11.0.1-2
CMake version: version 3.22.1
Libc version: glibc-2.31

Python version: 3.9.12 (main, Jun  1 2022, 11:38:51)  [GCC 7.5.0] (64-bit runtime)
Python platform: Linux-5.10.0-16-amd64-x86_64-with-glibc2.31
Is CUDA available: N/A
CUDA runtime version: Could not collect
GPU models and configuration: Could not collect
Nvidia driver version: Could not collect
cuDNN version: Could not collect
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: N/A

Versions of relevant libraries:
[pip3] numpy==1.22.3
[pip3] torch==1.11.0a0+gitbc2c6ed
[conda] mkl                       2022.0.1           h06a4308_117
[conda] mkl-include               2022.0.1           h06a4308_117
[conda] numpy                     1.22.3           py39h7a5d4dd_0
[conda] numpy-base                1.22.3           py39hb8be1f0_0
[conda] torch                     1.11.0a0+gitbc2c6ed          pypi_0    pypi

cc @ezyang @gchanan @zou3519 @gujinghui @PenghuiCheng @XiaobingSuper @jianyuh @VitalyFedyunin
Repository: pytorch
Issue: Floating point exception in gather gradient computation.
Labels: module: crash,module: error checking,triaged,module: edge cases

### 🐛 Describe the bug

Floating point exception in `gather` gradient computation.

### Example to reproduce

```python
import torch

grad = torch.full((2, 0, 0, 6, 6,), 0, dtype=torch.float64, requires_grad=True)
self = torch.full((2, 0, 0, 6, 6,), 0, dtype=torch.float64, requires_grad=True)
dim = 0
index = torch.full((2, 0, 0, 6, 6,), 0, dtype=torch.float64, requires_grad=True)
sparse_grad = True
res = torch.gather(self, dim, index, sparse_grad=sparse_grad)
grad_out = torch.zeros_like(res)
torch.autograd.backward(res, grad_tensors=grad_out)
```

### Result
```floating point exception```

### Expected behavior
Graceful termination or a RuntimeError to be thrown.

### Note
This bug was discovered using fuzz testing.

### Versions

PyTorch version: N/A
Is debug build: N/A
CUDA used to build PyTorch: N/A
ROCM used to build PyTorch: N/A

OS: Debian GNU/Linux 11 (bullseye) (x86_64)
GCC version: (Debian 10.2.1-6) 10.2.1 20210110
Clang version: 11.0.1-2
CMake version: version 3.22.1
Libc version: glibc-2.31

Python version: 3.9.12 (main, Jun  1 2022, 11:38:51)  [GCC 7.5.0] (64-bit runtime)
Python platform: Linux-5.10.0-16-amd64-x86_64-with-glibc2.31
Is CUDA available: N/A
CUDA runtime version: Could not collect
GPU models and configuration: Could not collect
Nvidia driver version: Could not collect
cuDNN version: Could not collect
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: N/A

Versions of relevant libraries:
[pip3] numpy==1.22.3
[pip3] torch==1.11.0a0+gitbc2c6ed
[conda] mkl                       2022.0.1           h06a4308_117
[conda] mkl-include               2022.0.1           h06a4308_117
[conda] numpy                     1.22.3           py39h7a5d4dd_0
[conda] numpy-base                1.22.3           py39hb8be1f0_0
[conda] torch                     1.11.0a0+gitbc2c6ed          pypi_0    pypi
Repository: pytorch
Issue: Segmentation fault in native_batch_norm
Labels: module: crash,module: error checking,triaged,module: norms and normalization

### 🐛 Describe the bug

Segmentation fault in `native_batch_norm`.

### Example to reproduce

```python
import torch

input = torch.full((5, 5,), 1, dtype=torch.float64, requires_grad=False)
weight = torch.full((14, 9, 12, 0, 6, 0, 15, 0, 0, 0,), -1.5e+300, dtype=torch.float64, requires_grad=False)
bias = torch.full((5,), 1, dtype=torch.float64, requires_grad=False)
running_mean = torch.full((0,), 1, dtype=torch.float64, requires_grad=False)
running_var = torch.full((0,), 1, dtype=torch.float64, requires_grad=False)
training = True
momentum = 0
eps = 0
torch.native_batch_norm(input, weight, bias, running_mean, running_var, training, momentum, eps)
```

### Result
```segmentation fault```

### Expected behavior
Graceful termination or a RuntimeError to be thrown.

### Note
This bug was discovered using fuzz testing.

### Versions

PyTorch version: N/A
Is debug build: N/A
CUDA used to build PyTorch: N/A
ROCM used to build PyTorch: N/A

OS: Debian GNU/Linux 11 (bullseye) (x86_64)
GCC version: (Debian 10.2.1-6) 10.2.1 20210110
Clang version: 11.0.1-2
CMake version: version 3.22.1
Libc version: glibc-2.31

Python version: 3.9.12 (main, Jun  1 2022, 11:38:51)  [GCC 7.5.0] (64-bit runtime)
Python platform: Linux-5.10.0-16-amd64-x86_64-with-glibc2.31
Is CUDA available: N/A
CUDA runtime version: Could not collect
GPU models and configuration: Could not collect
Nvidia driver version: Could not collect
cuDNN version: Could not collect
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: N/A

Versions of relevant libraries:
[pip3] numpy==1.22.3
[pip3] torch==1.11.0a0+gitbc2c6ed
[conda] mkl                       2022.0.1           h06a4308_117
[conda] mkl-include               2022.0.1           h06a4308_117
[conda] numpy                     1.22.3           py39h7a5d4dd_0
[conda] numpy-base                1.22.3           py39hb8be1f0_0
[conda] torch                     1.11.0a0+gitbc2c6ed          pypi_0    pypi
Repository: godot
Issue: Game is paused when pressing and holdilng close, minimize or maximize buttons of the game window
Labels: platform:windows,discussion,topic:porting

### Godot version

3.5

### System information

Windows

### Issue description

When you press the close /minimize/maximize window buttons but not release it the game is pausing.
The pausing is not expected.

https://user-images.githubusercontent.com/16458555/190872675-70b7698f-8ba0-47dd-8502-49f72f4c90b1.mp4



### Steps to reproduce

Create any project, do something say in _physics_process(), run it, press the close button of the game window but don't release the mouse.
The game process will be paused

### Minimal reproduction project

_No response_
Repository: stable-diffusion-webui
Issue: Implement consistency across all modes: write all parameters/settings to text files AND automatically save all generated images in ALL MODES (including scripts)
Labels: enhancement

**Is your feature request related to a problem? Please describe.**
Yes. Write all parameters/settings (negative prompt isn't being written, for sure) to text files when using the 'Outpainting mk2' script. The settings that are specific to this script aren't written to the text files at all; glad I took a couple screenshots to refer to, but it would be better if that were not necessary.

Additionally, images aren't being automatically saved after generation with the 'Outpainting mk2' script (possibly others as well, but this is what I've been playing with and noticed the problem on). I was messing around with this script for a few hours and finally had some okay results, but for some reason the terminal AND Opera browser froze at one point (both simultaneously became unresponsive), which meant I couldn't save that image manually (I'm not implying that THAT specific image would have been automatically saved, since progress was at 99%, it showed, but also none of the images are automatically saved after generation, overall with this script, so I have to manually click 'save' every time, which I was not aware of immediately, and lost some earlier generations).

**Describe the solution you'd like**
Write all parameters and settings to text files AND always save all generated images for all modes (scripts included)!

**Describe alternatives you've considered**
N/A

**Additional context**
N/A
Repository: rust
Issue: Margin drift in large `these functions exist but are inaccessible` diagnostic
Labels: A-diagnostics,T-compiler

In clippy if you add `check()` somewhere in `clippy_lints` where the function isn't found (e.g. in `clippy_lints/src/lib.rs`) the note will tell you about all the inaccessible functions called `check` of which there are many. That's handy, but there is a rather large margin applied to each function snippet. Starting in the ~middle there's a right to left 'sweep' of a veritcal bar in the multiline snippets

I tried to minimally reproduce this by putting 200/300 `fn check {}`s in their own modules but that didn't seem to work

Here's the output of `cargo check` on https://github.com/rust-lang/rust-clippy/commit/e120fb10c60a27670c72e7ec99e93d16c045f493 after adding `check();` to `clippy_lints/src/lib.rs`: https://gist.github.com/Alexendoo/210cf32bd7e6248431604df767d2d13a
Repository: godot
Issue: Vulkan: 2D msaa does not AA clipped children
Labels: discussion,topic:rendering,topic:2d

### Godot version

4.0 Beta 1

### System information

Shouldn't be system specific. Linux, Vulkan, 1050 Ti nvidia driver v515.65.01

### Issue description

The MSAA, it does nothing for the clipped goggles. Unclipped is on the left for comparison, and the zoomed squares to better show the AA:

![mrp_screenshot](https://user-images.githubusercontent.com/4397725/190875501-c70cc146-aa8f-4e0d-9b71-cefc13362dc2.png)


@Geometror 

The ghosting, darkening, and blending on the clipped version are unrelated to MSAA. See https://github.com/godotengine/godot/issues/49198

clip_children might be better done in some other technical way (one that does not block MSAA hopefully) but I don't know enough to say.

### Steps to reproduce

1. Set up 2D project
2. Enable 2D MSAA x8 in project settings
3. Create any canvasitem node (sprite or polygon)
4. Create a polygon (or line) node as a child of previous step, enable clip_children on said parent
5. Run scene, the parent will have AA but the child will not

Note on step 4: I imagine a sprite could have the same issue, but polygons are an easier way to create something that needs AA (and they need AA always, whereas sprites can be smoothed if you can use transparency).

### Minimal reproduction project

[clip_msaa_mrp.zip](https://github.com/godotengine/godot/files/9592571/clip_msaa_mrp.zip)

(screenshot above is what the MRP is)
Repository: PowerToys
Issue: PTRun Windows Search plugin, show erroneous non-indexed warning 
Labels: Issue-Bug,Product-PowerToys Run,Priority-2

### Microsoft PowerToys version

0.62.1

### Running as admin

- [X] Yes

### Area(s) with issue?

PowerToys Run

### Steps to reproduce

I don't understand the logic for when to show the warning:

![image](https://user-images.githubusercontent.com/4396667/190876037-2789b917-c268-4197-957c-a35c346b6ab5.png)

My files are indexed and enhanced mode is not on:
![image](https://user-images.githubusercontent.com/4396667/190875681-a1a2406a-a0c9-495e-a07c-51883d6ebec2.png)


### But the flags that control this depend on number of drives, enhanced mode, and a flag to show the warning or not. If you have more than one drive, enhanced off AND warning off, you get the warning. 

```
        // To display the drive detection warning only when enhanced mode is disabled on a system which has multiple drives.
        // Currently the warning would not be displayed if the enhanced mode is disabled when the user system has only a single fixed drive. However, this warning may be added in the future.
        // This warning can be disabled by checking the disabled drive detection warning checkbox in settings.
        public bool DisplayWarning()
        {
            return !(IsDriveDetectionWarningCheckBoxSelected || IsEnhancedModeEnabled || (_driveHelper.GetDriveCount() == 1));
        }
```
![image](https://user-images.githubusercontent.com/4396667/190875557-7aa98f85-bdf6-4544-a613-6f559148af05.png)



### Also, I check the index and it looks like it's up to date:
![image](https://user-images.githubusercontent.com/4396667/190875949-8fd2df24-87f3-4c47-a2ad-d383b2c2fcfd.png)


@Alekhya, can you help?

I think we should (for now) just always hide the warning. If we feel the warning is need for non-indexed file we should base the need for the warning on the actual status of the index. Which I think we can get with the SearchAPI. 




### ✔️ Expected Behavior

It should only show the warning message if configured to show AND the index is really incomplete and has pending items to index.

### ❌ Actual Behavior

It seems to show the message a "random" time. 

### Other Software

_No response_
Repository: godot
Issue: Vulkan: SDFGI rendering exhibits glitches (black rectangles)
Labels: bug,topic:rendering,needs testing,topic:3d

### Godot version

4.0.beta1

### System information

Windows 10, Vulkan, GTX 750 Ti 516.94

### Issue description

Hi, I'm not a pro user, I'm just playing and testing stuff in Godot but in beta version, when I import my 3d model and I selected SDFGI, After a while, suddenly everything got messed up, and I saw something like this:
![Screenshot (64)](https://user-images.githubusercontent.com/110334096/190876383-cba2d98e-657f-4dd1-ba9d-89cbf51422a3.png)
I don't know what exactly happening, but after second try It's also effecting the interface of software, like I can't even saw options!:
![Screenshot (67)](https://user-images.githubusercontent.com/110334096/190876523-39521cff-8e15-46ab-a44e-8afd36b0f071.png)


PS: This problem is not showing always! 

### Steps to reproduce

Import 3d model
select SDFGI


### Minimal reproduction project

_No response_
Repository: godot
Issue: C# - Cannot set `Variant` as value of Dictionary
Labels: bug,topic:dotnet

### Godot version

v4.0.beta1.mono.official [4ba934bf3]

### System information

Windows 11 21H2 (OS Build 22000.978)

### Issue description

When trying to set the value of a `Godot.Collections.Dictionary` to a `Godot.Variant.Type` value (`ulong`), see line 3:

```
var d = new Godot.Collections.Dictionary();
d.Add("name", "property_name");
d.Add("type", Variant.Type.String);
```

it produces the following error:

`Argument type 'Godot.Variant.Type' is not assignable to parameter type 'Godot.Variant'`

I would expect an implicit conversion.

### Steps to reproduce

1. Create a new C# Class
2. Create a method containing the following code:
```
var d = new Godot.Collections.Dictionary();
d.Add("name", "property_name");
d.Add("type", Variant.Type.String);
```


### Minimal reproduction project

[variant-repro.zip](https://github.com/godotengine/godot/files/9592716/variant-repro.zip)
Repository: rust
Issue: Don't suggest feature-gated paths on stable
Labels: C-enhancement,A-diagnostics,A-stability,T-compiler

This might well be a duplicate, but I couldn't find an existing bug.  I ran into this with `c_int`.

[Given the following program:](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=ceccee586bd86293bf6fee500ebdc17d)
```rust
fn main() {
    let _: c_int;
}
```
The output (with no dependencies) is
```
 --> src/main.rs:2:12
  |
2 |     let _: c_int;
  |            ^^^^^ not found in this scope
  |
help: consider importing one of these items
  |
1 | use core::ffi::c_int;
  |
1 | use std::os::raw::c_int;
```

Ideally the output should look like:
```
 --> src/main.rs:2:12
  |
2 |     let _: c_int;
  |            ^^^^^ not found in this scope
  |
help: consider importing one of these items
  |
1 | use std::os::raw::c_int;
```
[as `core::ffi::c_int` is unstable:](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=4e3535507fe31a7a0ebced0e601bcc45)
```rust
use core::ffi::c_int;
fn main() {
    let _: c_int;
}
```
Output:
```
error[E0658]: use of unstable library feature 'core_ffi_c'
 --> src/main.rs:1:5
  |
1 | use core::ffi::c_int;
  |     ^^^^^^^^^^^^^^^^
  |
  = note: see issue #94501 <https://github.com/rust-lang/rust/issues/94501> for more information

error[E0658]: use of unstable library feature 'core_ffi_c'
 --> src/main.rs:3:12
  |
3 |     let _: c_int;
  |            ^^^^^
  |
  = note: see issue #94501 <https://github.com/rust-lang/rust/issues/94501> for more information

For more information about this error, try `rustc --explain E0658`.
```
Stable compiler version 1.63.0.  This particular example works on Beta and Nightly, but presumably there are or will be other things in the standard library with a stable path and an unstable path.
Repository: godot
Issue: GDScript - Static typed String/StringName with type checking will result an error
Labels: discussion,topic:gdscript

### Godot version

v4.0.beta1.official [20d667284]

### System information

It's not system specific error.

### Issue description

If it is cast implicitly, it would work in all cases, but it seems that in some cases the conversion between String and StringName does not match the actual type.
I think the type check is not working properly. By the way, casting by `as` worked well.

### Steps to reproduce

1. Assign `StringName` value to statically typed `String` var

or

1. Assign `String` value to statically typed `StringName` var
2. Checking the type with `is`
3. An error is displayed: `Expression is of type blabla so it can't be of type blabla`

### Minimal reproduction project

```GDScript
func _ready():
	var istr1 = StringName("bbb")
	var mstr1 = String(istr1)
	print(istr1 is String)
	print(istr1 is StringName)
	print(mstr1 is String)
	print(mstr1 is StringName)

	var mstr2 = String("ddd")
	var istr2 = StringName(mstr2)
	print(istr2 is String)
	print(istr2 is StringName)
	print(mstr2 is String)
	print(mstr2 is StringName)

	var istr3 = StringName("ccc")
	var mstr3: String = istr3 # assignable
	print(istr3 is String)
	print(istr3 is StringName)
	print(mstr3 is String)
	#print(mstr3 is StringName) # but edit time error

	var mstr4 = String("eee")
	var istr4: StringName = mstr4 # assignable
	#print(istr4 is String) # but same error
	print(istr4 is StringName)
	print(mstr4 is String)
	print(mstr4 is StringName)
```
Repository: rust
Issue: Rename sysroot directories to be more clear
Labels: E-mentor,T-bootstrap,E-medium,S-blocked,A-contributor-roadblock

These are effectively user facing because they're used for `rustup link`. So far this has worked reasonably well, but after https://github.com/rust-lang/rust/issues/101691 `stage0-sysroot` will become user facing as well, at which point it will become extremely confusing that there's both that and `stage0`.

I suggest renaming `stage0` to `bootstrap-sysroot`, keeping stage0-sysroot as is and renaming stage1 to stage1-sysroot.

cc @bjorn3 @mark-simulacrum

_Originally posted by @jyn514 in https://github.com/rust-lang/rust/issues/101691#issuecomment-1243988456_

<!-- TRIAGEBOT_START -->

<!-- TRIAGEBOT_ASSIGN_START -->

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

<!-- TRIAGEBOT_ASSIGN_END -->
<!-- TRIAGEBOT_END -->
Repository: godot
Issue: Copy & pasting nodes into a child scene with "Editable Children" does not work correctly
Labels: bug,topic:editor,confirmed

### Godot version

3.5.stable

### System information

Linux. OpenGL ES 3.0. AMD Radeon RX 6700 XT

### Issue description

I have a child scene with "Editable Children" and I can create new nodes within the child scene via the parent scene.

What does not work is pasting a node into the expanded child scene.

What looks to happen is that it thinks the pasted node is actually inherited from the child scene and doesn't actually create the copied node into the parent scene. I think this because it appears grey like the other inherited nodes. It also does not save. If you close and reopen the parent scene the pasted node is lost. It is also lost if you run the project.

### Steps to reproduce


Copy the Light2D
![image](https://user-images.githubusercontent.com/3792060/190881704-e4e54d8c-ed7b-4aa0-9c29-de104788f9b9.png)

Paste it into one of the inherited nodes
![image](https://user-images.githubusercontent.com/3792060/190881802-82af474f-87b5-4ec1-9744-709f07f20b4d.png)


### Minimal reproduction project

[EditableChildrenCopyPasteMRP.zip](https://github.com/godotengine/godot/files/9592886/EditableChildrenCopyPasteMRP.zip)