Reland "Fix build on macosarm64 and pay attention to USE_SANDBOX flag" #83
Conversation
|
It worked on MacOS as well or just compiled? |
|
I compiled and did a gst-inspect-1.0 on it. I did not test but I can run one now... BUMMER. SIGSEGV. Changing to draft. I will work on it tomorrow. It's late for me. |
|
GStreamer 1.22.4 No such issue on Linux |
|
You can see here #67 Plus I started on my branch to make it work. master...reinismu:gstcefsrc:macos-support but I'm not familiar with cmake and so so with MacOS. We might put a bounty on this thing. Running this plugin on MacOS would benefit us. |
|
We had a discussion and we decided to reward 1000$ to someone who can make this plugin work on Apple Silicon MacOS :) |
|
You are headed on the right path with what you have done in gstcefsubprocess. If If I were to do more work on this I would look to the CEF examples. Specifically the mac process helper. If I have time this evening I will see what I can come up with. |
|
So over lunch I took another look at this. The segfault is coming from CefString. In That is where the segfault happens. I will look into it more later today if I have time. |
|
At this point not sure what is going on here. From the code |
|
I thought maybe trying to load the library in gstcefsrc.c might be the issue, but as soon as I touch I will get a crash. I think this might be a mem allocator issue? CefString does an allocation, and so does CefScopedSandboxContext. I can do this which is fine given this is a simple structure on the stack. It has been a while since I have dealt with these types of issues. I guess if I were going to debug this further I would build CEF against my local tool chain. |
|
Closing this as I will not have any more time to tinker with this. |
|
@reinismu I would like to get this working at some point, but I simply do not have the time to dig into it. As I stated above the issue revolves around memory allocation AFAICT. There is a bad access at as you can see. I ran the CEF sample minimal without any issue, so I know CEF works on OS-X and the M series chips. At this point I don't know. I have a habit of closing PR's that I will not work on. However, given minimal amount of traffic here I will reopen in hopes someone will have an aha moment. |
|
Maybe someone from Centricular will get interested in this as well. I wonder if bad access is not caused by MacOS security stuff. The last I recall from my try was setting up process metadata |
|
I am compiling CEF locally, so I can at least debug a bit better. I will continue to look into this when I have some free time. |
Noted, I will check with our MacOS people :) |
Did any MacOS people seem interested? :) If price is too low, we can discuss it |
Hey, sorry for not following up, I mentioned this in our internal chat but no one picked up on it at the time. Maybe shoot us a mail at [email protected] to get the ball rolling :) |
|
Hi! @nirbheek told me I could have a look at this. The issue you were facing is that, on macOS, what you're calling is in fact an interposer, lazy-loader dylib: https://github.com/chromiumembedded/cef/blob/00118ddcdbdd6f7a5ed6e131417e6fb222bb33b0/libcef_dll/wrapper/cef_library_loader_mac.mm#L63-L65 Since that library was never initialized in the gstcef side, all CEF calls were rendered null pointer dereferences. I believe these changes should be sufficient to get you going, feel free to include and rebase them : SteveMcFarlin/gstcefsrc@cmake-macosarm64...amyspark:gstcefsrc:cmake-macosarm64 Bear in mind, however, that it seems CEF intends you to consume the library as an Apple framework -- the loader attempts to find the Framework relative to the executable's path, as when deployed into an app bundle. |
Thanks for looking into this :) Currently trying it out on my M2 Mac Mini. Compiled and set up everything on it. Sadly for me it segfaults :( Command Logs: I tried running Maybe I missed something? |
|
Compared with my linux build folder and realized that cef libs are missing it seems to try to run cef lib functions, but fails to do so |
|
Hi! That's correct, CEF libraries are missing because on macOS, there are none. What the Spotify tarball ships is instead a framework. I assume the intention of the developers was to consume it from an app, and so they architected the lazy load to resolve from said path ( |
Did you manage to run gstcefsrc on your end? If so could you provide example? |
|
@SteveMcFarlin Hey! Did you manage to run these changes on your end? I feel like something still is missing there or I'm doing something wrong as I didn't get it to work :/ |
|
@reinismu I have not yet. I am getting setup to test it either today or tomorrow. |
|
Build works fine for me on MacOS, but if I try to package it together with Nix I run into issue Here is the nix file https://gist.github.com/reinismu/31452372283a7b89715399bd7e763aad I did some investigation and came to that clang that is installed by Nix only throws this. Not working command if I call it with I tried both V15 and V16 Clang and they had the same issue Update: Adding |
amyspark
force-pushed
the
cmake-macosarm64
branch
from
8d60901
to
562dba7
Compare
|
Let's gooo! Thanks again everyone, this is so nice to finally see this solved :) |
|
@amyspark Was this commit 1255b31 related to my nix build issue? If it was it seems that it still won't build without Today was trying to get all my stack building in nix and run into issue :( It seems that it doesn't start the browser and just stucks here https://github.com/centricular/gstcefsrc/blob/master/gstcefsrc.cc#L786 Maybe this is something obvious in your eyes. If not I will just bundle all binaries and distribute it that way :) |
|
@Reinis No, that commit was related to an issue one of my colleagues found, CMake runs all steps linearly, and the last Can you send me the recipe you're using? Either here or through email (amy at centricular). |
Has anyone done this with a Rust development environment? I currently am using the threaded callback function from the After following the instructions in the README, |
Calling CefInitialize multiple times during a process lifetime is not supported: * https://magpcss.org/ceforum/viewtopic.php?f=6&t=16430 * https://www.magpcss.org/ceforum/viewtopic.php?f=6&t=466 * https://stackoverflow.com/questions/73172139/cef-can-only-be-initialized-once-per-process-this-is-a-limitation-of-the-underl Prior to #83 we used to have a ShutdownEnforcer class, but as it was causing issues on OSX we will simply no longer shut down CEF at all. We can revisit if needed, but this is preferable to crashing.
Calling CefInitialize multiple times during a process lifetime is not supported: * https://magpcss.org/ceforum/viewtopic.php?f=6&t=16430 * https://www.magpcss.org/ceforum/viewtopic.php?f=6&t=466 * https://stackoverflow.com/questions/73172139/cef-can-only-be-initialized-once-per-process-this-is-a-limitation-of-the-underl Prior to #83 we used to have a ShutdownEnforcer class, but as it was causing issues on OSX we will simply no longer shut down CEF at all. We can revisit if needed, but this is preferable to crashing. See #88 (comment) and below
@sidsethupathi Hi! Chromium's Sandbox v2, in macOS, enforces that the library runs within an application bundle context. This cannot be changed unless you build CEF from source and disable those checks manually; there are several places where the library tests that it's being loaded from a Framework, and that it's being done by the bundled helper apps. |
Calling CefInitialize multiple times during a process lifetime is not supported: * https://magpcss.org/ceforum/viewtopic.php?f=6&t=16430 * https://www.magpcss.org/ceforum/viewtopic.php?f=6&t=466 * https://stackoverflow.com/questions/73172139/cef-can-only-be-initialized-once-per-process-this-is-a-limitation-of-the-underl Prior to #83 we used to have a ShutdownEnforcer class, but as it was causing issues on OSX we will simply no longer shut down CEF at all. We can revisit if needed, but this is preferable to crashing. See #88 (comment) and below
The issue with the prior PR was USE_SANBOX was ON by default. I clearly did not pay attention enough to that. IMO the default should be OFF, and only be enabled if the arch is arm and the target is macos.
Additionally I had to add a few additional cmake options for the MacARM build otherwise I would get errors, and in one case lib_cef_dllwrapper was being compiled for i386. Let me know if there is something wrong there.
Apple clang version 15.0.0 (clang-1500.1.0.2.5)
Target: arm64-apple-darwin23.2.0
cmake version 3.24.1