sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: pytorch
Issue: JIT fails to trace binary cross entropy with a strange error msg
Labels: oncall: jit

### 🐛 Describe the bug

JIT fails to trace binary cross entropy with a strange error msg

```py
import torch

def fn(input, target):
    weight = torch.tensor(64.0)
    reduction = "mean"
    return torch.nn.functional.binary_cross_entropy(input, target, weight=weight, reduction=reduction)

input = torch.tensor([0.1, 0.1, 0.1], dtype=torch.float32)
target = torch.tensor([0.15, 0.15, 0.15], dtype=torch.float32)

inputs = (input, target)

print(fn(*inputs))

new_fn = torch.jit.trace(fn, inputs)
print(new_fn(*inputs))
```

```
tensor(27.8364)

RuntimeError: expected int at position 0, but got: Tensor
```

I think the input here is valid and JIT should succeed to trace it

### Versions

```
PyTorch version: 1.13.0.dev20221001
Is debug build: False
CUDA used to build PyTorch: 11.7
ROCM used to build PyTorch: N/A

OS: Ubuntu 22.04.1 LTS (x86_64)
GCC version: (Ubuntu 11.2.0-19ubuntu1) 11.2.0
Clang version: Could not collect
CMake version: Could not collect
Libc version: glibc-2.35

Python version: 3.9.13 (main, Aug 25 2022, 23:26:10)  [GCC 11.2.0] (64-bit runtime)
Python platform: Linux-5.19.5-051905-generic-x86_64-with-glibc2.35
Is CUDA available: True
CUDA runtime version: 11.7.99
GPU models and configuration: GPU 0: NVIDIA GeForce RTX 3060
Nvidia driver version: 515.65.01
cuDNN version: Could not collect
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

Versions of relevant libraries:
[pip3] numpy==1.23.3
[pip3] torch==1.13.0.dev20221001
[pip3] torchaudio==0.13.0.dev20221001
[pip3] torchvision==0.14.0.dev20221001
[conda] blas                      1.0                         mkl  
[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.23.3                   pypi_0    pypi
[conda] numpy-base                1.23.1           py39ha15fc14_0  
[conda] pytorch                   1.13.0.dev20221001 py3.9_cuda11.7_cudnn8.5.0_0    pytorch-nightly
[conda] pytorch-cuda              11.7                 h67b0de4_0    pytorch-nightly
[conda] pytorch-mutex             1.0                        cuda    pytorch-nightly
[conda] torch                     1.13.0.dev20220923+cu116          pypi_0    pypi
[conda] torchaudio                0.13.0.dev20220923+cu116          pypi_0    pypi
[conda] torchvision               0.14.0.dev20220923+cu116          pypi_0    pypi
```
Repository: pytorch
Issue: TransformerEncoder src_key_padding_mask does not work in eval()
Labels: high priority,module: nn,triaged

### 🐛 Describe the bug

Described here: https://discuss.pytorch.org/t/model-eval-predicts-all-the-same-or-nearly-same-outputs/155025/12

Starting with version 1.12, TransformerEncoder uses two different code paths, which perform differently between training and evaluation mode. In training, the `why_not_sparsity_fast_path` will be set, and the sparsity fast path will not be used. During eval(), if using a `src_key_padding_mask`, output will be modified:

https://github.com/pytorch/pytorch/blob/b04b2fa9aa52cacbdc9aaaf477d55b0af845ce81/torch/nn/modules/transformer.py#L271
```
            if (not why_not_sparsity_fast_path) and (src_key_padding_mask is not None):
                convert_to_nested = True
                output = torch._nested_tensor_from_mask(output, src_key_padding_mask.logical_not(), mask_check=False)
                src_key_padding_mask_for_layers = None
```

The output is usually some constant value. It seems like their might be some misalignment with the expected `src_key_padding_mask` and the `logical_not()` operation. Perhaps the mask inversion should not be performed.

### Versions

