blis
blis copied to clipboard
Valgrind-clean mode/clean-up function
It'd be useful to have a way to clean up so users can avoid these leaks. PETSc would call it in PetscFinalize so users wouldn't have valgrind noise from BLIS.
$ valgrind --leak-check=full ./obj/haswell/blastest/dblat3.x < blastest/input/dblat3.in
==185692== Memcheck, a memory error detector
==185692== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==185692== Using Valgrind-3.16.1 and LibVEX; rerun with -h for copyright info
==185692== Command: ./obj/haswell/blastest/dblat3.x
==185692==
==185692==
==185692== HEAP SUMMARY:
==185692== in use at exit: 17,824,704 bytes in 41 blocks
==185692== total heap usage: 92 allocs, 51 frees, 17,836,911 bytes allocated
==185692==
==185692== 104 bytes in 1 blocks are possibly lost in loss record 7 of 41
==185692== at 0x483977F: malloc (vg_replace_malloc.c:307)
==185692== by 0x12E772: bli_fmalloc_align (in /home/jed/src/blis/obj/haswell/blastest/dblat3.x)
==185692== by 0x29ABD1: bli_pool_init (in /home/jed/src/blis/obj/haswell/blastest/dblat3.x)
==185692== by 0x2957B7: bli_apool_array_elem (in /home/jed/src/blis/obj/haswell/blastest/dblat3.x)
==185692== by 0x12EDD8: bli_sba_rntm_set_pool (in /home/jed/src/blis/obj/haswell/blastest/dblat3.x)
==185692== by 0x2A0B1D: bli_l3_sup_thread_decorator (in /home/jed/src/blis/obj/haswell/blastest/dblat3.x)
==185692== by 0x27A643: bli_gemmsup_ref (in /home/jed/src/blis/obj/haswell/blastest/dblat3.x)
==185692== by 0x12DC67: bli_gemmsup (in /home/jed/src/blis/obj/haswell/blastest/dblat3.x)
==185692== by 0x12D3C1: bli_gemm_ex (in /home/jed/src/blis/obj/haswell/blastest/dblat3.x)
==185692== by 0x1259B1: dgemm_ (in /home/jed/src/blis/obj/haswell/blastest/dblat3.x)
==185692== by 0x112573: dchk1_ (in /home/jed/src/blis/obj/haswell/blastest/dblat3.x)
==185692== by 0x10F0BE: main (in /home/jed/src/blis/obj/haswell/blastest/dblat3.x)
[...]
There is a bli_finalize: https://github.com/flame/blis/blob/master/docs/BLISTypedAPI.md#initialization-and-cleanup
Somewhat related, it might be a good idea to add the "malloc" GCC (and clang?) attribute to malloc-like functions.