-
-
Notifications
You must be signed in to change notification settings - Fork 8.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Crash when using OBS Virtual Camera in Chrome #4615
Comments
Thanks for the new crash log. This is a strange place to be crashing, as this code path only occurs when all of the following succeed:
So the pointer for the sample data should be valid. Do you happen to know what Chrome is trying to dereference at OnIncomingCapturedBufferExt+0x199? |
See the source-code link, which takes you to this: buffer_pool_->HoldForConsumers(buffer.id, 1); The crash is when dereferencing receiver_ to load the v-table pointer, which is being loaded in order to call OnFrameReadyInBuffer. From the code-search link you can easily go to the declaration of receiver_, which is this: // The receiver to which we post events. |
Sorry, I missed that link initially, I got too excited with the new stack trace :). |
When you say that you don't implement IMediaFilter::Stop does that mean that Chrome might be telling you to stop but you keep sending data? I don't work on the media team so I'm unclear on how all of this ties together or what the contract is. It would be nice to have a repro. |
That's what I'm thinking might be happening. Our output thread keeps running until the filter is unloaded, so even after a Comparing our filter code to the Microsoft SDK samples does make me think we might be missing a few bits and pieces though. A repro case would indeed be very useful. Is there anything else in common between the Chrome crash reports? |
There's a new type of crash discovered (https://bugs.chromium.org/p/chromium/issues/detail?id=1240085) with the same root cause: the OBSVirtualCamera keeps sending frames at chrome even though it should be stopped. In the crashlogs I see two threads with the following callstacks:
Second thread:
So, the callback is called on already destroyed/being destroyed instance. In no way can chrome protect against that. I'm not sure exactly what caused the destruction of the video capture device. The callstack indicates what that's not a regular path. Still, I suggest OBS software to add some locks and flags which to defensively not call chrome callbacks after it has stopped requesting frames. |
Hello, would you please bump the priority of this one? This is a 6th top crash in the utility process in the stable chrome. |
I'll bump the priority on it. |
Just to request to anyone watching this thread, this is difficult for us to debug without replication steps. Can someone who is experiencing the issue provide them so we can perform additional debugging on our side? I've spent a little bit of time playing around with various Chrome test/webcam features (enabling/disabling/swapping devices/changing modes/etc.) and I cannot replicate the crash, so there is something missing to what exactly is triggering it. Are there any specific websites that happen to be causing this crash that can be provided? Is the virtual output active at the time of the crash in OBS, or is this replicated just with the virtual camera device registered to the system? Distilling down the actual scenarios in which this causes a crash will be helpful. |
Sadly, we don't have any reproduction guide. We only see this in automatic crash reports. Seems like the affected users didn't file bug reports to google or chrome. From the callstack in other threads it looks like some kind of error in ipc communication needs to be happen to trigger the crash in chrome (mojo::InterfaceEndpointClient::NotifyError). Maybe it's happening on exit from chrome and therefore isn't user visible. No information about Obs configuration is available to our crash reporting systems, so here I also can't say anything. Could you point me to the code which passes the frames to the Chrome in this repository? I've failed to find it myself. |
I suspected as much, but wanted to confirm either way. Code for our dshow filter is here: https://github.com/obsproject/obs-studio/tree/master/plugins/win-dshow/virtualcam-module |
I believe that issue is affecting me in multiple programs. It kept crashing Firefox Aurora 94.0b9 (at all websites). Some of my crash reports can be found here and here. VLC seemed to only be able to capture the first frame, with the default DirectShow options (other than changing the video device name of course). After seeing this GitHub issue, I tried it in Chromium 95.0.4638.54 and it worked flawlessly. I tried it in Firefox again and didn't encounter any crashes. However, on some sites, the video appeared to be corrupted. See the screenshot below. Unfortunately, I have no idea how to reproduce the crashes in Firefox. It seems to be quite the Heisenbug. Edit: Sorry. It seems that there are better issues that I could have reported this in. I'm about to fall asleep at my desk. |
This should be fixed by 0f08432. Please report if you continue to see this behavior in OBS 28 or above. |
Operating System Info
Windows 10
Other OS
No response
OBS Studio Version
27.0.0-rc2
OBS Studio Version (Other)
No response
OBS Studio Log URL
Not available
OBS Studio Crash Log URL
Not available
Expected Behavior
No crashes
Current Behavior
Some Chrome users hit crashes when using OBS. I am a Chrome developer so I receive and analyze these crashes. I have not reproduced these crashes and I don't know what the users are doing. This was initially reported here:
CatxFish/obs-virtual-cam#141
The tracking bug on the Chromium side is crbug.com/1137308 but this link is just for my purposes - it has restricted viewing.
Since then 27.0 rc2 has become available and I have restricted my analysis to those crashes since PDBs are available.
I did some crash queries and found seven related crashes with the 27.0.0 OBS. It's too early to tell if the crash rate will be affected by the newest version but I don't think so. Here is the data from one of the crashes, with the OBS symbols:
(note that I changed the spelling of thread to threed to stop an emoji from being inserted there)
As before it is a NULL dereference crash. The crash is right after a call to media::ReadyFrameInBuffer::ReadyFrameInBuffer and it is clear that receiver_ is NULL when we try to call OnFrameReadyInBuffer. You can see the code right here:
https://source.chromium.org/chromium/chromium/src/+/master:media/capture/video/video_capture_device_client.cc;l=633?q=video_capture_device_client.cc
Does that help?
BTW, one of the crashes had a slightly different build of the DLL. The version number is the same but the build date was April 2nd instead of April 12. FWIW:
Steps to Reproduce
Unknown.
Anything else we should know?
No response
The text was updated successfully, but these errors were encountered: