sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: pytorch
Issue: Observing CUDA OOM errors in more recent versions of PyTorch nightly (post-`2.6.0.dev20241126`)
Labels: module: cuda,module: ci,triaged

### 🐛 Describe the bug

We've been running into issues with CUDA CI on FBGEMM in OSS:

```
E   torch.OutOfMemoryError: CUDA out of memory. Tried to allocate 14.00 MiB. GPU 0 has a total capacity of 21.98 GiB of which 2.44 MiB is free. Including non-PyTorch memory, this process has 21.96 GiB memory in use. Of the allocated memory 21.67 GiB is allocated by PyTorch, and 9.24 MiB is reserved by PyTorch but unallocated. If reserved but unallocated memory is large try setting PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True to avoid fragmentation.  See documentation for Memory Management  (https://pytorch.org/docs/stable/notes/cuda.html#environment-variables)
```
(https://github.com/pytorch/FBGEMM/actions/runs/12119841693/job/33788952412)

This started happening last week, and at first I thought it was due to a bad commit that landed in FBGEMM OSS.  The last commit that passed the test was https://github.com/pytorch/FBGEMM/commit/6eb379a96d55a2373c0a3ad4d7b46567d3b307d6, but I found that the post-land CI passed while at the same time, the nightly builds that came afterwards failed with the error signature.

From what I can tell, `torch-2.6.0.dev20241126` appears to be the last good build for us.  Im currently testing this hypothesis out by rerunning the FBGEMM CUDA CI against `torch-2.6.0.dev20241126`, but Im wondering if there's issues with the instances as well, since we don't normally run into OOM errors.

cc @ptrblck @msaroufim @eqy @seemethere @malfet @pytorch/pytorch-dev-infra @huydhn 

### Versions

Not exactly sure, but appears to be post-`2.6.0.dev20241126`
Repository: storybook
Issue: [Bug] SB Channel events are not doing anything in portable stories
Labels: bug,sev:S3,portable stories

### [Storybook Channel](https://storybook.js.org/docs/addons/addons-api#usechannel)

Storybook relies a lot in the Storybook channel. It only works correctly in Storybook, as most of places where channel events are registered are part of Storybook manager UI. In portable stories, it's just mocked. This causes issues in case stories or decorators actually need to emit/listen to events. One very clear example is the `useArgs` hook from `@storybook/preview-api`, which relies on emitting events, and therefore it won't do anything in portable stories. It so happens that many people use that hook because they want the controls panel to update as they interact with their components.

💡 Solutions/Action items:

- Honestly not sure, we need to discuss/research
- (From Michael) Specifically for useArgs, we could listen to its event in the mocked channel in PS and throw an error mentioning it's not supported (great short term solution)
Repository: storybook
Issue: [Bug] Preview API hooks aren't behaving as expected in portable stories
Labels: bug,sev:S3,portable stories

Apart from `useArgs` not working due to Storybook channel limitations (#29773), other hooks from `@storybook/preview-api` also don't behave as expected, such as `useState` and `useEffect`.

💡 Solutions/Action items:

- Research on how feasible it is to implement support for this
- Document this limitation

---

Currently, portable stories are not compatible with Storybook hooks from `@storybook/preview-api`. This makes it hard for users who have stories like so to use the Storybook Test feature:

```tsx
import { useArgs } from '@storybook/preview-api'
export const Default = {
  args: {
    value: true,
  },
  render: function Render() {
    const [{ value }, updateArgs] = useArgs()
    const onValueChange = () => updateArgs({ value: !value })

    return <button onClick={onValueChange}>The value is {JSON.stringify(value)}</button>
  },
  play: async({ canvas }) => {
    const button = await canvas.findByText('The value is true')
    await expect(button).toBeInTheDocument()
    await userEvent.click(button)
    await expect(await canvas.findByText('The value is false')).toBeInTheDocument()
  }
}
```
Repository: storybook
Issue: [Bug] Vitest plugin does not detect custom vite config paths
Labels: bug,sev:S4,portable stories

Storybook, by default, loads a `vite.config` file in the project root. The same goes for Vitest. However, users can customize the vite config path like so:

```tsx
// .storybook/main.js
export default {
  core: {
    builder: {
      name: '@storybook/builder-vite',
      options: {
        viteConfigPath: '.storybook/vite.config.ts',
      },
    },
  },
};
```

Vitest **will not** know about this, unless users manually load such vite config file in their vitest config file like so:

```tsx
// vitest.config.ts
import { defineWorkspace } from 'vitest/config'

export default defineWorkspace([
	{ extends: '.storybook/vite.config.ts', plugins: [ storybookTest() ] ... }
])
```

Some people have a vite config file for their app and another for Storybook. The `sb add` command won't detect a vite config file in the Storybook dir (though we could), so it can end up referring to the wrong config file when setting things up.

💡 Solutions/Action items:

- We can start checking the vite config file from the storybook configDir first
- We should make this clear in our docs, if it isn't already
Repository: storybook
Issue: [Bug] framework and addon preview annotations not automatically applied in portable stories
Labels: bug,sev:S3,portable stories

Apart from setting annotations in a set up file by importing them, users, addons or frameworks can also programatically add preview annotations via the `previewAnnotations` preset. Here's an example of what a user can do (though I think it's not so common):

```tsx
// .storybook/main.js
export default {
  previewAnnotations: [
    "./src/stories/components",
    "./template-stories/core/preview.ts",
  ],  
}
```

And here's an example taken from our React renderer:

```tsx
// Example taken from @storybook/react/preset
export const previewAnnotations: PresetProperty<'previewAnnotations'> = async (
  input = [],
  options
) => {
  const docsConfig = await options.presets.apply('docs', {}, options);
  const features = await options.presets.apply('features', {}, options);
  const docsEnabled = Object.keys(docsConfig).length > 0;
  const result: string[] = [];

  return result
    .concat(input)
    .concat([join(__dirname, 'entry-preview.mjs')])
    .concat(docsEnabled ? [join(__dirname, 'entry-preview-docs.mjs')] : [])
    .concat(features?.experimentalRSC ? [join(__dirname, 'entry-preview-rsc.mjs')] : []);
};
```

The react renderer example is interesting because the renderer has a portable stories entrypoint, which already adds the necessary annotations (and excludes the docs ones which are not needed), so that problem is solved when users call `setProjectAnnotations` coming from `@storybook/react`. However, this pattern would need to be documented for anyone creating community frameworks so that they can do the same thing.

💡 Solutions/Action items:

- Do nothing, acknowledge this limitation
- Document this properly. Users need to solve it by hand, framework authors need to provide the annotations (solved by CSF4 if the defineConfig function comes from frameworks)
- Take this into account as part of a “preset handling” solution
Repository: storybook
Issue: [Bug] Storybook experimental features ignored in portable stories
Labels: bug,sev:S3,portable stories,rsc

In Storybook we normally use the `features`main.js property to allow users to toggle between certain experimental features like `experimentalRSC`, however those are not taken into account in portable stories:

```tsx
// .storybook/main.js
export default {
  features: {
    experimentalRSC: true,
  },
}
```

💡 Solutions/Action items:

- We can add support for these by parsing that property in main.js and injecting into a  `FEATURES` object in globalThis during a test run (in a virtual set up file or the like)
- We can discourage ourselves to use the features property whenever possible, and use parameters instead. The `experimentalRSC` flag was actually moved into `parameters.react.rsc` and that is automatically handled in portable stories
Repository: react
Issue: Bug: useId not stable on hydration with mid-render state update (React 18)
Labels: Status: Unconfirmed

React version: 18.3.1, 18.0.0

Does not occur in React 19, but we can't use React 19.

## Summary

I am fully expecting this to be programmer error, but this behavior deeply puzzles me and I can't find any documented reason for it.  If this isn't a bug in React, I would definitely consider it a bug in React documentation :)