Python version: 3.8.13 (default, Mar 28 2022, 06:59:08) [MSC v.1916 64 bit (AMD64)] (64-bit runtime)
Python platform: Windows-10-10.0.22621-SP0
Is CUDA available: True
CUDA runtime version: 11.6.124
GPU models and configuration: GPU 0: NVIDIA GeForce RTX 3090
Nvidia driver version: 516.94
cuDNN version: Could not collect
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

Versions of relevant libraries:
[pip3] efficientnet-pytorch==0.7.1
[pip3] mypy-extensions==0.4.3
[pip3] numpy==1.23.3
[pip3] segmentation-models-pytorch==0.3.0
[pip3] torch==1.12.1+cu116
[pip3] torchaudio==0.12.1+cu116
[pip3] torchmetrics==0.9.3
[pip3] torchvision==0.13.1+cu116
[conda] efficientnet-pytorch      0.7.1                    pypi_0    pypi
[conda] numpy                     1.23.3                   pypi_0    pypi
[conda] segmentation-models-pytorch 0.3.0                    pypi_0    pypi
[conda] torch                     1.12.1+cu116             pypi_0    pypi
[conda] torchaudio                0.12.1+cu116             pypi_0    pypi
[conda] torchmetrics              0.9.3                    pypi_0    pypi
[conda] torchvision               0.13.1+cu116             pypi_0    pypi

cc @ezyang @gchanan @zou3519 @kadeng @msaroufim @albanD @mruberry @jbschlosser @walterddr @mikaylagawarecki @bhosmer @cpuhrsch @erichan1 @drisspg
Repository: pytorch
Issue: torch.jit.trace throwing Invalid name for qualified name eror 
Labels: oncall: jit

### 🐛 Describe the bug

While running `torch.jit.trace`, the function throws an error and explicitly asks to open a bug. Based on the name in the last line of the trace, it looks like something is wrong with the format, but I am not sure if this is a bug, as stated in the error message, or I can tweak something to change the name. 

Code: 
```
module = torch.jit.trace(model, test_input)
```

Trace 
```
  File "model_generator.py", line 89, in pytorch_to_fp32onnx
    module = torch.jit.trace(model, test_input)
  File "/home/hcsuser/envs/latest/lib/python3.7/site-packages/torch/jit/_trace.py", line 750, in trace
    _module_class,
  File "/home/hcsuser/envs/latest/lib/python3.7/site-packages/torch/jit/_trace.py", line 942, in trace_module
    module = make_module(mod, _module_class, _compilation_unit)
  File "/home/hcsuser/envs/latest/lib/python3.7/site-packages/torch/jit/_trace.py", line 568, in make_module
    return _module_class(mod, _compilation_unit=_compilation_unit)
  File "/home/hcsuser/envs/latest/lib/python3.7/site-packages/torch/jit/_trace.py", line 1072, in __init__
    tmp_module, lambda module: (), share_types=False, is_tracing=True
  File "/home/hcsuser/envs/latest/lib/python3.7/site-packages/torch/jit/_recursive.py", line 451, in create_script_module
    concrete_type = get_module_concrete_type(nn_module, share_types)
  File "/home/hcsuser/envs/latest/lib/python3.7/site-packages/torch/jit/_recursive.py", line 408, in get_module_concrete_type
    concrete_type = concrete_type_builder.build()
RuntimeError: atom.size() > 0INTERNAL ASSERT FAILED at "../aten/src/ATen/core/qualified_name.h":25, please report a bug to PyTorch. Invalid name for qualified name: '__torch__..model_wrapper.TigerViT'
```


### Versions

PyTorch version: 1.11.0+cu102
Is debug build: False
CUDA used to build PyTorch: 10.2
ROCM used to build PyTorch: N/A

