| Summary: | generated suppressions based on the origin of uninitialized memory | ||
|---|---|---|---|
| Product: | [Developer tools] valgrind | Reporter: | Joost VandeVondele <Joost.VandeVondele> |
| Component: | general | Assignee: | Julian Seward <jseward> |
| Status: | REPORTED --- | ||
| Severity: | normal | CC: | bugzilla, csoler, ivosh, jacek.tomaka, retrosharephenom |
| Priority: | NOR | ||
| Version First Reported In: | 3.7 SVN | ||
| Target Milestone: | --- | ||
| Platform: | Unlisted Binaries | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
+1 for this. I am trying to analyze app which uses OpenSSL, and have to silence some messages about uninitialized memory. BTW, -DPURIFY for OpenSSL did not solve my problem completely - there is still one place left there. +1000: We need it.
Like:
{
libcrypto[Memcheck:Cond]
Memcheck:Cond
...
obj:/usr/lib/libcrypto.so.1.0.0
...
}
Should mark all memory allocated by or through this library as initialized.
Same report here BR#255987 https://bugs.kde.org/show_bug.cgi?id=255987 +1. This would save the life of anyone who's using libcrypto, which happens to generate so much warning about uninitialised memory that is makes valgrind unusable. Of course for libcrypto from OpenSSL the ultimate fix would be to fix it so it does not base its processing on uninitialized memory. I understand at least one part of libcrypto takes some uninitialized memory as a source to produce entropy - this would need to be annotated with VALGRIND_MAKE_MEM_DEFINED or VALGRIND_MAKE_MEM_DEFINED_IF_ADDRESSABLE, though. Anyway, patches are welcome! +1 Just ran into it while using boost library: boost/boost/uuid/seed_rng.hpp:167 166 // *p is intentionally left uninitialized 167 unsigned int * p = new unsigned int; |
Version: 3.7 SVN OS: Linux For some 'bugs' in libraries, it would be great if it would be possible to write a suppression based on the location where the uninitialized memory came from (unless there is a better trick to do so already). The example below is an issue where in the MPI library an uninitialized value was created, which causes conditional jumps in tons of places in the code. With a single suppression (which would of course require --track-origins=yes) I could handle this issue easily. Thanks for considering this feature, Joost ==546== Conditional jump or move depends on uninitialised value(s) ==546== at 0x4C270E9: memcpy (mc_replace_strmem.c:120) ==546== by 0x72A03B0: MPIDI_CH3U_Request_unpack_uebuf (in /opt/cray/mpt/5.2.2/xt/gemini/mpich2-gnu/lib/libmpich.so.1.3) ==546== by 0x72FEAC8: MPID_Irecv (in /opt/cray/mpt/5.2.2/xt/gemini/mpich2-gnu/lib/libmpich.so.1.3) ==546== by 0x72EE7CB: MPIC_Irecv (in /opt/cray/mpt/5.2.2/xt/gemini/mpich2-gnu/lib/libmpich.so.1.3) ==546== by 0x72B663D: MPIR_CRAY_Alltoallv (in /opt/cray/mpt/5.2.2/xt/gemini/mpich2-gnu/lib/libmpich.so.1.3) ==546== by 0x727E5E5: PMPI_Alltoallv (in /opt/cray/mpt/5.2.2/xt/gemini/mpich2-gnu/lib/libmpich.so.1.3) ==546== by 0x1CAE7A1: mpi_alltoallv_ (wrappers.c:537) ==546== by 0x64CC50: __message_passing_MOD_mp_alltoall_l11v (message_l_passing.f90:161) ==546== by 0xA553CF: __task_list_methods_MOD_create_local_tasks (task_list_methods.F:1636) ==546== by 0xA6318B: __task_list_methods_MOD_distribute_tasks (task_list_methods.F:1914) ==546== by 0xA68EC3: __task_list_methods_MOD_generate_qs_task_list (task_list_methods.F:302) ==546== by 0x779B75: __qs_environment_methods_MOD_qs_env_update_s_mstruct (qs_environment_methods.F:361) ==546== Uninitialised value was created by a heap allocation ==546== at 0x4C25661: malloc (vg_replace_malloc.c:261) ==546== by 0x727A186: MPIR_Allreduce (in /opt/cray/mpt/5.2.2/xt/gemini/mpich2-gnu/lib/libmpich.so.1.3) ==546== by 0x727B886: PMPI_Allreduce (in /opt/cray/mpt/5.2.2/xt/gemini/mpich2-gnu/lib/libmpich.so.1.3) ==546== by 0x1CAE424: mpi_allreduce_ (wrappers.c:362) ==546== by 0x6478C0: __message_passing_MOD_mp_sum_im (message_i_passing.f90:887) ==546== by 0x729902: __pw_grids_MOD_pw_grid_count (pw_grids.F:1246) ==546== by 0x730AD0: __pw_grids_MOD_pw_grid_setup_internal (pw_grids.F:454) ==546== by 0x731505: __pw_grids_MOD_pw_grid_setup (pw_grids.F:385) ==546== by 0x13462B5: __pw_env_methods_MOD_pw_env_rebuild (pw_env_methods.F:410) ==546== by 0x13477AA: __pw_env_methods_MOD_pw_env_create (pw_env_methods.F:124) ==546== by 0x7766F5: __qs_environment_methods_MOD_qs_env_rebuild_pw_env (qs_environment_methods.F:443) ==546== by 0x77B863: __qs_environment_methods_MOD_qs_env_setup (qs_environment_methods.F:171) ==546== { <insert_a_suppression_name_here> Memcheck:Cond fun:memcpy fun:MPIDI_CH3U_Request_unpack_uebuf fun:MPID_Irecv fun:MPIC_Irecv fun:MPIR_CRAY_Alltoallv fun:PMPI_Alltoallv fun:mpi_alltoallv_ fun:__message_passing_MOD_mp_alltoall_l11v fun:__task_list_methods_MOD_create_local_tasks fun:__task_list_methods_MOD_distribute_tasks fun:__task_list_methods_MOD_generate_qs_task_list fun:__qs_environment_methods_MOD_qs_env_update_s_mstruct } Reproducible: Always Steps to Reproduce: use --track-origins Actual Results: the origin can not be used in a suppression Expected Results: the origin could be used in a suppression