As far as I can tell, this code follows all of the rules of hooks and documented invariants:

```jsx
function App() {
  const _id = useId() // If commented out, no warning.

  const [prevValue, setPrevValue] = useState(false)
  if (prevValue === false) setPrevValue(true) // If commented out, no warning.

  return <Inner />
}

// If this component's body is copied into `App`, no warning.
function Inner() {
  const id = useId() // <---- NOT STABLE!

  return <div id={id} />
}
```

However, it fails with a hydration mismatch error:

```
client.js:2427 Warning: Prop `id` did not match. Server: ":R6:" Client: ":R2:" Error Component Stack
    at div (<anonymous>)
    at Inner (client.js:23592:40)
    at App (client.js:23596:41)
    at body (<anonymous>)
    at html (<anonymous>)
    at Html (<anonymous>)
```

## Steps To Reproduce

I created a GitHub repo with a minimal reproduction. Steps to run are in the README: https://github.com/kognise/react-reproduction

Alternately, you should be able to see the same behavior by copying the top code sample into any server-rendered (and hydrated) React app.

## The current behavior

React prints the warning ``Prop `id` did not match. Server: ":R6:" Client: ":R2:"``.

## The expected behavior

I would expect this to just work with no issues.

Modifying the snippet as commented makes the warning go away.

