sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: pytorch
Issue: Segmentation fault in _remove_batch_dim
Labels: needs reproduction,triaged,module: vmap

### 🐛 Describe the bug

Segmentation fault in `_remove_batch_dim`.

### Example to reproduce

```python
import torch

self = torch.full((5, 5, 5, 5, 5,), 1, dtype=torch.float64, requires_grad=False)
level = 0
batch_size = 0
out_dim = 1250999896764
torch._remove_batch_dim(self, level, batch_size, out_dim)
```

### Result
```segmentation fault```

### Expected behavior
Graceful termination or a RuntimeError to be thrown.

### Note
This bug was discovered using IvySyn, a fuzz testing tool which is currently being developed at Secure Systems Labs at Brown University.

### Versions

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.18.4
Libc version: glibc-2.31

Python version: 3.9.7 (default, Sep 16 2021, 13:09:58)  [GCC 7.5.0] (64-bit runtime)
Python platform: Linux-5.10.0-11-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.0
[pip3] torchaudio==0.11.0
[pip3] torchvision==0.12.0
[conda] blas                      1.0                         mkl
[conda] cpuonly                   2.0                           0    pytorch
[conda] ffmpeg                    4.3                  hf484d3e_0    pytorch
[conda] mkl                       2021.4.0           h06a4308_640
[conda] mkl-service               2.4.0            py39h7f8727e_0
[conda] mkl_fft                   1.3.1            py39hd3c417c_0
[conda] mkl_random                1.2.2            py39h51133e4_0
[conda] numpy                     1.21.2           py39h20f2e39_0
[conda] numpy-base                1.21.2           py39h79a1101_0
[conda] pytorch                   1.11.0              py3.9_cpu_0    pytorch
[conda] pytorch-mutex             1.0                         cpu    pytorch
[conda] torchaudio                0.11.0                 py39_cpu    pytorch
[conda] torchvision               0.12.0                 py39_cpu    pytorch

cc @zou3519
Repository: pytorch
Issue: Floating point exception in channel_shuffle
Labels: triaged,release notes: python_frontend

### 🐛 Describe the bug

Floating point exception in `channel_shuffle`.

### Example to reproduce

```python
import torch

self = torch.empty((0, 3, 8, 0, 6,), dtype=torch.float64)
groups = 1
torch.channel_shuffle(self, groups)
```

### Result
```floating point exception```

### Expected behavior
Graceful termination or a RuntimeError to be thrown.

### Note
This bug was discovered using IvySyn, a fuzz testing tool which is currently being developed at Secure Systems Labs at Brown University.

### Versions

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.18.4
Libc version: glibc-2.31

Python version: 3.9.7 (default, Sep 16 2021, 13:09:58)  [GCC 7.5.0] (64-bit runtime)
Python platform: Linux-5.10.0-11-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.0
[pip3] torchaudio==0.11.0
[pip3] torchvision==0.12.0
[conda] blas                      1.0                         mkl
[conda] cpuonly                   2.0                           0    pytorch
[conda] ffmpeg                    4.3                  hf484d3e_0    pytorch
[conda] mkl                       2021.4.0           h06a4308_640
[conda] mkl-service               2.4.0            py39h7f8727e_0
[conda] mkl_fft                   1.3.1            py39hd3c417c_0
[conda] mkl_random                1.2.2            py39h51133e4_0
[conda] numpy                     1.21.2           py39h20f2e39_0
[conda] numpy-base                1.21.2           py39h79a1101_0
[conda] pytorch                   1.11.0              py3.9_cpu_0    pytorch
[conda] pytorch-mutex             1.0                         cpu    pytorch
[conda] torchaudio                0.11.0                 py39_cpu    pytorch
[conda] torchvision               0.12.0                 py39_cpu    pytorch
Repository: pytorch
Issue: Floating point exception in native_channel_shuffle
Labels: triaged,release notes: python_frontend

### 🐛 Describe the bug

Floating point exception in `native_channel_shuffle`.

### Example to reproduce

