- Posts: 6
- Joined: Fri Sep 05, 2014 11:51 pm
I have a Decklink Duo and I just updated our Castus unit to driver 10.3.7. Our code uses the C++ interfaces under Linux. We're using (what I understand) is the latest version of the SDK 10.3.1. Linux kernel 3.14.15 on x86_64.
I'm noticing that no matter what I release, the SDK seems to leave file handles and memory maps behind. What it opens and maps on capture or playback it never frees when I release all the objects.
This is a serious issue to us because it means that about 300MB of application resources is leaked every time our code opens or reopens the device. Leaving the device open at all times is not an option, the code in question is for a video capture source that is opened only when the schedule or user requests video, else, it closes it. If we allow the leak to excess, it can consume all 4GB of RAM in the system and then trigger the Linux OOM killer.
Our code is using the v9.9 interface because many of our systems out in the field have not yet been upgraded and our clients need to stay on the air. The leak seems to happen as early as when our code uses QueryInterface to obtain the IDeckLinkConfiguration of the input.
Interfaces used:
Closing:
Until recently that freed all resources as normal, until 10.3.5 and 10.3.7, where the memory map and file handles are left behind (plainly visible in /proc/<pid>/fd and /proc/<pid>/maps).
Can you please address this resource leak?
I'm noticing that no matter what I release, the SDK seems to leave file handles and memory maps behind. What it opens and maps on capture or playback it never frees when I release all the objects.
This is a serious issue to us because it means that about 300MB of application resources is leaked every time our code opens or reopens the device. Leaving the device open at all times is not an option, the code in question is for a video capture source that is opened only when the schedule or user requests video, else, it closes it. If we allow the leak to excess, it can consume all 4GB of RAM in the system and then trigger the Linux OOM killer.
Our code is using the v9.9 interface because many of our systems out in the field have not yet been upgraded and our clients need to stay on the air. The leak seems to happen as early as when our code uses QueryInterface to obtain the IDeckLinkConfiguration of the input.
Interfaces used:
- Code: Select all
# if BLACKMAGIC_DECKLINK_API_VERSION >= 0x0a010400
# include <isp-utils-v4/media-item/DeckLinkAPI_v9_9.h>
# define IDeckLinkOutput IDeckLinkOutput_v9_9
# define IID_IDeckLinkOutput IID_IDeckLinkOutput_v9_9
# endif
#endif
IDeckLinkDisplayMode* decklink_displaymode_changed = NULL;
IDeckLinkDisplayMode* decklink_displaymode = NULL;
IDeckLinkConfiguration* decklink_cfg = NULL;
IDeckLinkInput* decklink_in = NULL;
IDeckLinkIterator* decklink_i = NULL;
IDeckLink* decklink = NULL;
Closing:
- Code: Select all
if (decklink_displaymode_changed != NULL) {
decklink_displaymode_changed->Release();
decklink_displaymode_changed=NULL;
}
if (decklink_displaymode != NULL) {
decklink_displaymode->Release();
decklink_displaymode=NULL;
}
if (decklink_cfg != NULL) {
decklink_cfg->Release();
decklink_cfg=NULL;
}
if (decklink_in != NULL) {
decklink_in->StopStreams();
decklink_in->DisableVideoInput();
decklink_in->DisableAudioInput();
decklink_in->Release();
decklink_in=NULL;
}
if (decklink != NULL) {
decklink->Release();
decklink=NULL;
}
if (decklink_i != NULL) {
decklink_i->Release();
decklink_i=NULL;
}
Until recently that freed all resources as normal, until 10.3.5 and 10.3.7, where the memory map and file handles are left behind (plainly visible in /proc/<pid>/fd and /proc/<pid>/maps).
Can you please address this resource leak?