I am getting the following reports running with --leak-check=full (which could be mentioned somewhere in FAQ). Is this something to worry about?
Thanks Dominik ==10052== 300 (60 direct, 240 indirect) bytes in 1 blocks are definitely lost in loss record 14 of 15 ==10052== at 0x4C28F9F: malloc (vg_replace_malloc.c:236) ==10052== by 0x67AB855: nss_parse_service_list (nsswitch.c:626) ==10052== by 0x67ABE39: __nss_database_lookup (nsswitch.c:167) ==10052== by 0x74B6823: ??? ==10052== by 0x67648AC: getpwuid_r@@GLIBC_2.2.5 (getXXbyYY_r.c:256) ==10052== by 0x67641A2: getpwuid (getXXbyYY.c:117) ==10052== by 0x99BE9D: PetscGetUserName (fuser.c:66) ==10052== by 0x5D2A20: PetscErrorPrintfInitialize (errtrace.c:68) ==10052== by 0x5F1057: PetscInitialize (pinit.c:697) ==10051== 8 bytes in 1 blocks are definitely lost in loss record 2 of 15 ==10051== at 0x4C28F9F: malloc (vg_replace_malloc.c:236) ==10051== by 0x1296EB9: GKmalloc__ (util.c:151) ==10051== by 0x1296E00: fmalloc__ (util.c:112) ==10051== by 0x1295CBC: CheckInputs__ (weird.c:188) ==10051== by 0x126F8B8: ParMETIS_V3_PartKway (kmetis.c:56) ==10051== by 0xD26874: MatPartitioningApply_Parmetis (pmetis.c:96) ==10051== by 0x6DDCFC: MatPartitioningApply (partition.c:226)