```python
import torch

self = torch.full((0, 0, 9, 15, 0, 0, 0, 0, 0, 8,), 1, dtype=torch.int64, requires_grad=False)
groups = 0
torch.native_channel_shuffle(self, groups)
```

### Result
```floating point exception```

### Expected behavior
Graceful termination or a RuntimeError to be thrown.

### Note
This bug was discovered using IvySyn, a fuzz testing tool which is currently being developed at Secure Systems Labs at Brown University.

### Versions

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.18.4
Libc version: glibc-2.31

Python version: 3.9.7 (default, Sep 16 2021, 13:09:58)  [GCC 7.5.0] (64-bit runtime)
Python platform: Linux-5.10.0-11-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.0
[pip3] torchaudio==0.11.0
[pip3] torchvision==0.12.0
[conda] blas                      1.0                         mkl
[conda] cpuonly                   2.0                           0    pytorch
[conda] ffmpeg                    4.3                  hf484d3e_0    pytorch
[conda] mkl                       2021.4.0           h06a4308_640
[conda] mkl-service               2.4.0            py39h7f8727e_0
[conda] mkl_fft                   1.3.1            py39hd3c417c_0
[conda] mkl_random                1.2.2            py39h51133e4_0
[conda] numpy                     1.21.2           py39h20f2e39_0
[conda] numpy-base                1.21.2           py39h79a1101_0
[conda] pytorch                   1.11.0              py3.9_cpu_0    pytorch
[conda] pytorch-mutex             1.0                         cpu    pytorch
[conda] torchaudio                0.11.0                 py39_cpu    pytorch
[conda] torchvision               0.12.0                 py39_cpu    pytorch
Repository: pytorch
Issue: Floating point exception in slow_conv3d
Labels: module: convolution,triaged,module: edge cases

### 🐛 Describe the bug

Floating point exception in `slow_conv3d`.

### Example to reproduce

```python
import torch

tensor_0 = torch.full((0, 0, 9, 15, 0, 0, 0, 0, 0, 8,), 1, dtype=torch.float64, requires_grad=False)
tensor_1 = torch.full((0, 0, 9, 15, 0, 0, 0, 0, 0, 8, 0, 11, 10, 3, 0,), 0.5, dtype=torch.float64, requires_grad=False)
intarrayref_2 = [-8608480567731124087, -8608480567731124087, -8608480567731124087]
tensor_3 = torch.full((), 1, dtype=torch.int64, requires_grad=False)
intarrayref_4 = [-8608480567731124087, -8608480567731124087, -8608480567731124087]
intarrayref_5 = [-8608480567731124087, -8608480567731124087, -8608480567731124087]
torch._C._nn.slow_conv3d(tensor_0, tensor_1, intarrayref_2, tensor_3, intarrayref_4, intarrayref_5)
```

### Result
```floating point exception```

### Expected behavior
Graceful termination or a RuntimeError to be thrown.

### Note
This bug was discovered using IvySyn, a fuzz testing tool which is currently being developed at Secure Systems Labs at Brown University.

### Versions

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.18.4
Libc version: glibc-2.31

Python version: 3.9.7 (default, Sep 16 2021, 13:09:58)  [GCC 7.5.0] (64-bit runtime)
Python platform: Linux-5.10.0-11-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.0
[pip3] torchaudio==0.11.0
[pip3] torchvision==0.12.0
[conda] blas                      1.0                         mkl
[conda] cpuonly                   2.0                           0    pytorch
[conda] ffmpeg                    4.3                  hf484d3e_0    pytorch
[conda] mkl                       2021.4.0           h06a4308_640
[conda] mkl-service               2.4.0            py39h7f8727e_0
[conda] mkl_fft                   1.3.1            py39hd3c417c_0
[conda] mkl_random                1.2.2            py39h51133e4_0
[conda] numpy                     1.21.2           py39h20f2e39_0
[conda] numpy-base                1.21.2           py39h79a1101_0
[conda] pytorch                   1.11.0              py3.9_cpu_0    pytorch
[conda] pytorch-mutex             1.0                         cpu    pytorch
[conda] torchaudio                0.11.0                 py39_cpu    pytorch
[conda] torchvision               0.12.0                 py39_cpu    pytorch
Repository: pytorch
Issue: Heap corruption in slow_conv_transpose3d
Labels: module: convolution,triaged,module: edge cases

