-
Notifications
You must be signed in to change notification settings - Fork 3k
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
segmentation fault when quit at hdr output #12666
Comments
i can reproduce this, though no idea what exactly happens there. just to make things clear, it only happens with [edit] |
Same finds here, mpv crashes. but how can I achieve HDR passthrough without using target-colorspace-hint? |
new founds hope it's helpful to locate the glitch. certain hdr video will keep on flashing less adjust mpv window size below are my settings: vo=gpu-next [HDR pq] [HDR hlg] |
the minimum settings to reproduce this crash report: crash.txt terminal also outputs a
[edit]
|
coming from this call in mpv Line 980 in 6ecdeda
in libplacebo https://github.com/haasn/libplacebo/blob/e987124b516507f4eb71a29b53e288d3c590aa75/src/swapchain.c#L65-L67 some problem with the pointer to pl_color_space and inappropriate freeing? |
after trying to fix a problem with rendering on the main queue (https://github.com/Akemi/mpv/commits/mac_vulkan_main/) the crash persists but already crashs when trying to load an HDR file.
|
This looks like TLS clean up touching module that has been unloaded. And we get BUS error. Could you save memory map before crash and compare this failing address? It is likely in something that is unloaded/reloaded. |
It seems to be caused by a double release (NSZombie) from libMoltenVK and libpthread, but I'm unsure how to resolve this without changing libplacebo api. When first frame is drawn, Line 1019 in 7e51939
It is released shortly afterward. However, when I set a breakpoint in lldb and here is the output:
|
Yes, your analysis seems to be consistent with what we already seen from @Akemi backtrace. There is allocation done inside
There is nothing wrong on libplacebo / mpv side. When VO thread is joined, pthread is calling TLS destructors for each key attached to given thread in I don't know Objective-C and not willing to learn just for that. But this should be obvious for someone familiar with their memory management model. NSData* colorVolData = [NSData dataWithBytes: &colorVol length: sizeof(colorVol)];
NSData* lightLevelData = [NSData dataWithBytes: &lightLevel length: sizeof(lightLevel)];
CAEDRMetadata* caMetadata = [CAEDRMetadata HDR10MetadataWithDisplayInfo: colorVolData
contentInfo: lightLevelData
opticalOutputScale: 1];
auto* mtlLayer = getCAMetalLayer();
mtlLayer.EDRMetadata = caMetadata;
mtlLayer.wantsExtendedDynamicRangeContent = YES;
[caMetadata release];
[colorVolData release];
[lightLevelData release]; Does this code look correct to you? As we can see there are three references,
All three references are released. Will they be refcounted correctly? Who is responsible for that? Like I said, I don't do objc, so not sure what is proper way to handle those memory allocations, but it is clear to me that it is fully caused by MoltenVK, as we (libplacebo / mpv) does not interact with those allocations at all. We only call vkSetHdrMetadataEXT and it is driver responsibility to copy/use the data in whatever way it needs. |
Unfortunately, I'm not an expert in memory management either and feel not confident drawing any conclusions yet. I plan to build MoltenVK to run some tests later. |
I confirmed that this issue is related to a bug in MoltenVK (KhronosGroup/MoltenVK#2399). I've fixed this bug and successfully tested it on my local env. Here is the dynamic library, can someone help verify if this resolves the problem? |
@NekoAsakura tested your moltenvk lib and the issue is fixed. i will keep this issue open till a new moltenvk release with the fix included is made, to keep track on this issue and we know when the blocker for the "vo=gpu-next" milestone is gone. thanks for looking into this. |
Important Information
Provide following Information:
master 02d009b
Sonoma
build by the toolchain of https://github.com/deus0ww/homebrew-tap
N/a
No
Reproduction steps
mpv --config=no --force-window=yes --idle=yes --vo=gpu-next --gpu-context=macvk --target-colorspace-hint=yes --log-file=test.log
Expected behavior
No error
Actual behavior
segmentation fault
seg.txt
Log file
test.log
Sample files
Any hdr video
The text was updated successfully, but these errors were encountered: