Closed Envo closed 3 years ago
Fenrirthviti
commented
4 years ago In the future, please do not delete the report template.
I'll leave this open as it's something we'll need to address eventually, but it will likely be a while as this is a beta OS. A quick discussion in our Discord lead to concluding that crash appears to be related to CEF, and may require changes on their end to be compatible.
Envo
commented
4 years ago I just deleted the whole settings folder from the ~/username/Library and now it works. Guess you're right and the problem was one of the streamlabs widget.
Sorry for the mess i made, I hope some way it can be a help.
MisutaaAsriel
commented
4 years ago Is there any more details on why this is happening? Researching "Trace/BPT trap: 5", which is output by the terminal and listed as the termination signal, suggests this is failure at locating a dynamic library, and the OBS Log itself outputs:
os_dlopen(../obs-plugins/obs-browser->../obs-plugins/obs-browser.so): dlopen(../obs-plugins/obs-browser.so, 257): image not found
_osdlopen, or dlopen, is the system call for loading dynamic libraries, suggesting that this error has to do with loading the obs-browser. However, obs-browser.so exists in the application plugin directory, so I'm not sure why it's throwing a dlopen error, or even if the trap error is coincidence...
I have a stream this Saturday and can't afford to have OBS suddenly failing. It was working earlier today, with all my scenes, but trying to relaunch it an hour later results in this issue.
Fenrirthviti
commented
4 years ago If stream stability is a concern, I would recommend not running on untested beta operating systems.
MisutaaAsriel
commented
4 years ago Gee, thanks for the advice. I'm aware I'm on a beta operating system. I'm an Appleseed beta tester.
Replacing Chromium Embedded Framework.framework in the Application's framework directory (e.g. /Applications/OBS.app/Contents/Frameworks/) with a copy from the CEF Automated Builds page, located within the Release folder of the downloaded archive, fixes the crash, but breaks OBS's browser. (tested: cef_binary_86.0.18+gd3ead8b+chromium-86.0.4240.111_macosx64 [Stable]).
It would seem the copy distributed with OBS is outdated, and unstable on Big Sur, but the latest version is not OBS compatible.
Additional information:
I symlinked Plugins to obs-plugins, and this killed the os_dlopen(../obs-plugins/obs-browser->../obs-plugins/obs-browser.so): dlopen(../obs-plugins/obs-browser.so, 257): image not found error; this bit from the log would seem it was related to a renamed or incorrectly referenced plugins directory?
Fenrirthviti
commented
4 years ago Updating CEF is non-trivial, as we have very specific requirements and patches that were removed or deprecated in later versions. We are currently waiting on new OSR and audio support PRs to be addressed and merged, at which time we will be able to update CEF.
MisutaaAsriel
commented
4 years ago Fair enough. Updating to macOS build 20B5012d seems to temporarily have remedied the issue. However, it's possible going forward that older versions of CEF may be unstable on newer versions of macOS, especially considering version 75.x is over a year old.
mufunyo
commented
4 years ago I have a stream this Saturday and can't afford to have OBS suddenly failing.
Gee, thanks for the advice. I'm aware I'm on a beta operating system. I'm an Appleseed beta tester.
I'm having difficulty reconciling these two statements. Either you're aware you're beta testing, and are willing to live with the repercussions of that decision, or you have important things to stream that you can't afford to go wrong and stay on a stable operating system.
PatTheMav
commented
4 years ago To be fair, Apple Beta releases exist specifically for developers to update their software for the release, that's their raison d`être. That we don't have the resources to do so is an unfortunate situation, but "it's a macOS beta, don't expect it to work" is fine for a month or two after WWDC, but not this close to release. We should not accept this mentality and aim to do better.
Besides, this will affect all users upgrading to Big Sur of which there will be many and also everyone who got a new Mac over the holidays.
Regarding the error message os_dlopen(../obs-plugins/obs-browser->../obs-plugins/obs-browser.so): dlopen(../obs-plugins/obs-browser.so, 257): image not found, it is an unfortunate legacy issue that will pop up on every OBS launch and is "expected" (it's related to an older browser source plugin version iirc) - you will also find it in your logs when everything (including browser source) works as expected and not indicative of an issue.
MisutaaAsriel
commented
4 years ago This response has been formatted with emboldened text for ease-of-access and speed reading.
I'm having difficulty reconciling these two statements. Either you're aware you're beta testing, and are willing to live with the repercussions of that decision, or you have important things to stream that you can't afford to go wrong and stay on a stable operating system.
I am aware of the repercussions of beta testing. That's part of the point. I'm here to detect issues with the operating system and application compatibility and report them.
The fact that I have to use Big Sur as my daily driver relates to the fact that I am not in a financial position to own a secondary Macintosh system; not all Mac owners are well off. 😐 — I recently got back in to streaming, and the lack of viable native alternatives, and the even greater instability of OBS variants and alternatives on even standard OS releases, means that I must rely on OBS for the time being.
My admitted sass was due to the response I received. Telling a beta tester, who is there to report issues with a beta, that maybe they shouldn't be using the beta, is a complete non-response and unhelpful. It's a method of "passing the buck" on issues involving (but not always caused by) betas that I've increasingly become agitated with receiving as of late, so I apologize if my attitude came across as abrasive. But @PatTheMav put it best:
"it's a macOS beta, don't expect it to work" is fine for a month or two after WWDC, but not this close to release. We should not accept this mentality and aim to do better.
OBS was also stable up until the other night, exception being only light crashing related to corrupted/broken audio configurations (which were remedied by removing them from the profile JSON). — The CEF crash was, as one might say, out of the blue, with no clear cause nor changes to the operating system or OBS configuration which may trigger it.
I would also like to note: browser engine development moves at an accelerated rate compared to standard application software_. — I know I'm not an OBS developer; and moving to a different engine or upgrading to a newer version that calls for complete rewriting of other components (or reduces the feature set) is never easy. — However, relying on a specific version of a browser engine, when that engine is over a year outdated and compatibility is not guaranteed, is detrimental to both application stability and user security. Frequently, browser engines are updated to patch major security flaws, or to improve serious performance detriments, which put a user's machine at risk of both security and performance losses. "Waiting around" for a newer version to get what you want, with no guarantee it'll happen, is not a serious development strategy.
On another note, as I mentioned previuosly, @PatTheMav, symlinking obs-plugins to the Plugins directory (within the application's root contents directory) completely silenced the error. — I am aware that there is no issue, now, but for those not familiar with OBS' inner workings, and the fact that both this error message and the CEF crash at face value relate to the opening of a dynamic library**, others, as I myself originally did, may incorrectly infer this error to be related to the issue at hand. — For the future, silencing this error may aid in more effective and accurate user-end troubleshooting. Erroneous errors aid no one.
If I should submit a separate issue ticket for this, including steps used to silence the error, please let me know.
Fenrirthviti
commented
4 years ago Nobody is questioning the issue or that this is something we should fix. I never said that you shouldn't be testing things. You claim that you understand what being on a beta OS means, but then come in to our issue report stating that "I have a stream this Saturday and can't afford to have OBS suddenly failing."
Perhaps there's a miscommunication here, but that kind of comment implies that you're asking us to drop everything and respond to your request in a timely manner. That starts the conversation off with a sense of entitlement from your end. People don't run betas in production where stability is a concern, no matter how close to release they are. Any veteran beta tester will know this, so making that comment in the first place is something you should know better to even add to an issue report.
Again, to clarify, this is an issue, and we should address it. My specific concern was the implication that we should fix it by Saturday for a stream for a single user where stability was a concern. My comment was perhaps a bit too harsh, and I apologize for that, but there is fault on both sides here.
MisutaaAsriel
commented
4 years ago Perhaps there's a miscommunication here, but that kind of comment implies that you're asking us to drop everything and respond to your request in a timely manner. ... My comment was perhaps a bit too harsh, and I apologize for that, but there is fault on both sides here.
There definitely was a miscommunication then. My comment was not a request or demand that it be fixed in such an unreasonable time frame, but rather an expression of frustration, and a hope that, perhaps, someone else may have found a workaround, or temporary solution to the matter, as, as I stated, the occurrence of the issue was rather sudden and unexpected. — I have been running Big Sur since July, and have carried out a handful of streams using the software without this issue, including up until the other night.
My frustration was with a program that was working until it wasn't, with no clear explanation. The fact that it ran on the beta up to this point with no serious issue seemed to suggest that it wasn't the beta itself at fault; not entirely, anyways.
I struggle with communication, and sometimes I state things as matter-of-fact, that are [then] interpreted more as demands or other inaccurate inferences. It is a fact that I have a stream Saturday. It is a fact that it would cause problems for me if I were to miss it. It is also a fact that I myself have put myself into this "boat" by using a beta OS.
I made that statement to hopefully demonstrate the frustration this bug can cause. It is clear that I failed in that way. It was not a push for time, nor a demand that the entire OBS development team cater to me. I would never request such a thing. — If I was experienced in more than just Swift and Storyboards, I probably would have looked into trying to fix it myself, honestly.
Again, I do apologize for that.
WizardCM
commented
4 years ago Side note - sounds like this was also reported here - https://github.com/obsproject/obs-browser/issues/235
As one of the people who keep an eye on CEF and our browser source closely, the fact that this crash exists is a concern. I personally can't think of a reason why this crash would only occur on Big Sur. I wonder if the hack in https://github.com/obsproject/obs-browser/commit/a4e05bc8b93393b47d52b1f7a3a58ba2ab19028c that's only enabled on Windows would fix this crash on macOS without having to upgrade CEF (could someone find out?).
I will also add my voice to mention that updating CEF in an official OBS capacity requires a fair bit of work. For any version of CEF 3904 (Chrome 78) and above, our existing audio mixing code is unnecessary. Additionally, around 3945 (Chrome 79) above the CEF Audio API was changed, and would require an OBS update to work properly. As a non-macOS user, I'd be curious which CEF version explicitly fixes the issue for you, and whether the fix would be something we could backport into 3770 or 3809 (Chrome 76). As it stands - if you update CEF in OBS to anything higher than 3809, it is unlikely that the "Control audio via OBS" setting in the browser source will function correctly.
I will continue to keep an close eye on CEF so that we can update to something newer ASAP, but as others have mentioned it likely won't be in time for Big Sur, and so I hope we can find a temporary solution that doesn't require users modify the OBS files themselves.
MisutaaAsriel
commented
4 years ago I will continue to keep an close eye on CEF so that we can update to something newer ASAP, but as others have mentioned it likely won't be in time for Big Sur, and so I hope we can find a temporary solution that doesn't require users modify the OBS files themselves.
As it stands, even modifying the files does not work. It remedies the crash to replace CEF with a newer version, yes, but all browser content refuses to render, instead leaving a transparent square. I even tried CEF ver. 76.x (a single major revision up from OBS' 75.x), to no avail. — For users who have no reliance on browser content, this is a simple fix which would allow them to stream; but anyone who relies on browser content for widgets, media, or even graphical elements which OBS cannot provide (such as myself), this would be a non-option.
Replacing Chromium Embedded Framework.framework in the Application's framework directory ... with a copy from the CEF Automated Builds page ... fixes the crash, but breaks OBS's browser.
I know this may sound silly, coming from an inexperienced dev, but is there any reason OBS needs to use CEF on macOS? The system has a built in WebKit engine, including APIs for embedding webkit content such as WKWebView. WKWebView is also likely to be considerably less resource intensive over CEF, and provide great consistency with other system applications, and the system browser, Safari. — macOS isn't like Windows where, until recently, the included browser engine was a fork of IE (EdgeHTML), which whilst fairly standards compliant, had difficulty keeping up with WebKit & Blink.
It would require maintaining a macOS only fork, yes. Which is probably not ideal if you wish to maintain consistency between the macOS and Windows editions of OBS. However, it would guarantee increased compatibility with upcoming Apple Silicon Macs, as well as offer performance gains there too (by relying on the native system browser engine, rather than emulating CEF x86-64 via Rosetta 2, which would introduce overhead to an already performance heavy framework).
Fenrirthviti
commented
4 years ago Maintainability and someone putting in the effort are the primary reasons we don't. It's been discussed in the past, but nobody was really interested in doing the work, and there are limitations when it comes to a performance standpoint compared to CEF, IIRC. Those may have been resolved since it was last looked at, however, I am not sure offhand as it's been a while since we've looked at it.
WizardCM
commented
4 years ago I know this may sound silly, coming from an inexperienced dev, but is there any reason OBS needs to use CEF on macOS?
We depend on 3 things at their core for the best performance (some of which are currently not available on CEF on macOS but there's a CEF PR I'm keeping an eye on):
Additionally, we don't have a big enough team (let alone anyone full-time) to actively maintain specific features for macOS. We're able to keep dependencies up to date and fix bugs quickly (where possible), but not write & maintain something as.. flexible and ever-changing as a browser component.
MisutaaAsriel
commented
4 years ago Annnnnd it's crashing again.
Just to be clear, it was working again after moving to macOS build (20B5012d), but now, once again, with no clear reason and an arbitrary lapse in time from last launch, it is once again failing to launch.
As stated before, the method of termination being reported is Trace/BPT trap: 5, which the common consensus is a incorrectly referenced DYLIB. If this is accurate, and there was a way of knowing which library cannot be located, theoretically a terminal command is all it takes to tell macOS where it it actually located, or the library could be symlinked to the expected location.
Edit: Additionally, the behavior between launching OBS with CEF removed, and launching OBS with CEF replaced, is identical, suggesting OBS is rejecting other versions of CEF.
PatTheMav
commented
4 years ago I know this may sound silly, coming from an inexperienced dev, but is there any reason OBS needs to use CEF on macOS? The system has a built in WebKit engine, including APIs for embedding webkit content such as WKWebView.
Long story, short: There is no efficient way to generate a texture out of a WKWebView as WebKit’s out-of-process rendering was built to essentially disallow such shenanigans: https://developer.apple.com/forums/thread/129274?answerId=613174022#613174022
MisutaaAsriel
commented
4 years ago Long story, short: There is no efficient way to generate a texture out of a WKWebView as WebKit’s out-of-process rendering was built to essentially disallow such shenanigans: https://developer.apple.com/forums/thread/129274?answerId=613174022#613174022
Forgive me again if this sounds stupid, but is it not possible to create a texture out of the WKWebView's parent? I'm not too familiar with macOS' method of drawing the UI, but on iOS, I was once able to draw a WKWebView as a texture on a 3D object in SceneKit by capturing a visual representation of the parent UIView which contained it. — I'm not sure how performant that was as a texture, however, admittedly. It may have been very slow. But I know in another project it performed equally to the actual display when displayed as a UIImage side-by-side. — If AppKit works any similar to UIKit, would it be possible to "wrap" the WKWebView in a parent object and use the wrapper as the texture instead?
I've tried building obs-browser with Chrome 77, to see if perhaps a slight version bump would remedy the issue. 77, as @WizardCM pointed out, 78 and above renders audio mixing unecessary. However, after getting dependencies, building CEF (as the binaries dont include libcef_dll_wrapper*), and patching everything up, I get Unknown CMake command "install_obs_plugin_with_data".. Not sure how to go from here as I am as unfamiliar with CMake as I am flavors of C (C# not withstanding).
And there hasn't been any separate binary releases for OBS-Browser in a while, with the latest being built on Chrome 40. That's... a tad out of date.
Edit: Dropping CEF 3865 (Chrome 77), and lower versions, in directly under the Frameworks folder loads (Launching from the terminal with DYLD_PRINT_LIBRARIES=1 DYLD_PRINT_INITIALIZERS=1 DYLD_PRINT_WARNINGS=1 shows that CEF is loaded and initialized, and no errors are returned as long as the version exceeds 75.1.16), but nothing displays in OBS, so the version OBS-Browser being built with Chrome 75 clearly does not work with even slightly newer versions.
Edit [2]: Is there any way of debugging exactly what it's crashing on? I don't have the DYSM file for 26.0.2, which would allow me to symbolicate the crash log to know what file and line it's crashing on. — Currently seeing if I can successfully build the entirety of OBS Studio using the 10.15 (Catalina) SDK on Big Sur in the meantime.
MisutaaAsriel
commented
4 years ago Scroll down for important edits and information:
I wonder if the hack in obsproject/obs-browser@a4e05bc that's only enabled on Windows would fix this crash on macOS without having to upgrade CEF (could someone find out?).
I downloaded the source, @WizardCM, & commented out the correct portions, so it read:
//#ifdef _WIN32
/* Massive (but amazing) hack to prevent chromium from modifying our
* process tokens and permissions, which caused us problems with winrt,
* used with window capture. Note, the structure internally is just
* two pointers normally. If it causes problems with future versions
* we'll just switch back to the static library but I doubt we'll need
* to. */
uintptr_t zeroed_memory_lol[32] = {};
CefInitialize(args, settings, app, zeroed_memory_lol);
//#else
// CefInitialize(args, settings, app, nullptr);
//#endif, and built the application using the CI script. — Attempts to build with Xcode throws errors, as cmake makes some errors in building that have to be corrected manually, so command line building has to do; but I can still attach the debugger through XCode none the less via custom scheme.
This is the error it throws with the Windows fix: Thread 1: EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0)
It points to this portion, "stepping in" to CEF, as containing the error (arrow where error is thrown):
0x1f5e645d <+141>: callq 0x1f5e8cca ; symbol stub for: cef_initialize
-> 0x1f5e6462 <+146>: movl %eax, %ebxWith the "stock" configuration, no changes, this is the error it throws: Thread 1: EXC_BREAKPOINT (code=EXC_I386_BPT, subcode=0x0)
Again, with a similar "root" cause stepping into CEF (arrow where error is thrown):
0x25d5c45d <+141>: callq 0x25d5ecca ; symbol stub for: cef_initialize
-> 0x25d5c462 <+146>: movl %eax, %ebxIt would let me step further, except LLDB does not have the symbols for CEF loaded, and I personally wouldn't know how to load them as part of the debugging session of a "greater" program.
Edit: Using atos to symbolicate the crash log, it returns this for the relevant bits (ordered topmost to innermost):
atos -arch x86_64 -o [redacted]/Chromium\ Embedded\ Framework.dSYM/Contents/Resources/DWARF/Chromium\ Embedded\ Framework -l 0x2850f000 0x000000002a99164c 0x000000002a991a18 0x000000002cf0a474 0x000000002acf4e3d 0x000000002ac390ed 0x000000002ac3a041
net_service::InputStreamReader::RunReadCallback(int) (in Chromium Embedded Framework) (stream_reader_url_loader.cc:411)
net_service::InputStreamReader::RunReadCallbackOnJobThread(int, base::OnceCallback<void (int)>) (in Chromium Embedded Framework) (stream_reader_url_loader.cc:431)
base::internal::Invoker<base::internal::BindState<void (DevToolsUIBindings::*)(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&), base::WeakPtr<DevToolsUIBindings>, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, void (std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&)>::Run(base::internal::BindStateBase*, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) (in Chromium Embedded Framework) (bind_internal.h:654)
EVP_des_ede3_cbc_init (in Chromium Embedded Framework) (e_des.c:159)
base::sequence_manager::internal::SequenceManagerImpl::~SequenceManagerImpl() (in Chromium Embedded Framework) (sequence_manager_impl.cc:200)
base::sequence_manager::internal::SequenceManagerImpl::CreateTaskQueueImpl(base::sequence_manager::TaskQueue::Spec const&) (in Chromium Embedded Framework) (sequence_manager_impl.cc:318)If anybody can make sense of this, maybe have an idea of what's causing it, I'd be curious to hear about it. Address values were from a .crashlog. — It looks like it has something to do with threading and the task queue, to me?
Edit 2: As a side note, does anyone know why the bug onset is inconsistent? The first time OBS worked for months without issue, only to break. This time it worked after a system update only to break again. Both times OBS had been quit hours before and the machine left alone. This is bothering me, as you would expect the bug to, at the very least, be consistent. What allowed it to work before? What changed? These are the things that keep me up at night.
Edit 3: Another oddity: resetting OBS by way of deleting it's support directory restores functionality, and browser sources work. However, importing the old scene breaks OBS, suggesting that it is a matter of configuration? What is causing this bug?
Edit 4:
It has to do with the number of OBS Browser objects in your scene file, total, not just what's active. "Disabling" CEF temporarily, and removing a handful (about 3) of browser objects from all scenes (ensuring there are no stale references keeping them live), before enabling CEF, results in successful launch.
Does OBS properly destroy and recreate CEF objects when switching scenes, when "Shutdown source when not visible" is enabled? As this behavior suggest no, OBS creates all the browsers up front (most of my browser objects are set to shutdown when not visible.)
Edit 5: It's still crashing after close, but I can consistently get it to launch normally again by disabling CEF, removing one [1] browser object, and re-enabling CEF.
Which is... odd, behavior. What is it that changes when OBS exits?
Edit 6: Disabling CEF, successfully launching OBS and exiting, then re-enabling CEF now works, without removing browser objects. To summarize:
.bak to it's framework extension.PatTheMav
commented
4 years ago If AppKit works any similar to UIKit, would it be possible to "wrap" the WKWebView in a parent object and use the wrapper as the texture instead?
Yeah that's one issue, drawHierarchyInRect or snapshotViewAfterScreenUpdates are not available on macOS (seem to be UIView only. takeSnapshot on WKWebView itself also has a big performance overhead (tried it and had 50%-60% CPU usage just capturing the WebView and creating a Metal texture from it). Using a CARenderer seems more promising but that one is incompatible with the out-of-process rendering as mentioned by the Apple engineer.
MisutaaAsriel
commented
4 years ago
drawHierarchyInRectorsnapshotViewAfterScreenUpdatesare not available on macOS (seem to be UIView only...)
Hmmm... Now that catalyst is widely available to developers, do you think a version of OBS Browser could be built upon that, with UIKit, within a .framework? It would only be compatible with macOS Catalina and above, unfortunately (which isn't ideal; would require maintaining the CEF version for older platforms.), but in theory it would offer the featureset you mention. (snapshotViewAfterScreenUpdates & drawHierarchyInRect are both available to Mac Catalyst applications and frameworks as of version 13. {Catalyst follows iOS versioning schemes, so Catalyst 13 is iOS 13, or macOS Catalina 10.15})
With the bug at hand, does anyone have an idea why launching, and successfully exiting, OBS, with CEF removed, allows OBS to launch with CEF restored for the next launch? Or why exiting OBS (whether successfully or not) with CEF enabled prevents it from launching it with CEF on next launch? As well as why the number of OBS Browser sources contained in the collection effects the severity of this bug? All of this seems like it wouldn't be possible if CEF was merely failing to initialize at all on Big Sur.
StobyWan
commented
3 years ago I got the Big sure release Today and OBS 26.0.2 will not open anymore:here is my crash log
Maintainer edit: Moved the crash log to a gist as it was extremely noisy as a comment: https://gist.github.com/Fenrirthviti/e5fb3d4940bfefcdf7b579f65bb9e1b0
PatTheMav
commented
3 years ago At least in my tests I didn't have any issues with OBS - BrowserSource works fine as do a few other plugins. WindowCapture/DesktopCapture was fine, VirtualCam works fine.
So I wasn't able to replicate it and will now update my second Mac to Big Sur as well and redo the checks.
@StobyWan would you be able to make a backup of your current settings (found at ~/Library/Application Support/obs-studio/) by renaming the basic folder, then launch OBS? It should give you a clean slate and it'd be interesting to know if it crashes then as well.
Next, please add a browser source, quit OBS, relaunch it. Report back if/when crashes occur and upload the logs on crash as a Gist and link it.
MisutaaAsriel
commented
3 years ago @PatTheMav Just a heads up, I am on Release Candidate 2 (Which is the public release of Big Sur), and OBS still crashes with the same error as before, and the same crash log as before. @StobyWan's crash log they submitted previously matches the crash logs of others here closely. — I have only 4 browser sources within my current collection, 8 counting browser source reference copies between scenes.
As stated previously, OBS launches when provided a clean slate, but will return to crashing on next launch once a number of browser sources have been added. — It's not just about CEF itself, but the number of (browser) sources OBS initializes in the current scene collection — This means that you cannot have more than one or two browser sources in a scene collection, accounting for all scenes, before the bug is triggered.
As another note: Hiding (clicking the eye icon by the source name) all browser sources before exit, combined with the previous "CEF-less pre-launch" trick, appears to let OBS launch normally without removing browser sources.
Suggestion: In a fresh OBS instance, slowly add and configure OBS browser sources within the current scene selection, closing and relaunching OBS between configuration of one source and the addition of another. This should eventually trigger the bug, if hardware related bugs are not a factor.
PatTheMav
commented
3 years ago The kind of website open in those browser sources also is irrelevant I take it? Because then it should be an easier path to reproduce.
MisutaaAsriel
commented
3 years ago The kind of website open in those browser sources also is irrelevant I take it? Because then it should be an easier path to reproduce.
@PatTheMav actually I'm left head scratching now. I decided to test further myself, and, whilst it behaved identically in earlier betas, the behavior now seems un-reproduceable on fresh/new scene collections, including with browser URLs from other collections. However, I had previously tried rebuilding one of my collections, and at some point the bug appeared. It would seem that the bug is related to a combination of factors, some of which are currently unknown, and some which are known (number of browser sources).
On the other hand, A new, simpler workaround has been discovered:
Scene Collection -> New)On next launch, it should not crash, and switching to the original scene collection, as long as the blank scene was the last scene used, will not crash the application.
If OBS cannot be opened to set this up, previous "CEF-less" workaround can be used for configuration.
Here is a copy of an example scene which crashes OBS without the above workaround: https://gist.github.com/MisutaaUrufu/a05e250d13851a041fa8cd1f2223d755
Edited to provide proper Gist link
PatTheMav
commented
3 years ago Just tried to replicate it, no issues for me.
Before relaunch:
12:47:52.102: All scene data cleared
12:47:52.102: ------------------------------------------------
12:47:52.103: Switched to scene 'Scene'
12:47:52.104: Added scene collection 'New Collection' (clean, New_Collection.json)
12:47:52.104: ------------------------------------------------
12:47:58.614: All scene data cleared
12:47:58.614: ------------------------------------------------
12:47:58.617: Switched to scene 'Scene'
12:47:58.622: ------------------------------------------------
12:47:58.622: Loaded scenes:
12:47:58.634: - scene 'Scene':
12:47:58.634: ------------------------------------------------
12:47:58.634: Switched to scene collection 'Default Collection' (Default_Collection.json)
12:47:58.634: ------------------------------------------------
12:48:05.238: User added scene 'Blank Scene'
12:48:05.238: User switched to scene 'Blank Scene'
12:48:13.276: All scene data cleared
12:48:13.276: ------------------------------------------------
12:48:13.279: Switched to scene 'Scene'
12:48:13.279: ------------------------------------------------
12:48:13.279: Loaded scenes:
12:48:13.279: - scene 'Scene':
12:48:13.279: ------------------------------------------------
12:48:13.280: Switched to scene collection 'New Collection' (New_Collection.json)
12:48:13.280: ------------------------------------------------After Relaunch:
12:49:10.615: ==== Startup complete ===============================================
12:49:10.633: All scene data cleared
12:49:10.634: ------------------------------------------------
12:49:10.641: Switched to scene 'Scene'
12:49:10.641: ------------------------------------------------
12:49:10.641: Loaded scenes:
12:49:10.641: - scene 'Scene':
12:49:10.641: ------------------------------------------------I've disabled all plugins and started with an entirely fresh configuration. Also had no crash with my existing setup which includes a browser source after updating to Big Sur either.
MisutaaAsriel
commented
3 years ago @PatTheMav does anything strike you as "off" or deprecated in the attached scene file above?
At this point I am wondering if there was a change in formatting, or syntax to a particular plugin related to CEF, or a particular feature or addition (audio, video, or source filter) which conflicts with CEF during the initialization phase of the OBS browser plugin.
StobyWan
commented
3 years ago Thank you all, I attempted 3 things:
PatTheMav
commented
3 years ago According to that log the crash was caused by advanced-scene-switcher.so - to disable plugins you need to rename the plugin folder in /Library/Application Support/obs-studio (plugin developers still use that location unfortunately).
73Minstrel
commented
3 years ago ~/library/application support/obs-studio/basic/
and Deleted my Scenes Folder and Voila its Working
dkorzhevin
commented
3 years ago This doesn't helps at all. Tried everything listed on this page and nothing helps, app crashing every-time I move window, expand it, etc.
Completely unusable after upgrade to Big Sur.
StobyWan
commented
3 years ago i was able to get it running but adding the "Browser" to any scene does crash the app every time due to CEF most likely?? without a browser window it does make some tasks difficult.
StobyWan
commented
3 years ago https://gist.github.com/StobyWan/1ef35eabcfd57ca6b291acf444817c45 here ias the "Browser" plugin error log from Big Sur Crash
kellemar
commented
3 years ago Same issue with Big Sur and OBS with regards to CEF. Current system is Big Sur on a Macbook 16" 32GB RAM.
Process: obs [5353]
Path: /Applications/OBS.app/Contents/MacOS/obs
Identifier: com.obsproject.obs-studio
Version: 26.0.2 (26.0.2)
Code Type: X86-64 (Native)
Parent Process: ??? [1]
Responsible: obs [5353]
User ID: 501
Date/Time: 2020-11-15 18:07:38.021 +0800
OS Version: macOS 11.0.1 (20B29)
Report Version: 12
Bridge OS Version: 5.0.1 (18P2561)
Anonymous UUID: 9A532D82-F7AE-65B9-E84E-D0DA05A671E6
Sleep/Wake UUID: A98D045E-9971-43F9-8E8B-B582B68372B6
Time Awake Since Boot: 34000 seconds
Time Since Wake: 370 seconds
System Integrity Protection: enabled
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Exception Type: EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0000000000000002, 0x0000000000000000
Exception Note: EXC_CORPSE_NOTIFY
Termination Signal: Trace/BPT trap: 5
Termination Reason: Namespace SIGNAL, Code 0x5
Terminating Process: exc handler [5353]
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 org.chromium.ContentShell.framework 0x000000001cfc2041 0x1a897000 + 41070657
1 org.chromium.ContentShell.framework 0x000000001cfc10ed 0x1a897000 + 41066733
2 org.chromium.ContentShell.framework 0x000000001d07ce3d 0x1a897000 + 41836093
3 org.chromium.ContentShell.framework 0x000000001f292474 0x1a897000 + 77575284
4 org.chromium.ContentShell.framework 0x000000001cd19a18 0x1a897000 + 38283800
5 org.chromium.ContentShell.framework 0x000000001cd1964c 0x1a897000 + 38282828
6 org.chromium.ContentShell.framework 0x000000001a8995d4 cef_initialize + 276
7 obs-browser.so 0x000000001a7ff122 CefInitialize(CefMainArgs const&, CefStructBase<CefSettingsTraits> const&, scoped_refptr<CefApp>, void*) + 146
8 obs-browser.so 0x000000001a7a9fa1 obs_browser_initialize + 1601
9 obs-browser.so 0x000000001a7ac705 RegisterBrowserSource()::$_1::__invoke(obs_data*, obs_source*) + 21
10 libobs.0.dylib 0x0000000102f3c44b obs_source_create_internal + 2219
11 libobs.0.dylib 0x0000000102f58995 obs_load_source_type + 181
12 libobs.0.dylib 0x0000000102f58dc1 obs_load_sources + 177
13 com.obsproject.obs-studio 0x000000010018a5d6 OBSBasic::Load(char const*) + 1510
14 com.obsproject.obs-studio 0x000000010018efd6 OBSBasic::OBSInit() + 1670
15 com.obsproject.obs-studio 0x000000010016b7c3 OBSApp::OBSInit() + 499
16 com.obsproject.obs-studio 0x000000010016f5c7 main + 5287
17 libdyld.dylib 0x00007fff20345631 start + 1
svjp6049
commented
3 years ago Same problem here. OBS crashes instantly if there are browser sources.
[Maintainer edit: removed crash log text, can be viewed from message edit history to avoid cluttering the thread.
Fenrirthviti
commented
3 years ago Thanks everyone for confirming this issue. At this time, we don't need additional crash logs as they are not helpful to solving the problem. If you are attaching a crash log (really anywhere, not just this thread!), please make sure to upload it to somewhere like pastebin or a gist first, as dumping the entire text of the crash log in a comment makes the thread very difficult to read. Thanks!
svjp6049
commented
3 years ago Got it, sorry! Looking forward to the fix.
tonymooremusic
commented
3 years ago Hi - Sorry if this is the wrong thread, as a non tech person,I just updated to Big Sur without checking compatibility with OBS- and have a different problem. I am running a macbook and two external monitors, I usually use FULL SCREEN Projection of preview window on to both monitors - but now If I try - it just makes my macbook into full screen. - so I can no longer see the controls/and scenes to operate OBS, when I close the projection, it crashes more often than not..I realise that there are still issues being sorted out and though this feedback might help...Also, does anyone else have this problem?
All the best Tony
PatTheMav
commented
3 years ago @StobyWan Just to get this right - you moved away your configs/reset OBS so it launched properly but the moment you added a browser source it crashed right? So empty OBS, no other scenes, no fancy configs, just the browser source?
It's important to rule out other factors there because it's hard to replicate the bug if it requires scene setups and all.
Alas I haven't had any crashes with OBS on Big Sur so far and the only way to get a similar crash report was running OBS outside of an application bundle.
If anyone of you wants to spend the time, you can try re-compiling OBS with this CEF version (https://cef-builds.spotifycdn.com/cef_binary_76.1.13%2Bgf19c584%2Bchromium-76.0.3809.132_macosx64.tar.bz2), using the full-build-script to bundle OBS up, then download the debug symbols (https://cef-builds.spotifycdn.com/cef_binary_76.1.13%2Bgf19c584%2Bchromium-76.0.3809.132_macosx64_debug_symbols.tar.bz2) and symlink the .dsym file right next to CEF's .framework file in the bundle. This should give more info in the crash dump.
Also you can create an empty framework project in Xcode, then edit the Run scheme to launch the OBS.app instead which will attach lldb to OBS' process.
(I already did all the above, but as I mentioned - no crashes for me).
StobyWan
commented
3 years ago @PatTheMav this was a fresh install with no old scenes and the scene that crashes is blank besides the Browser window i am trying to add. I will work to follow your instructions when i have time today and get back to you with results.
PatTheMav
commented
3 years ago Awesome, @MisutaaUrufu already went down that path trying to symbolize the crash, but I wasn't sure if they matched the debug symbols with the right framework version. Iirc our 3770 build has some custom changes done to it which makes it incompatible with the official debug symbols.
soniq111
commented
3 years ago This is what I noticed: I was able to add several browser sources to a blank scene and then add more things no problem. Then after streaming for about 2 hours I would get an Error complaining about application memory and it said OBS was using 100+ gb of memory, OBS then crashed sometime after.
If I started with a blank screen and added a bunch of stuff and then added browser sources afterwards then OBS would crash immediately
kellemar
commented
3 years ago @StobyWan Just to get this right - you moved away your configs/reset OBS so it launched properly but the moment you added a browser source it crashed right? So empty OBS, no other scenes, no fancy configs, just the browser source?
It's important to rule out other factors there because it's hard to replicate the bug if it requires scene setups and all.
Alas I haven't had any crashes with OBS on Big Sur so far and the only way to get a similar crash report was running OBS outside of an application bundle.
If anyone of you wants to spend the time, you can try re-compiling OBS with this CEF version (https://cef-builds.spotifycdn.com/cef_binary_76.1.13%2Bgf19c584%2Bchromium-76.0.3809.132_macosx64.tar.bz2), using the full-build-script to bundle OBS up, then download the debug symbols (https://cef-builds.spotifycdn.com/cef_binary_76.1.13%2Bgf19c584%2Bchromium-76.0.3809.132_macosx64_debug_symbols.tar.bz2) and symlink the
.dsymfile right next to CEF's.frameworkfile in the bundle. This should give more info in the crash dump.Also you can create an empty framework project in Xcode, then edit the
Runscheme to launch theOBS.appinstead which will attachlldbto OBS' process.(I already did all the above, but as I mentioned - no crashes for me).
I recreated a new scene with nothing inside and added a browser source, and it was an immediate crash. This happened on my MBP 16 with Big Sur, and also now, on the M1 with Big Sur.
I've attached a gist of the log. https://gist.github.com/kellemar/16c71fbea9253e895f6f20080a6a5b3e
elpop
commented
3 years ago Crash happen on OBS 26.0.2 and Mac OS Big Sur 11.0.1 (release), I edit my .json scene and remove all the browse based sources and OBS can star and work as usual. The problem is when invoque a Browser-based source o try to add one.
The same OBS and scenes was working good on Mac OS Catalina. OBS_Crash_20201116.txt
aaronaustin
commented
3 years ago @elpop I'm having the same problem on Big Sur but I can't seem to find the .json file for the scene. Where is it located?
Nevermind. I found it and it worked! Thanks so much!
elpop
commented
3 years ago @elpop I'm having the same problem on Big Sur but I can't seem to find the .json file for the scene. Where is it located?
Nevermind. I found it and it worked! Thanks so much!
Just for the record:
~/Library/Application\ Support/obs-studio/basic/scenes/
TechTeacher12
commented
3 years ago Does anyone have time to help me out? Here is my original post on the OBS forum.
Hi! First time post! I am a technology teacher in an elementary school. We use OBS to live stream our school news every day. Our broadcast is awesome... live weather, multiple anchors, special segments, and even animated transitions created by students. Like an idiot, I updated our MacBook Pro to Big Sur... Now, OBS can't open.
Does anyone have any advice for me? What can I do to be able to access OBS? When I try to open, it "quits unexpectedly". I am kicking myself for doing this update.
I know this isn't a very important problem... but having a fun news cast for our students is a bright spot in the bleak days of hybrid learning with children wearing masks during a pandemic. Any advice you can offer is greatly appreciated.
Thank you, Mrs. Greene
PS: I can't include a log file because I can't open the program.
aaronaustin
commented
3 years ago @TechTeacher12 The problem I encountered was due to an issue that happens when you have browser sources in your scene. From what I understand it is a problem with the version of Chromium OBS is using. At any rate, thanks to @elpop helping out, I was able to edit the .json file for my profile by removing all of the objects that referenced browser-based sources. That removed all the browser sources and allowed me to start OBS.
This is where the .json file is located: ~/Library/Application\ Support/obs-studio/basic/scenes/<Your_Scene_name>.json
I hadn't given my Scene a name so it was Untitled.json
You'll find the sources in an array like this:
"sources": [
{
"balance": "0.5",
....
"id": "browser"
},
{
"balance": "0.5",
...
"id": "ffmpeg"
}
]If you're familiar with .json then you won't need the rest of this, but just in case. I honestly can't remember since I deleted all the references, but I think that OBS uses the id to set the type of source. I basically searched the file for 'browser' and then deleted the entire object with the browser id. I would save a backup copy just in case. For example, with the above array, it would look like this after deletion:
"sources": [
{
"balance": "0.5",
...
"id": "ffmpeg"
}
]There's a lot more in the file, but deleting just the objects that have browser sources worked for me.
Nothing surprising, but I hope this report can help to make OBS available on the new macOS as soon as it's get's released.
Once you starts OBS on Big Sur, it's quit unexpectedly, here's the trace:
[Maintainer Edit] Snipped the crashlog and put it here as I was getting tired of having to scroll 8 pages to get to the discussion.