### 🐛 Describe the bug

Heap corruption in `slow_conv_transpose3d`.

### Example to reproduce

```python
import torch

tensor_0 = torch.empty((3, 3, 3, 3, 3,), dtype=torch.float32)
tensor_1 = torch.empty((3, 3, 3, 3, 3,), dtype=torch.float32)
intarrayref_2 = [2, 2, 2]
tensor_3 = torch.full((3,), 0.5, dtype=torch.float64, requires_grad=False)
intarrayref_4 = [1, 1, 1]
intarrayref_5 = [1, 1, 1]
intarrayref_6 = [-1250999896764, -1250999896764, -1250999896764]
intarrayref_7 = [1250999896764, 1250999896764, 1250999896764]
torch._C._nn.slow_conv_transpose3d(tensor_0, tensor_1, intarrayref_2, tensor_3, intarrayref_4, intarrayref_5, intarrayref_6, intarrayref_7)
```

### Result
```malloc_consolidate(): invalid chunk size```

### Expected behavior
Graceful termination or a RuntimeError to be thrown.

### Note
This bug was discovered using IvySyn, a fuzz testing tool which is currently being developed at Secure Systems Labs at Brown University.

### Versions

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.18.4
Libc version: glibc-2.31

Python version: 3.9.7 (default, Sep 16 2021, 13:09:58)  [GCC 7.5.0] (64-bit runtime)
Python platform: Linux-5.10.0-11-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.0
[pip3] torchaudio==0.11.0
[pip3] torchvision==0.12.0
[conda] blas                      1.0                         mkl
[conda] cpuonly                   2.0                           0    pytorch
[conda] ffmpeg                    4.3                  hf484d3e_0    pytorch
[conda] mkl                       2021.4.0           h06a4308_640
[conda] mkl-service               2.4.0            py39h7f8727e_0
[conda] mkl_fft                   1.3.1            py39hd3c417c_0
[conda] mkl_random                1.2.2            py39h51133e4_0
[conda] numpy                     1.21.2           py39h20f2e39_0
[conda] numpy-base                1.21.2           py39h79a1101_0
[conda] pytorch                   1.11.0              py3.9_cpu_0    pytorch
[conda] pytorch-mutex             1.0                         cpu    pytorch
[conda] torchaudio                0.11.0                 py39_cpu    pytorch
[conda] torchvision               0.12.0                 py39_cpu    pytorch
Repository: material-ui
Issue: Add a Dialog created without Modal
Labels: new feature,component: dialog

### Duplicates

- [X] I have searched the existing issues

### Latest version

- [X] I have tested the latest version

### Summary 💡

