# This is a suppression file for valgrind

# In order to generate it, re-run valgrind as follows:
# valgrind --leak-check=full --gen-suppressions=all ./my_program arg1 # arg2 ... 
# The "..." joker matches several possible lines in the call trace.

{
   hwloc_is_known_to_leak_a_bit_mangled_names
   Memcheck:Leak
   match-leak-kinds: definite
   fun:malloc
   ...
   fun:hwloc_topology_init
   fun:_ZN9cpubinderC1ERSo
   fun:cpubinding_get_info
   fun:pi_init_mpilevel
}

{
   hwloc_is_known_to_leak_a_bit_unmangled_names
   Memcheck:Leak
   match-leak-kinds: definite
   fun:malloc
   ...
   fun:hwloc_topology_init
   fun:cpubinder
   fun:cpubinding_get_info
   fun:pi_init_mpilevel
   fun:pi_go_inner_not_interleaved
}
{
   hwloc_again
   Memcheck:Leak
   match-leak-kinds: definite
   fun:malloc
   ...
   fun:lt_dlopenadvise
   ...
   fun:_ZN17las_parallel_desc6helperC1Ev
   ...
}
{
   hwloc_still_same_leak_with_topology_init
   Memcheck:Leak
   match-leak-kinds: definite
   fun:malloc
   ...
   fun:lt_dlopenadvise
   ...
   fun:cpubinder
   fun:cpubinding_get_info
   fun:pi_init_mpilevel
   fun:pi_go_inner_not_interleaved
   ...
}
{
   openmp_leak
   Memcheck:Leak
   match-leak-kinds: possible
   fun:calloc
   fun:allocate_dtv
   fun:_dl_allocate_tls
   fun:allocate_stack
   fun:pthread_create*
   ...
   fun:GOMP_parallel
   ...
}
{
   another_openmp_leak
   Memcheck:Leak
   match-leak-kinds: reachable
   fun:malloc
   obj:/usr/lib/x86_64-linux-gnu/libgomp.so.1.0.0
   obj:/usr/lib/x86_64-linux-gnu/libgomp.so.1.0.0
   obj:/usr/lib/x86_64-linux-gnu/libgomp.so.1.0.0
   fun:call_init.part.0
   fun:call_init
   fun:_dl_init
   obj:/lib/x86_64-linux-gnu/ld-2.24.so
   ...
}

# The one below is without openmp. So maybe openmp is innocent. I haven't
# really investigated whether there's a code path which fails to properly
# join() all threads. However, if there were, then one would not expect
# openmp to leak similarly. So I'm skeptical. It's probably the glibc's
# fault.
{
   another_one_quite_similar_to_the_previous_leak
   Memcheck:Leak
   match-leak-kinds: possible
   fun:calloc
   fun:allocate_dtv
   fun:_dl_allocate_tls
   fun:allocate_stack
   fun:pthread_create*
   ...
   fun:filter_rels
   ...
   fun:main
}
{
   another_one_quite_similar_to_the_previous_leak
   Memcheck:Leak
   match-leak-kinds: possible
   fun:calloc
   fun:allocate_dtv
   fun:_dl_allocate_tls
   fun:allocate_stack
   fun:pthread_create*
   ...
   fun:_ZN11thread_pool*
   ...
}
{
   another_one_quite_similar_to_the_previous_leak
   Memcheck:Leak
   match-leak-kinds: possible
   fun:calloc
   fun:allocate_dtv
   fun:_dl_allocate_tls
   fun:allocate_stack
   fun:pthread_create*
   ...
   fun:_ZN11thread_poolC1EmRdm
   ...
}
{
   ok_there_is_an_annoying_error_with_glibc_2_22_which_seems_hard_to_reproduce_but_let_us_write_a_suppression_for_it
   Memcheck:Cond
   fun:index
   fun:expand_dynamic_string_token
   fun:fillin_rpath
   ...
   obj:/lib/x86_64-linux-gnu/ld-2.22.so
   ...
}
{
   another_one_of_the_stop_bothering_me_kind
   Memcheck:Cond
   fun:index
   fun:expand_dynamic_string_token
   ...
   fun:do_preload
   fun:dl_main
   ...
   obj:/lib/x86_64-linux-gnu/ld-2.22.so
   ...
}

# See there
# https://sourceforge.net/p/valgrind/mailman/message/32434015/
{  
   helgrind_does_not_cope_with_gcc_thread_safe_statics
   Helgrind:Race
   fun:_ZNK5tdict4slotcvNS_3keyEEv
   ...
   fun:_ZN11thread_pool20thread_work_on_tasksEPv
   fun:mythread_wrapper
   fun:start_thread
   fun:clone
}
{
   same_as_above
   Helgrind:Race
   fun:_ZNK5tdict4slotcvNS_3keyEEv
   fun:_Z23do_one_special_q_sublatR8nfs_workSt10shared_ptrI14nfs_work_cofacES1_I7nfs_auxER11thread_pool
   fun:_Z16do_one_special_qR8las_infoR8nfs_workSt10shared_ptrI7nfs_auxER11thread_pool
   fun:_Z10las_subjobR8las_infoiR13las_todo_listR10las_reportRN5tdict4treeINS5_20timer_seconds_threadEEE
   ...
   obj:/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.25
   fun:mythread_wrapper
   fun:start_thread
}


{  
   drd_does_no_better
   drd:ConflictingAccess
   fun:_ZNK5tdict4slotcvNS_3keyEEv
   ...
   fun:_ZN11thread_pool20thread_work_on_tasksEPv
   fun:vgDrd_thread_wrapper
   fun:start_thread
   fun:clone
}

{  
   helgrind_does_not_cope_with_gcc_thread_safe_statics
   Helgrind:Race
   fun:_ZNK5tdict3key6encodeEi
   fun:_ZNK5tdict15slot_parametricclEi
   ...
   fun:_ZN11thread_pool20thread_work_on_tasksEPv
   fun:mythread_wrapper
   fun:start_thread
   fun:clone
}

{  
   drd_also_this_one
   drd:ConflictingAccess
   fun:_ZNK5tdict3key6encodeEi
   fun:_ZNK5tdict15slot_parametricclEi
   ...
   fun:_ZN11thread_pool20thread_work_on_tasksEPv
   fun:vgDrd_thread_wrapper
   fun:start_thread
   fun:clone
}

# I'm quite convinced that helgrind is wrong here. The errors it reports
# are in blatant contradiction with the promise that the dtor of the
# shared_ptr is called exactly once. However my (little) web search did
# not reveal any bug report for this.
{
   helgrind_does_not_know_that_shared_ptr_dtor_is_thread_safe
   Helgrind:Race
   ...
   fun:_ZN7nfs_auxD1Ev
   ...
   fun:_ZNSt10shared_ptrI7nfs_auxED1Ev
   fun:_ZN25detached_cofac_parametersD1Ev
   ...
}
{
   this_is_the_same_problem_but_the_stack_trace_is_so_deep_that_helgrind_sees_both_as_different
   Helgrind:Race
   ...
   fun:_ZN10las_report20accumulate_and_clearEOS_
   fun:_ZN7nfs_auxD1Ev
   ...
}