https://gitlab.inria.fr/cado-nfs/cado-nfs
Revision 6615ac369b8eb2750088c33cd9667c971132f8c5 authored by Emmanuel Thomé on 19 March 2021, 14:24:16 UTC, committed by Emmanuel Thomé on 19 March 2021, 14:24:16 UTC
Bucket sieve projective primes; fix attempt for #30012 See merge request cado-nfs/cado-nfs!27
Tip revision: 6615ac369b8eb2750088c33cd9667c971132f8c5 authored by Emmanuel Thomé on 19 March 2021, 14:24:16 UTC
Merge branch 'bucket_sieve_projective_primes' into 'master'
Merge branch 'bucket_sieve_projective_primes' into 'master'
Tip revision: 6615ac3
cado-nfs.supp
# 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
...
}
Computing file changes ...