https://bugs.winehq.org/show_bug.cgi?id=48732
--- Comment #6 from Gabriel Ivăncescu gabrielopcode@gmail.com --- (In reply to Zebediah Figura from comment #5)
(In reply to Gabriel Ivăncescu from comment #4)
Created attachment 66627 [details] Test workaround
Does this patch help? It should avoid the call if the window has no owner to begin with.
The issue is that this shouldn't be needed, as there's nothing in the call, so I don't know if it's suitable for upstream, but that's up to Zeb. Personally I'm fine with it, if it helps.
I don't know if it's a game bug that can't handle a redundant call to SetParent for example, or if there's a deeper issue with Wine.
That doesn't seem right, and I'd be surprised if it helps. If the window is parentless it shouldn't result in any messages getting sent to the application.
Right, I was thinking the app does something weird like hook into SetParent. Or perhaps the call exposes a race condition of a deeper issue, which is a bigger concern. (this would just "hide" it)
The refcount issue I mentioned earlier seems harmless. For some reason, it is caused by:
if (filter->presenter) IVMRImagePresenter9_Release(filter->presenter);in quartz/vmr9.c vmr_destroy function, which decreases the refcount after it was already zero. However, this doesn't really seem to do anything, since on the filter side, it checks if (!refcount) and otherwise does nothing, so it seems harmless and likely not the culprit.
That doesn't seem right either; the allocator/presenter is a separate object with its own refcount. Are you sure that's where the dereference is coming from?
I'm as puzzled as you are, but yes, that's where it happened for some reason; I added traces between each call to verify this. It could be an application bug, though (which is also silently ignored on Windows). I'm curious, do you not get this behavior when you try it? (I mean the refcount thing)