OS: Ubuntu 18.04.6 LTS (x86_64)
GCC version: (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0
Clang version: Could not collect
CMake version: version 3.10.2
Libc version: glibc-2.26

Python version: 3.7.5 (default, Dec  9 2021, 17:04:37)  [GCC 8.4.0] (64-bit runtime)
Python platform: Linux-5.4.0-1083-azure-x86_64-with-Ubuntu-18.04-bionic
Is CUDA available: True
CUDA runtime version: 9.1.85
GPU models and configuration: Could not collect
Nvidia driver version: Could not collect
cuDNN version: Probably one of the following:
/usr/lib/x86_64-linux-gnu/libcudnn.so.8.4.1
/usr/lib/x86_64-linux-gnu/libcudnn_adv_infer.so.8.4.1
/usr/lib/x86_64-linux-gnu/libcudnn_adv_train.so.8.4.1
/usr/lib/x86_64-linux-gnu/libcudnn_cnn_infer.so.8.4.1
/usr/lib/x86_64-linux-gnu/libcudnn_cnn_train.so.8.4.1
/usr/lib/x86_64-linux-gnu/libcudnn_ops_infer.so.8.4.1
/usr/lib/x86_64-linux-gnu/libcudnn_ops_train.so.8.4.1
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

Versions of relevant libraries:
[pip3] numpy==1.21.6
[pip3] torch==1.11.0
[pip3] torchvision==0.13.1
[conda] Could not collect
Repository: godot
Issue: Window Dialog is continuously generating new object ids for the close button
Labels: topic:core,documentation

### Godot version

3.5.1

### System information

Linux Mint 21 Cinnamon

### Issue description

_Note: I think this is a bug, but I'm not familiar with the inner workings of window rendering, so maybe this is intentional?_

The object id of a WindowDialog's close button is constantly incrementing during runtime. You can either observe this in the Remote view while the project is running or by adding a script to a WindowDialog node with the following contents:

```
extends WindowDialog

func _process(delta):
	print(get_child(0).texture_normal.image)
``` 

https://user-images.githubusercontent.com/35151158/193619934-8dfa0e17-acf8-48ff-bc47-fa6d8a419edf.mp4

### Steps to reproduce

1. Create a new WindowDialog scene and save it
2. Start the scene and switch to the Remote view
3. Expand the WindowDialog node and select the Button child node
4. Open the Button's Texture Normal object
5. Observe that the image object's id is constantly incrementing

### Minimal reproduction project

[window_dialog_bug.zip](https://github.com/godotengine/godot/files/9699057/window_dialog_bug.zip)
Repository: deno
Issue: ffmpeg import via npm: specifiers fails with 'Invalid URL'
Labels: bug,needs investigation,node compat

simple repro script:
`deno run --unstable --allow-read mod.ts`
```ts
import ffmpegCore from 'npm:@ffmpeg/core'
import { createFFmpeg, fetchFile } from 'npm:@ffmpeg/ffmpeg'

const ffmpeg = createFFmpeg({ log: true })
await ffmpeg.load();
```


```
[info] use ffmpeg.wasm v0.11.5
[info] load ffmpeg-core
[info] loading ffmpeg-core
✅ Granted read access to <main_module>.
[fferr] TypeError: Invalid URL
error: Uncaught RuntimeError: abort(TypeError: Invalid URL). Build with -s ASSERTIONS=1 for more info.
    at process.u (file:///Users/andrew.kaiser/Library/Caches/deno/npm/registry.npmjs.org/@ffmpeg/core/0.11.0/dist/ffmpeg-core.js:25:109)
    at process.emit (https://deno.land/std@0.158.0/node/_events.mjs:379:28)
    at process.emit (https://deno.land/std@0.158.0/node/process.ts:435:20)
    at https://deno.land/std@0.158.0/node/process.ts:301:15
    at innerInvokeEventListeners (deno:ext/web/02_event.js:755:9)
    at invokeEventListeners (deno:ext/web/02_event.js:795:7)
    at dispatch (deno:ext/web/02_event.js:664:11)
    at dispatchEvent (deno:ext/web/02_event.js:1043:14)
    at promiseRejectMacrotaskCallback (deno:runtime/js/99_main.js:633:18)
```

`deno --version` output:
```
deno 1.26.0 (release, aarch64-apple-darwin)
v8 10.7.193.3
typescript 4.8.3
```

(tangentially related, we have been working through some of the runtime issues with ffmpeg-wasm running in deno here https://github.com/ffmpegwasm/ffmpeg.wasm/issues/110)
Repository: pytorch
Issue: [TorchDispatch] Scalar Only Inputs Gets Matched To Tensor Schema
Labels: triaged,module: __torch_dispatch__

### 🐛 Describe the bug

When you call `torch.div` with scalar-only inputs, the schema that gets matched to is `aten::div.Tensor(Tensor self, Tensor other) -> Tensor`.  

```
import torch
from torch.utils._python_dispatch import TorchDispatchMode

class DebugMode(TorchDispatchMode):
    def __torch_dispatch__(self, func, types, args=(), kwargs=None):
        print(func, args, kwargs)
        return func(*args, **kwargs)

with DebugMode():
    print(torch.div(240, 8))
```
> aten.div.Tensor (240, 8) {}
tensor(30.)

I would expect the scalar inputs to get promoted to Tensors (lift_fresh) before the `aten.div` is invoked, or for a scalar schema to get matched to (probably the former). 

Also, I couldn't find the tests for scalar only inputs to Binary torch functions. 

Related: https://github.com/pytorch/torchdynamo/issues/1445

### Versions

master

cc @Chillee @ezyang @zou3519 @albanD @samdow
Repository: vscode
Issue: Define and apply guidance for icon toggle states
Labels: ux,polish

Refs https://github.com/microsoft/vscode/issues/162441

In some situations where a state is toggled (locking, pinning, hiding), we use a different approach for which icon is exposed. Sometimes we show the current state (e.g. locked) and sometimes we show the target state (currently unlocked, but the locked icon is displayed). 

Ideally we can have reusable guidance to apply elsewhere.
Repository: vscode
Issue: Settings UI shows no warning (and possibly an incorrect value) when an invalid enum is in settings.json
Labels: bug,settings-editor,confirmed

<!-- ⚠️⚠️ Do Not Delete This! bug_report_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- 🕮 Read our guide about submitting issues: https://github.com/microsoft/vscode/wiki/Submitting-Bugs-and-Suggestions -->
<!-- 🔎 Search existing issues to avoid creating duplicates. -->
<!-- 🧪 Test using the latest Insiders build to see if your issue has already been fixed: https://code.visualstudio.com/insiders/ -->
<!-- 💡 Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. -->
<!-- 🔧 Launch with `code --disable-extensions` to check. -->
Does this issue occur when all extensions are disabled?: Yes

<!-- 🪓 If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. -->
<!-- 📣 Issues caused by an extension need to be reported directly to the extension publisher. The 'Help > Report Issue' dialog can assist with this. -->
- VS Code Version:Version: 1.72.0-insider (user setup)
Commit: 9fb452c4852ef098206ec67a2b236ad5fd0ba828
Date: 2022-10-03T07:34:58.711Z
Electron: 19.0.17
Chromium: 102.0.5005.167
Node.js: 16.14.2
V8: 10.2.154.15-electron.0
OS: Windows_NT x64 10.0.22621
Sandboxed: Yes

Steps to Reproduce:

1. Install the C/C++ extension version 1.13.1 (pre-release).
2. Add the invalid/deprecated setting "C_Cpp.enhancedColorization": "Disabled" to settings.json (the enum was renamed "disabled".
3. View the settings UI.
NOTE: The bug is probably reproduceable with some other setting enum, but I haven't tried.

Bug: No warning appears in the settings UI, and it shows the misleading/unused default value of "enabled" -- our extension still handles the "Disabled" value for backwards compatibility, so the UI settings misleading shows the wrong value. This can confuse users into believing the setting is actually enabled and there's a bug causing it to not work, when in fact if they opened the settings.json they would see the json warnings in that file showing that the setting is invalid.

The issue on the C/C++ extension is at https://github.com/microsoft/vscode-cpptools/issues/9938.
Repository: pytorch
Issue: Debuggability++: Share instructions for building exotic CI configurations
Labels: module: ci,triaged

### 🚀 The feature, motivation and pitch

We know how to build PyTorch on various exotic CI configurations (@ezyang has them [documented internally](https://fb.workplace.com/groups/1274980366011614/posts/2317382101771430/?comment_id=2317519805090993)).

It would be great to make these more visible to people. In particular, if an exotic CI job fails, it would be good to link to instructions for how to build in that configuration directly. This could be done in HUD, or directly in the logfiles (although logfiles are at risk of not being seen by users.) Is anyone in Dev Infra interested in helping make this happen? I think it would be a great benefit for anyone working inside core PyTorch.

Practically, this would be two stages:
1. **Make the info available** externally. Perhaps copy/paste it to CONTRIBUTING.md or the wiki
2. **Surface the info** by sharing it in HUD under failing workflows 

### Why do this?
This is a usability improvement that will help people debug their failing builds, making them less likely to decide to `merge -f` a broken change

cc @seemethere @malfet @pytorch/pytorch-dev-infra
Repository: vscode
Issue: Command Center visibility should be toggled as one unit
Labels: under-discussion,command-center

Maybe a known bug, but I think it's strange to have the ability to hide specific parts of the command center UI:

<img width="711" alt="CleanShot 2022-10-03 at 10 35 40@2x" src="https://user-images.githubusercontent.com/25163139/193642330-a7798055-4606-408f-b1ea-e2484afbda30.png">
Repository: terminal
Issue: New instance behavior doesn't work as expected with multiple monitors
Labels: Issue-Feature,Product-Terminal,Area-Windowing

### Windows Terminal version

1.15.2713.0

### Windows build number

10.0.22621.0

### Other Software

_No response_

### Steps to reproduce

* You need at least 2 monitors connected.
* Set "New instance behavior" to "Attach to most recently used window on this desktop".
* Open Terminal window and move it to other monitor.
* Open another Terminal

### Expected Behavior

Since first Terminal window is on different monitor, the second one should open new window.

### Actual Behavior

Second terminal is opened as a tab in the window moved to second monitor.
Repository: storybook
Issue: Error: EBUSY: resource busy or locked when running storybook
Labels: bug,windows

**Describe the bug**
A clear and concise description of what the bug is.

**To Reproduce**
With Node v 16.13 and NPM 8.15 installed
Create-react-app
cd into directory
npx storybook init
Once completed, npm run storybook

**System**
 npmPackages:
    @storybook/addon-actions: ^6.5.12 => 6.5.12
    @storybook/addon-essentials: ^6.5.12 => 6.5.12
    @storybook/addon-interactions: ^6.5.12 => 6.5.12
    @storybook/addon-links: ^6.5.12 => 6.5.12
    @storybook/builder-webpack5: ^6.5.12 => 6.5.12
    @storybook/manager-webpack5: ^6.5.12 => 6.5.12
    @storybook/node-logger: ^6.5.12 => 6.5.12
    @storybook/preset-create-react-app: ^4.1.2 => 4.1.2
    @storybook/react: ^6.5.12 => 6.5.12
    @storybook/testing-library: ^0.0.13 => 0.0.13
**Additional context**
The results are:

10% building 0/1 entries 0/0 dependencies 0/0 modulesnode:internal/process/promises:279
            triggerUncaughtException(err, true /* fromPromise */);
            ^

[Error: EBUSY: resource busy or locked, open 'C:\Users\MyUsername\Documents\NCS\ncs\node_modules.cache\storybook\dev-server\325c8f456729b912b0d2134054eb7448-41ac79ddc5290d504ad69ef1fe8200a7'] {
  errno: -4082,
  code: 'EBUSY',
  syscall: 'open',
  path: 'C:\Users\MyUsername\Documents\NCS\ncs\node_modules\.cache\storybook\dev-server\325c8f456729b912b0d2134054eb7448-41ac79ddc5290d504ad69ef1fe8200a7'
}
Repository: godot
Issue: GLES2 handles transparency wrong
Labels: bug,topic:rendering,needs testing,topic:3d

### Godot version

3.5-stable

### System information

Ubuntu 22.04

### Issue description

I am rendering [a 3D model](https://sketchfab.com/3d-models/character-teen-red-2k-f0fbad361e5843ddbcb07cd65679ec60) of a character on a viewport texture. Parts of the textures (eg. around the hair) are transparent. When using GLES3, it looks fine, but when I change to GLES2, some unwanted parts of the model are shown as transparent. It seems as if there are multiple layers of the model where some of them are transparent and some of them aren't, then they are marked as transparent in total.

GLES3:
![GLES3](https://i.ibb.co/4p8pySm/gles3-transparent.png)

GLES2:
![GLES2](https://i.ibb.co/4PWQsbK/gles2-transparent.png)

The problem disappears when I turn the transparency of the material off, in GLES2:

![GLES2, nontrasparent](https://i.ibb.co/4tF0Td1/gles2-nontransparent.png).

Maybe related issue: #43559.

### Steps to reproduce

Render the model from the link on a viewport texture in GLES2 vs GLES3. I will be able to look deeper and create a minimal project if what I wrote above doesn't ring any bells.

### Minimal reproduction project

_No response_
Repository: kubernetes
Issue: apiserver: command exec in pod randomly drops stdin
Labels: kind/bug,sig/api-machinery,sig/testing,triage/accepted

### What happened?

I was using https://github.com/kubernetes/kubernetes/blob/725993afce11082b973901d2e92553640771d55d/test/e2e/framework/exec_util.go#L49-L84 (similar to `kubectl exec -i`) with `dd` as command and some data as stdin to create a file inside a container. This worked fine most of the time during local development. When used inside a Prow job, I ran into test flakes that could be traced down to `dd` returning after writing zero bytes although stdin was non-empty. No error was returned.

### What did you expect to happen?

The data should be transferred reliably.

### How can we reproduce it (as minimally and precisely as possible)?

Sorry, no test for this right now.

### Anything else we need to know?

_No response_

### Kubernetes version

462f41212a4e5ded8974784038f681a08dded1be (roughly current master)


### Cloud provider

<details>
kind
</details>


### OS version

_No response_

### Install tools

kind

### Container runtime (CRI) and version (if applicable)

containerd (from master)

### Related plugins (CNI, CSI, ...) and versions (if applicable)

_No response_
Repository: stable-diffusion-webui
Issue: Move the Re-use seed next to the pictures themselves
Labels: enhancement

**Is your feature request related to a problem? Please describe.**
Not so much of a problem, more like an inconvenience, every time I want to re use a seed I click a picture, scroll down to the ♻ button, and scroll back up to the generate button, seems like a UX oversight

**Describe the solution you'd like**
Moving the reuse button next to the image, or for instance as a little overlay on top or even just next to "save" or any other button of that line would make more sense In my opinion
Repository: godot
Issue: CharString variable declaration in GDNative code causes crash when that method is called from GDScript
Labels: bug,topic:gdextension,crash

### Godot version

3.5.1.stable

### System information

WIndows 10

### Issue description

When a CharString variable is declared in a C++ method called by GDScript, Godot will crash shortly after, possibly during, the return from the called C++ method.

I think this was crashing under linux as well, but most of my testing and debugging of this crash was performed under windoze.

I ran into the problem on another project where I was initially using a CharString to convert a Godot::String to a C/C++ string before I found String::alloc_c_string().  However, I left the CharString declaration in that code and was getting random crashes on the first call, unless I had a print() statement immediately before it in the calling GDScript code.  Once I removed the declaration of the unused CharString variable, the crashes stopped.

To verify that removing the CharString variable declaration was really a fix, I added one to the GDNative C++ Example code.  That code now crashes as well.

### Steps to reproduce

Start with the GDExample class in the [GDNative C++ Example](https://docs.godotengine.org/en/3.5/tutorials/scripting/gdnative/gdnative_cpp_example.html) tutorial.  Declare a CharString variable in the _process() method:

```c++
void GDExample::_process(float delta) {
  CharString cs;                          // <------- Added this line
  time_passed += speed * delta;

  Vector2 new_position = Vector2(
				 (real_t) (amplitude + (amplitude * sin(time_passed * 2.0))),
				 (real_t) (amplitude + (amplitude * cos(time_passed * 1.5)))
				 );

  set_position(new_position);
}
```

Build the code.

Run the main.tscn scene.

It should crash.

### Minimal reproduction project

[GDNative C++ Example](https://github.com/BastiaanOlij/gdnative_cpp_example)