Thanks!
Repository: pytorch
Issue: Test failures when migrating to SM89
Labels: module: cuda,module: tests,triaged

### 🐛 Describe the bug

See https://github.com/pytorch/pytorch/pull/140305
For some reasons, while running tests on L4 some tests started to fail, while other require increased tolerances

### Versions

CI

cc @ptrblck @msaroufim @eqy @mruberry @ZainRizvi
Repository: terminal
Issue: Trigger Redraw Crash
Labels: Area-Rendering,Issue-Bug,Severity-Crash,Product-Terminal

### Windows Terminal version

1.21.3231.0

### Windows build number

10.0.26335.0

### Other Software

_No response_

### Steps to reproduce

Unsure 😅

### Expected Behavior

To not crash

### Actual Behavior

`Access Violation` exception, see Watson Bucket 20f45815-12a1-7b5a-eadf-5a6297346f30
Repository: vscode
Issue: Win+R code ENTER opens irritating conhost.exe console window
Labels: bug,windows,workbench-os-integration,confirmed

If you run code from "Run" Explorer dialog (type "Win+R" on keyboard)  two windows are open: `code` editor and console `conhost.exe`.

conhost take precious space in Taskbar & occupy extra slot in Alt+TAB.

`Win+R code Enter` is a fast way to open an editor.

Workaround: instead of running `c:\Users\user\AppData\Local\Programs\Microsoft VS Code\bin\code.cmd` one could utilize `c:\Users\user\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Visual Studio Code\Visual Studio Code.lnk` by pressing `Win c o d e Enter` - basically from the Start menu.

Related bugs: 

* https://github.com/microsoft/vscode/issues/66750

I don't understand why Code installer puts `c:\Users\user\AppData\Local\Programs\Microsoft VS Code\bin` to `PATH` but not a parent directory... Maybe to avoid pollution of `PATH` with DLLs...

I wish I don't see irritating extra `conhost` window when I type `Win+R c o d e Enter`
Repository: go
Issue: crypto/tls: TestHandshakeClientECDHEECDSAAESGCM/TLSv12 failures
Labels: NeedsInvestigation

```
#!watchflakes
default <- pkg == "crypto/tls" && test == "TestHandshakeClientECDHEECDSAAESGCM/TLSv12"
```

Issue created automatically to collect these failures.

