mdk-sdk
mdk-sdk copied to clipboard
"Random" segmentation faults on memory deallocations
Hello,
Using Qt5 with MinGW 8.1.0 64bit on Windows 10 64bit, and MDK 0.15.0.
I'm experiencing in my app seemingly random SIGSEGV exceptions in MDK libraries after prepare requests. This can happen sooner or later, after just a couple prepares, or after multiple ones. Context: my app uses a scenario similar to PlaylistAsOne, and the user can seek through multiple files by single clicks or continuously dragging over a progress bar (which may lead to very fast file changes). The crash can appear after just a couple clicks, or after multiple different seeks (not necessarily quick seeks, they can be spread over multiple minutes, and can be caused by single seeks, not by drags/quick file changes).
I can't find a reliable way to reproduce it 100%.
But I attached an archive with a stress scenario that quickly prepares/sets next media (not sure if it matters, but it's what my app does)/starts playback. Sooner or later, one or more HEAP deallocation errors may or may not appear (they usually do, but sometimes it crashes without them):

Then everything ends with SIGSEGV:

This is the sample code: https://drive.google.com/file/d/1zBrYRb1jptY7aG78TwKttdYTWF0gidkV/view?usp=sharing I've noticed this happening with MP4 files, but I don't think the filetype matters. Anyway, the archive contains one sample video (the code switches between 2 files, you can just copy it).
NOTE: Sometimes it just works. If it doesn't seem to crash, just stop it, wait a few minutes and try again. It seems random, but it happens very often.
thanks for your example, it should be fixed in the latest build. tested on mac.
I tested today's version ("mdk-sdk-windows-desktop.7z", 2022-07-03 12:28:29 UTC). The HEAP errors seem to be fixed, or at least they didn't appear anymore.
However, SIGSEGV is still present, using the same sample code on Windows:

Tested a few times, all crashed after about 80-120 steps.
this crash is in the log, it's a know bug, i don't know the reason yet. You can simply disable the log, no setLogHandler
try the latest build
It still crashes with today's build, if the log handler is enabled (even if the log level is set to Off)

With the handler disabled, everything seems fine.
crash in log should be fixed in the latest release