Aging test crash in WmfMediaSampler

After about 4 hours of runtime, we are experiencing what appears to be a deallocation crash inside the new media framework.

BasicProj.exe!FOutputDeviceWindowsError::Serialize(const wchar_t * Msg, ELogVerbosity::Type Verbosity, const FName & Category) Line 95	C++
BasicProj.exe!FOutputDevice::Logf__VA(const wchar_t * Fmt, ...) Line 145	C++
BasicProj.exe!FDebug::AssertFailed(const char * Expr, const char * File, int Line, const wchar_t * Format, ...) Line 220	C++
BasicProj.exe!FMallocBinned::FreeInternal(void * Ptr) Line 630	C++
BasicProj.exe!SharedPointerInternals::DestroyObject<TArray<unsigned char,FDefaultAllocator> >(void * Object) Line 279	C++
BasicProj.exe!SharedPointerInternals::FSharedReferencer<1>::operator=(SharedPointerInternals::FSharedReferencer<1> && InSharedReference) Line 402	C++
BasicProj.exe!FMediaSampleBuffer::ProcessMediaSample(const void * Buffer, unsigned int BufferSize, FTimespan Duration, FTimespan Time) Line 64	C++
BasicProj.exe!FWmfMediaSampler::OnProcessSample(const _GUID & MajorMediaType, unsigned long SampleFlags, __int64 SampleTime, __int64 SampleDuration, const unsigned char * SampleBuffer, unsigned long SampleSize) Line 105	C++

The crash seems to be triggered by the following line:
https://github.com/EpicGames/UnrealEngine/blob/4.5/Engine/Source/Runtime/Media/Public/Common/MediaSampleBuffer.h#L64

Hi num3ric,

A few questions.

  • Did this happen while using the 4.5 Preview? If so, do you see the same behavior with the released version of 4.5?
  • Did you build the Engine from source code?
  • Could you provide some information or steps for how you are setting up this project and using the media sample buffer?

I’ll run an aging test tonight with the official packaged 4.5.0 release. This was on a built-from-source version (where a media asset packaging issue had be fixed).

I have a single 2048x1024 .wmv playing on loop (Media Player → Media Texture → Material, applied as emissive on a single object in the scene, nothing else).

Will post an update tomorrow.

Same exact error unfortunately, about 3 hours of run-time.

Could you provide the full callstack for the crash, if it gives you one?

Thanks num3ric, I will look into this shortly.

num3ric, I have not been able to track this down. The main obstacle is the fact that I cannot see what possibly went wrong. Do you happen to have the contents of the assertion that was actually triggered? It should be in your log file.

I will run the Editor for a few hours myself tonight, and hopefully I can repro it.

Assertions in the allocator often indicate memory corruption. There may not actually be a problem with the shared pointer assignment itself. It’s possible that the current value in CurrentSample is somehow corrupted, or maybe the entire FMediaSampleBuffer instance is somehow invalid.

If you can repro this in a Debug build, that may shine some more light on the problem.

Haven’t had time to look into this further yet, but it’s still on the backlog. Sorry for the delay. If you’ve made any progress on your end, please let me know, thanks!

This is still on the backlog.

So you were never able to reproduce it? We worked on a VR installation, and I managed to bypass any aging issues by restarting our app every few runs automatically ( GitHub - BanTheRewind/StayUp: Process health, monitoring, and logging for Windows )… (No costs involved in doing that in this case.)

Maybe something else caused it? I could try it again with the latest… It’s a matter of taking the time to setup everything again.

I wasn’t able to repro it. Is there a you could send me the affected video file? Also, which build configuration did you use - development? shipping?

Hey num3ric -

We have not heard back from you in a few days, so we are marking this post as Resolved for tracking purposes. If you are still experiencing the issue you reported, please respond to this message with additional information and we will offer further assistance.

Thank you.

Eric Ketchum

Apologies if this isn’t the correct way to go about this, but we are now experiencing the exact same issue using 4.8.

We’ve attempted various workarounds. We’ve tried the H.264 and .wmv format videos, and other strange hacks like stopping, destroying, recreating and restarting the videos with no luck.

I know the feature is still considered experimental, but just wanted to make sure this issue is still ‘live’.

Hi Milly01,

Have you been able to reproduce this in a clean sample project? If so, would it be possible to get a copy of that sample project to take a look? We have so far been unable to reproduce this on our end.

Also, would you be able to provide the callstack for the crash (if you get one)?

Hi Milly01,

We have not heard back from you for a few days. Do you have any additional information that may help us narrow down a repro for this issue? I will be marking this issue as resolved for internal tracking purposes, but please feel free to add a comment with any additional information you may have to re-open the post.