- Posts: 5
- Joined: Thu Feb 09, 2017 4:47 am
I agree. It is very frustrating using valgrind when the 3rd party libraries are not valgrind clean. It has been a while since I have reviewed the following, and I am not sure how specific it is to my own linux development environment, but the following is what I used in my .supp file in an attempt to suppress some of the decklink API valgrind chatter:
- Code: Select all
{
<decklink-cond>
Memcheck:Cond
...
obj:/usr/lib/libDeckLinkAPI.so
}
{
<decklink-value8>
Memcheck:Value8
...
obj:/usr/lib/libDeckLinkAPI.so
}
{
<decklink-input>
Memcheck:Leak
match-leak-kinds: reachable
fun:_Znwm
fun:_ZN9CDeckLink14QueryInterfaceE6REFIIDPPv
fun:_ZN15SystemResources27findAllInputDeckLinkDevicesEv
}
{
<decklink-input2>
Memcheck:Leak
match-leak-kinds: reachable
fun:_Znwm
fun:_ZN14DeckControlLib11DeckControlC1EP12CDeckControlP15VTRSerialDevicebP28DeckControlHardwareInterface
fun:_ZN12CDeckControlC1EP9CDeckLinkP28DeckControlHardwareInterfaceP15pthread_mutex_t
fun:_ZN9CDeckLink14QueryInterfaceE6REFIIDPPv
fun:_ZN9CDeckLink14QueryInterfaceE6REFIIDPPv
}
{
<decklink-iterator>
Memcheck:Leak
match-leak-kinds: reachable
fun:malloc
fun:_Z18DeckLinkOpenDevicePK18DeckLinkDeviceNode
fun:_Z20DeckLinkIteratorNextP19DeckLinkIteratorRec
fun:ConnectToDriverCore
fun:_ZN17CDeckLinkIterator4NextEPP9IDeckLink
}
{
<decklink-card-iterator>
Memcheck:Leak
match-leak-kinds: reachable
fun:_Znwm
fun:_ZNSt11_Deque_baseI18DeckLinkDeviceNodeSaIS0_EE15_M_create_nodesEPPS0_S4_
fun:_ZNSt11_Deque_baseI18DeckLinkDeviceNodeSaIS0_EE17_M_initialize_mapEm
fun:CreateDeckLinkIterator
fun:_ZN17CDeckLinkIteratorC1Ev
fun:_Z35CreateDeckLinkIteratorInstance_Headv
}
Again, not sure if this is even useful for you but thought I would at least share what I have because I feel your pain also.
-Andres