Example ([log](https://ci.chromium.org/b/8729631309123220881)):

    === RUN   TestHandshakeClientECDHEECDSAAESGCM/TLSv12
    === PAUSE TestHandshakeClientECDHEECDSAAESGCM/TLSv12
    === CONT  TestHandshakeClientECDHEECDSAAESGCM/TLSv12
    panic: test timed out after 6m0s
    	running tests:
    		TestHandshakeClientECDHEECDSAAESGCM/TLSv12 (0s)
    
    goroutine 392 gp=0x10c000105800 m=12 mp=0x10c000103808 [running]:
    panic({0xbebfa0?, 0x10c000026ba0?})
    	/home/swarming/.swarming/w/ir/x/w/goroot/src/runtime/panic.go:806 +0x168 fp=0x10c000341f10 sp=0x10c000341e60 pc=0x54eac8
    ...
    crypto/tls.runTestAndUpdateIfNeeded.func1(0x10c00040c200)
    	/home/swarming/.swarming/w/ir/x/w/goroot/src/crypto/tls/handshake_test.go:60 +0x7f fp=0x10c0003edf38 sp=0x10c0003edf00 pc=0xa0097f
    testing.tRunner(0x10c00040c200, 0x10c0003121b0)
    	/home/swarming/.swarming/w/ir/x/w/goroot/src/testing/testing.go:1764 +0x1db fp=0x10c0003edfc0 sp=0x10c0003edf38 pc=0x6cb8db
    testing.(*T).Run.gowrap1()
    	/home/swarming/.swarming/w/ir/x/w/goroot/src/testing/testing.go:1823 +0x25 fp=0x10c0003edfe0 sp=0x10c0003edfc0 pc=0x6cd8c5
    runtime.goexit({})
    	/home/swarming/.swarming/w/ir/x/w/goroot/src/runtime/asm_amd64.s:1700 +0x1 fp=0x10c0003edfe8 sp=0x10c0003edfe0 pc=0x556641
    created by testing.(*T).Run in goroutine 327
    	/home/swarming/.swarming/w/ir/x/w/goroot/src/testing/testing.go:1823 +0x94b


— [watchflakes](https://go.dev/wiki/Watchflakes)
Repository: rust
Issue: Bad `+ use<>` suggestion in nested macro_rules
Labels: A-lints,A-macros,T-compiler,C-bug,A-suggestion-diagnostics,E-needs-mcve,D-invalid-suggestion,D-edition,A-edition-2024,L-impl_trait_overcaptures,I-edition-triaged

Failure in migrating rocket 0.5.1 to 2024 due to the [_typed_stream](https://github.com/rwf2/Rocket/blob/v0.5.1/core/lib/src/response/stream/mod.rs#L292-L301) macro getting modified to:

```rust
macro_rules! _typed_stream {
    ($S:ident, $($t:tt)*) => (
        $crate::__typed_stream! {
            $crate::response::stream::$S,
            $crate::response::stream::stream,
            $crate::futures::stream::Stream,
            $($t)*
        } + use<'b>
    )
}
```

where that is invalid syntax. Just removing the `+ use<'b>` seems to make things work?

Unraveling this to a minimal example seems to be quite a bit of work since there are many layers of macros involved. This could also just be an issue with the rocket_codegen proc-macro respanning, but I did not unravel it that far.

### Meta

```
rustc 1.85.0-nightly (5e1440ae5 2024-12-01)
binary: rustc
commit-hash: 5e1440ae514d98ddfcbf1607acb64d41e07ef616
commit-date: 2024-12-01
host: aarch64-unknown-linux-gnu
release: 1.85.0-nightly
LLVM version: 19.1.4
```
Repository: yt-dlp
Issue: Embedding subtitles in preferred formats or convert other formats
Labels: enhancement

### DO NOT REMOVE OR SKIP THE ISSUE TEMPLATE

- [X] I understand that I will be **blocked** if I *intentionally* remove or skip any mandatory\* field

### Checklist

- [X] I'm asking a question and **not** reporting a bug or requesting a feature
- [X] I've looked through the [README](https://github.com/yt-dlp/yt-dlp#readme)
- [X] I've verified that I have **updated yt-dlp to nightly or master** ([update instructions](https://github.com/yt-dlp/yt-dlp#update-channels))
- [X] I've searched [known issues](https://github.com/yt-dlp/yt-dlp/issues/3766) and the [bugtracker](https://github.com/yt-dlp/yt-dlp/issues?q=) for similar questions **including closed ones**. DO NOT post duplicates
- [X] I've read the [guidelines for opening an issue](https://github.com/yt-dlp/yt-dlp/blob/master/CONTRIBUTING.md#opening-an-issue)

### Please make sure the question is worded well enough to be understood

I am looking to download subtitles in given formats. I prefer ASS first, then SRT if they have it, and anything else should be converted into ASS where possible.

Issue #57 asks a similar question in that the user wanted to download into SRT and convert anything else (though they were archiving from YouTube so dropped the format selection), but this extends it to look for other formats before resorting to conversion.

It seems a possible set of options would be `--sub-format "ass/srt" --convert-subs ass` but I'm not sure if this what I'm looking for, and worried if it'll also convert the SRT into ASS as well.

So my question is is it possible to download the ASS format as-is, otherwise download the SRT format as-is, otherwise download the best version and convert it to ASS? And if so how do I put that into the command line?

I should point out it's downloading everything fine, so this is just icing on the cake.

### Provide verbose output that clearly demonstrates the problem

- [ ] Run **your** yt-dlp command with **-vU** flag added (`yt-dlp -vU <your command line>`)
- [ ] If using API, add `'verbose': True` to `YoutubeDL` params instead
- [ ] Copy the WHOLE output (starting with `[debug] Command-line config`) and insert it below

### Complete Verbose Output

_No response_
Repository: rust
Issue: [rustc] SIGSEGV maximum backtrace depth reached
Labels: I-crash,P-low,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/
-->

### Code

Use javascript `x=10000; out="compile_error!(" + "concat!(".repeat(x) + '"A"' + ")".repeat(x); + ");"` to create rust code. 

Full code in [evil3.rs.txt](https://github.com/user-attachments/files/17984702/evil3.rs.txt)

```Rust
compile_error!(concat!(concat!(concat!(concat!(concat!(concat!(concat!(.....)))))));
```


### 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`:
```
<version>
rustc 1.83.0 (90b35a623 2024-11-26) (Arch Linux rust 1:1.83.0-1)
binary: rustc
commit-hash: 90b35a6239c3d8bdabc530a6a0816f7ff89a0aaf
commit-date: 2024-11-26
host: x86_64-unknown-linux-gnu
release: 1.83.0
LLVM version: 18.1.8
```

### Error output

```
error: rustc interrupted by SIGSEGV, printing backtrace

/usr/lib/librustc_driver-37bf60d83001ffbc.so(+0x1373cb9) [0x79575ff73cb9]
/usr/lib/libc.so.6(+0x3d1d0) [0x79575ea4c1d0]
/usr/lib/librustc_driver-37bf60d83001ffbc.so(+0x45e3d38) [0x7957631e3d38]
/usr/lib/librustc_driver-37bf60d83001ffbc.so(+0x45e522e) [0x7957631e522e]
/usr/lib/librustc_driver-37bf60d83001ffbc.so(_RNvMs_Cs1pTYV0gRL8Y_11rustc_lexerNtNtB4_6cursor6Cursor13advance_token+0xadd) [0x7957631e491d]
/usr/lib/librustc_driver-37bf60d83001ffbc.so(+0x3db789d) [0x7957629b789d]
/usr/lib/librustc_driver-37bf60d83001ffbc.so(+0x3e04e6c) [0x795762a04e6c]

### cycle encountered after 7 frames with period 8
/usr/lib/librustc_driver-37bf60d83001ffbc.so(+0x3e05187) [0x795762a05187]
/usr/lib/librustc_driver-37bf60d83001ffbc.so(+0x3e05187) [0x795762a05187]
/usr/lib/librustc_driver-37bf60d83001ffbc.so(+0x3e05187) [0x795762a05187]
/usr/lib/librustc_driver-37bf60d83001ffbc.so(+0x3e05187) [0x795762a05187]
/usr/lib/librustc_driver-37bf60d83001ffbc.so(+0x3e05187) [0x795762a05187]
/usr/lib/librustc_driver-37bf60d83001ffbc.so(+0x3e05187) [0x795762a05187]
/usr/lib/librustc_driver-37bf60d83001ffbc.so(+0x3e05187) [0x795762a05187]
/usr/lib/librustc_driver-37bf60d83001ffbc.so(+0x3e05187) [0x795762a05187]
### recursed 31 times

/usr/lib/librustc_driver-37bf60d83001ffbc.so(+0x3e05187) [0x795762a05187]

note: rustc unexpectedly overflowed its stack! this is a bug
note: maximum backtrace depth reached, frames may have been lost
note: we would appreciate a report at https://github.com/rust-lang/rust
help: you can increase rustc's stack size by setting RUST_MIN_STACK=16777216
note: backtrace dumped due to SIGSEGV! resuming signal
Segmentation fault (core dumped) 
```
Repository: go
Issue: x/benchmarks/sweet/cmd/sweet: TestSweetEndToEnd failures
Labels: NeedsInvestigation

```
#!watchflakes
default <- pkg == "golang.org/x/benchmarks/sweet/cmd/sweet" && test == "TestSweetEndToEnd"
```

Issue created automatically to collect these failures.

Example ([log](https://ci.chromium.org/b/8729636098417253009)):

    === RUN   TestSweetEndToEnd
        integration_test.go:36: phase setup @0s (duration: 1.690814682s)
        integration_test.go:36: phase sweet-get @1.690814682s (duration: 25.079331613s)
        integration_test.go:131: 	phase sweet-run-tile38 @26.77226649s (duration: 2m39.396455735s)
        integration_test.go:131: 	phase sweet-run-etcd @26.772219613s (duration: 2m46.225737556s)
        integration_test.go:131: 	phase sweet-run-go-build @26.772238392s (duration: 3m32.888872074s)
        integration_test.go:131: 	phase sweet-run-bleve-index @3m12.998030008s (duration: 1m13.089130537s)
        integration_test.go:131: 	phase sweet-run-gopher-lua @3m59.661207171s (duration: 39.735472257s)
        integration_test.go:162: no go.results results
        integration_test.go:176: output for esbuild:
    ...
            panic: Internal error
            
            goroutine 1 [running]:
            github.com/evanw/esbuild/internal/helpers.(*Timer).Log(0x0?, {0xc0070700e0, 0xc007bb2240, 0xc007bb2258, 0xc006bb0080, 0x3, 0xc000b6a3f0})
            	/home/swarming/.swarming/w/ir/x/w/targetrepo385663626/sweet/tmp/tmp-4/esbuild/src/internal/helpers/timer.go:83 +0x6ee
            github.com/evanw/esbuild/pkg/api.rebuildImpl({0xc009f761e0, {0xc007bb21f8, 0x1, 0x1}, {0x0, 0x0, 0x0}, {0x6, 0x1, 0x0, ...}, ...}, ...)
            	/home/swarming/.swarming/w/ir/x/w/targetrepo385663626/sweet/tmp/tmp-4/esbuild/src/pkg/api/api_impl.go:1635 +0x143a
            github.com/evanw/esbuild/pkg/api.(*internalContext).rebuild(_)
            	/home/swarming/.swarming/w/ir/x/w/targetrepo385663626/sweet/tmp/tmp-4/esbuild/src/pkg/api/api_impl.go:990 +0x29c
            github.com/evanw/esbuild/pkg/api.(*internalContext).Rebuild(...)
    ...
            	/home/swarming/.swarming/w/ir/x/w/targetrepo385663626/sweet/tmp/tmp-4/esbuild/src/cmd/esbuild/main.go:368 +0x9bc
            exit status 2
            [sweet] error: error preparing PGO profiles: failed to execute any profile benchmarks, see logs for more details
        integration_test.go:197: exit status 1
        integration_test.go:131: 	phase sweet-run-esbuild @3m6.168859846s (duration: 1m41.91694443s)
        integration_test.go:131: 	phase sweet-run-markdown @4m26.087241639s (duration: 22.346004884s)
        integration_test.go:131: 	phase sweet-run-gvisor @4m39.396760271s (duration: 2m35.249026287s)
        integration_test.go:131: 	phase sweet-run-cockroachdb @26.77230934s (duration: 32m12.812836519s)
        integration_test.go:36: phase sweet-run @26.770146295s (duration: 32m12.815137315s)
    --- FAIL: TestSweetEndToEnd (1965.68s)


— [watchflakes](https://go.dev/wiki/Watchflakes)