Dialogs are both modal and non-modal, as noted in [mdn web docs](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/dialog_role) and [w3c aria](https://w3c.github.io/aria/#dialog).

I am currently building some tool windows and toolboxes that would be great as floating, draggable dialogs that allow interaction on the page below as well as in the dialog. However, the current Dialog is build on top of Modal, and that creates issues with accessibility for accessing controls on the page and in the dialog.

Can we add a property to Dialog (and possibly Drawer) for isModal={false}?

### Examples 🌈

A decent example is [Photopea](https://www.photopea.com/). When you select Layer -> Layer Style -> Blending Options and you get a floating, draggable dialog with options inside the dialog, but also can still select other things at the same time.

### Motivation 🔦

Really, the summary expresses it best. Dialogs can be modal or non-modal. Why is Material UI limited to only modal Dialogs? And why create more accessibility issues by limiting to modals? While there are ways to turn off aspects of the Modal component, it has several bugs that still create accessibility issues that have not yet been fixed.
Repository: godot
Issue: Mouse cursor image flickering when using two viewports layered
Labels: bug,platform:windows,topic:porting,topic:input,topic:gui

### Godot version

3.4.3.rc1.mono.official

### System information

Windows 11, GLES3

### Issue description

In my current game project I need two layered viewports on top of each other. One is for the actual ingame world and the other one for UI and stuff.

I want to let the cursor fall back to e.g. a crosshair and only show a normal mouse cursor when hovering Control elements. This basically works fine so far but there is one bug happening: **When hovering the parts where no Control node is on the UI viewport, the cursor somehow flickers between crosshair and normal cursor.** (Check the video for the reproduction project at the bottom) Seems like the normal cursor is set but then the crosshair takes over within milliseconds.
This is also only happening when the cursor is being actively moved.

This bug is confirmed on two other devices (Windows 10 and 11 with different GPUs).

### Steps to reproduce

Here you can see the node tree:
![image](https://user-images.githubusercontent.com/7323098/169419543-d2073a48-3a0b-49c1-a3f8-e6e3d7146b5f.png)

* Both ViewportContainers are in strech mode
* ViewportContainer1 and 2 is set to "Mouse -> Ignore"
* Root node is set to "Mouse -> Stop, Cross"
* The ColorRect is set to "Mouse -> Stop, Arrow"
* The Viewport nodes have no meaningful adjustments


### Minimal reproduction project

For reproduction purposes I have created a minimal setup close to my game setup.
[FlickerTest.zip](https://github.com/godotengine/godot/files/8734703/FlickerTest.zip)

Here you also can see a recording of the problem:
[Link to video](https://user-images.githubusercontent.com/7323098/169420208-61a05bad-2b3f-4274-b36c-49f59ceee51c.mp4)
Repository: godot
Issue: Fake bold (embolden) doesn't render glyph intersections correctly when MSDF is enabled on the default project font
Labels: bug,topic:rendering,confirmed,topic:gui

### Godot version

4.0.alpha8

### System information

Fedora 36, GeForce GTX 1080 (NVIDIA 510.68.02)

### Issue description

Fake bold (embolden) doesn't render glyph intersections correctly when MSDF is enabled on the default project font.

Due to how msdfgen works, this may not be fixable. We could figure out a workaround instead (such as disabling fake bold when the default project font has MSDF enabled).

Fake italic works well, so it can be left enabled.

*Left: Fake bold/italic*
*Right: Real bold/italic*

![2022-05-20_01 43 38](https://user-images.githubusercontent.com/180032/169421648-8e473868-f746-4149-9a20-f1fcfa46e3d4.png)

### Steps to reproduce

- Add a RichTextLabel node with some text. Enable **BBcode** in the RichTextLabel inspector, then write some text within `[b]` and `[i]` tags.
- Enable **GUI > Theme > Default Font Multichannel Signed Distance Field** in the Project Settings.

### Minimal reproduction project

https://0x0.st/oaBa.zip <sub>(link expires in April 2023)</sub>

*Keywords for easier searching: faux*
Repository: go
Issue: cmd/go: Misleading err msg if vendors/modules.txt doesn't exist
Labels: NeedsInvestigation,GoCommand

### What version of Go are you using (`go version`)?

The bug was originally discovered with using Go `1.17.5` while we were trying to setup a [CI](https://github.com/redhat-appstudio/managed-gitops/pull/126) for our Go project.

It is also reproducible with the latest release and build, such as:

<pre>
go version devel go1.19-8542bd8938 Thu May 19 19:32:35 2022 +0000 darwin/amd64
</pre>

### What did you do?

1. Go to any of your Go projects: `cd $GOPATH/src/github.com/foo/bar`
2. Make sure you have modules enabled: `export GO111MODULE=on`
3. Make sure you have vendor flag enabled: `export GOFLAGS="-mod=vendor"`
4. Make sure there is no `vendor` directory there: `rm -rf vendor` or if you have rename it `mv vendor backup_vendor`.
5. Run `go fmt ./...`

### What did you expect to see?

I would expect to get an error:

```bash
go: open $GOPATH/src/github.com/foo/bar/vendor/modules.txt: no such file or directory
```

### What did you see instead?


```
github.com/emicklei/go-restful/v3@v3.7.1: is explicitly required in go.mod, but not marked as explicit in vendor/modules.txt
... 
...
...
(skip the rest of them for brevity)
...
	To ignore the vendor directory, use -mod=readonly or -mod=mod.
	To sync the vendor directory, run:
		go mod vendor
```

It complains about my modules (actually, for every single one of them) that are not in-sync with my vendors, but this comparison never happens in the first place since there's no `vendor/modules.txt` to compare with.
Repository: frp
Issue: [Feature Request] Hot reloading TLS certificates in FRPS 
Labels: proposal

### Describe the feature request

Currently in FRPS TLS certificates are only loaded during the initialisation of the server, so if the signed certificate expires or are replaced FRPS needs to be restarted which will break any client connections.

Looking  at how other programs handle this there seems to be two main approaches.

1. Catch any SIGHUP signals sent to the FRPS process and reload the certificate
2. Watch the files and reload the files when they changed

The former seemed simpler to implement so I have a working version at: [splinter98/frp](https://github.com/splinter98/frp/tree/ssh-renewal) on the ssh-renewal branch.

### Describe alternatives you've considered

I've also considered looking implementing the file monitoring approach but this would introduce another 3rd party library dependency.

### Affected area

- [ ] Docs
- [ ] Installation
- [ ] Performance and Scalability
- [X] Security
- [X] User Experience
- [ ] Test and Release
- [ ] Developer Infrastructure
- [ ] Client Plugin
- [X] Server Plugin
- [ ] Extensions
- [ ] Others
Repository: flutter
Issue: remove non-free dependency com.google.android.play.core.splitcompat.SplitCompatApplication
Labels: platform-android,engine,c: proposal,a: build,P3,team-android,triaged-android

## Use case

The implementation of `com.google.android.play.core.splitcompat.SplitCompatApplication` in https://github.com/flutter/engine/blob/main/shell/platform/android/io/flutter/embedding/android/FlutterPlayStoreSplitApplication.java and https://github.com/flutter/engine/blob/main/shell/platform/android/io/flutter/app/FlutterPlayStoreSplitApplication.java should be made optional and not included by default in the android builds.

Those implementations should be optionally imported into built APKs / appbundles in order to shrink the built applications size. Moreover, making those implementations would result in apps with entirely open source dependencies; which might be important for high-security certifications.

## Proposal

The stated implementations should only be included in the built applications in case deferred libraries are used. Otherwise, they should be left out in order to produce smaller builds.
Repository: tensorflow
Issue: Memory Leak with Tensorflow Experimental Save
Labels: stat:awaiting tensorflower,comp:data,type:performance,TF 2.8

<details><summary>Click to expand!</summary> 
 
 ### Issue Type

Performance

### Source

source

### Tensorflow Version

2.8

### Custom Code

Yes

### OS Platform and Distribution

_No response_

### Mobile device

_No response_

### Python version

3.9

### Bazel version

_No response_

### GCC/Compiler version

_No response_

### CUDA/cuDNN version

_No response_

### GPU model and memory

_No response_

### Current Behaviour?

```shell
I have a loop where I am creating tensorflow datasets and then saving to directories for later use using tf.data.experimental.save.

I found that as the loop progresses, the memory being used greatly increases, until the process eventually crashes.

In this first example below, I do not save the file, and the memory stays at the same level throughout. However, if I save each dataset, the memory used increases each time.

Adding tf.keras.backend.clear_session() after each save appears to slow down the memory growth but doesn't fully stop it.

Thank you in advance for any help.
```


### Standalone code to reproduce the issue

```shell
import tensorflow as tf
import numpy as np
from humanize import naturalsize
import psutil

# First example, no memory increase
for i in range(10000):
    if i in range(1, 10001, 100):
        print(naturalsize(psutil.Process().memory_info().rss))
    data = tf.data.Dataset.from_tensors(np.array([0, 1, 2]))

# Second example, memory increase
for i in range(10000):
    if not i % 100:
        print(naturalsize(psutil.Process().memory_info().rss))
    data = tf.data.Dataset.from_tensors(np.array([0, 1, 2]))
    tf.data.experimental.save(data, path='~/Desktop/1')
# Grows by about 5 MB each 100 runs.
```


### Relevant log output

_No response_</details>