I'm trying to run valgrind in order to identify memory leaks in my program.
Unfortunately, running it fails as follows:
igor#WaylandGnome ~/dbhandler/Debug/dbhandler $ valgrind --leak-check=full dbhandler
==32622== Memcheck, a memory error detector
==32622== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==32622== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info
==32622== Command: dbhandler
==32622==
vex amd64->IR: unhandled instruction bytes: 0x8F 0xEA 0x78 0x10 0xD0 0x8 0x4 0x0 0x0 0x89
vex amd64->IR: REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0
vex amd64->IR: VEX=0 VEX.L=0 VEX.nVVVV=0x0 ESC=NONE
vex amd64->IR: PFX.66=0 PFX.F2=0 PFX.F3=0
==32622== valgrind: Unrecognised instruction at address 0x40197cf.
==32622== at 0x40197CF: get_common_indices.constprop.0 (in /lib64/ld-2.33.so)
==32622== by 0x401ACB6: init_cpu_features.constprop.0 (in /lib64/ld-2.33.so)
==32622== by 0x401BE1D: _dl_sysdep_start (in /lib64/ld-2.33.so)
==32622== by 0x4001FDB: _dl_start (in /lib64/ld-2.33.so)
==32622== by 0x4001057: ??? (in /lib64/ld-2.33.so)
==32622== Your program just tried to execute an instruction that Valgrind
==32622== did not recognise. There are two possible reasons for this.
==32622== 1. Your program has a bug and erroneously jumped to a non-code
==32622== location. If you are running Memcheck and you just saw a
==32622== warning about a bad jump, it's probably your program's fault.
==32622== 2. The instruction is legitimate but Valgrind doesn't handle it,
==32622== i.e. it's Valgrind's fault. If you think this is the case or
==32622== you are not sure, please let us know and we'll try to fix it.
==32622== Either way, Valgrind will now raise a SIGILL signal which will
==32622== probably kill your program.
==32622==
==32622== Process terminating with default action of signal 4 (SIGILL)
==32622== Illegal opcode at address 0x40197CF
==32622== at 0x40197CF: get_common_indices.constprop.0 (in /lib64/ld-2.33.so)
==32622== by 0x401ACB6: init_cpu_features.constprop.0 (in /lib64/ld-2.33.so)
==32622== by 0x401BE1D: _dl_sysdep_start (in /lib64/ld-2.33.so)
==32622== by 0x4001FDB: _dl_start (in /lib64/ld-2.33.so)
==32622== by 0x4001057: ??? (in /lib64/ld-2.33.so)
==32622==
==32622== HEAP SUMMARY:
==32622== in use at exit: 0 bytes in 0 blocks
==32622== total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==32622==
==32622== All heap blocks were freed -- no leaks are possible
==32622==
==32622== For lists of detected and suppressed errors, rerun with: -s
==32622== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Illegal instruction
Any idea what is happening?
I'm running Gentoo here and my program is built with C++11 standard.
This is valgrind bug https://bugs.kde.org/show_bug.cgi?id=381819
There is a patch attached to the bug but the patch is not in the latest valgrind release as it is reported as not being complete.
Related
I try to track a memory leak in a code using boost::python.
I reduced my code to a simple main. This simple main run with valgrind without error/leak :
valgrind --leak-check=full --track-origins=yes /HIDDEN_PATH/MemLeak
==23316== Memcheck, a memory error detector
==23316== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==23316== Using Valgrind-3.19.0 and LibVEX; rerun with -h for copyright info
==23316== Command: /HIDDEN_PATH/MemLeak
==23316==
==23316==
==23316== HEAP SUMMARY:
==23316== in use at exit: 0 bytes in 0 blocks
==23316== total heap usage: 192 allocs, 192 frees, 148,668 bytes allocated
==23316==
==23316== All heap blocks were freed -- no leaks are possible
==23316==
==23316== For lists of detected and suppressed errors, rerun with: -s
==23316== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
When I add the first call to something using boost::python, valgrind fails to execute the code (the error is before the main):
> valgrind --leak-check=full --track-origins=yes /HIDDEN_PATH/BUILD_DEBUG/test/experimentation/MemLeak
==23595== Memcheck, a memory error detector
==23595== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==23595== Using Valgrind-3.19.0 and LibVEX; rerun with -h for copyright info
==23595== Command: /HIDDEN_PATH/BUILD_DEBUG/test/experimentation/MemLeak
==23595==
vex amd64->IR: unhandled instruction bytes: 0x62 0xF1 0xFD 0x8 0x6F 0x4 0x24 0x48 0x89 0x68
vex amd64->IR: REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0
vex amd64->IR: VEX=0 VEX.L=0 VEX.nVVVV=0x0 ESC=NONE
vex amd64->IR: PFX.66=0 PFX.F2=0 PFX.F3=0
==23595== valgrind: Unrecognised instruction at address 0x61ac14.
==23595== at 0x61AC14: boost::python::converter::registry::insert(void* (*)(_object*), void (*)(_object*, boost::python::converter::rvalue_from_python_stage1_data*), boost::python::type_info, _typeobject const* (*)()) (in /HIDDEN_PATH/BUILD_DEBUG/test/experimentation/MemLeak)
==23595== by 0x628753: boost::python::converter::initialize_builtin_converters() (in /HIDDEN_PATH/BUILD_DEBUG/test/experimentation/MemLeak)
==23595== by 0x61A55B: boost::python::converter::(anonymous namespace)::get(boost::python::type_info, bool) (in /HIDDEN_PATH/BUILD_DEBUG/test/experimentation/MemLeak)
==23595== by 0x528FCD: registry_lookup2<const volatile std::__cxx11::basic_string<char> > (registered.hpp:100)
==23595== by 0x528FCD: registry_lookup1<const volatile std::__cxx11::basic_string<char>&> (registered.hpp:107)
==23595== by 0x528FCD: __static_initialization_and_destruction_0 (registered.hpp:118)
==23595== by 0x528FCD: _GLOBAL__sub_I__ZN6minamo22PyMod_VirtualEvaluatorC2Ev (PyMod_VirtualEvaluator.cpp:188)
==23595== by 0x8A61AC: __libc_csu_init (in /HIDDEN_PATH/BUILD_DEBUG/test/experimentation/MemLeak)
==23595== by 0x68E1C2D: (below main) (libc-start.c:270)
==23595== Your program just tried to execute an instruction that Valgrind
==23595== did not recognise. There are two possible reasons for this.
==23595== 1. Your program has a bug and erroneously jumped to a non-code
==23595== location. If you are running Memcheck and you just saw a
==23595== warning about a bad jump, it's probably your program's fault.
==23595== 2. The instruction is legitimate but Valgrind doesn't handle it,
==23595== i.e. it's Valgrind's fault. If you think this is the case or
==23595== you are not sure, please let us know and we'll try to fix it.
==23595== Either way, Valgrind will now raise a SIGILL signal which will
==23595== probably kill your program.
==23595==
==23595== Process terminating with default action of signal 4 (SIGILL)
==23595== Illegal opcode at address 0x61AC14
==23595== at 0x61AC14: boost::python::converter::registry::insert(void* (*)(_object*), void (*)(_object*, boost::python::converter::rvalue_from_python_stage1_data*), boost::python::type_info, _typeobject const* (*)()) (in /HIDDEN_PATH/BUILD_DEBUG/test/experimentation/MemLeak)
==23595== by 0x628753: boost::python::converter::initialize_builtin_converters() (in /HIDDEN_PATH/BUILD_DEBUG/test/experimentation/MemLeak)
==23595== by 0x61A55B: boost::python::converter::(anonymous namespace)::get(boost::python::type_info, bool) (in /HIDDEN_PATH/BUILD_DEBUG/test/experimentation/MemLeak)
==23595== by 0x528FCD: registry_lookup2<const volatile std::__cxx11::basic_string<char> > (registered.hpp:100)
==23595== by 0x528FCD: registry_lookup1<const volatile std::__cxx11::basic_string<char>&> (registered.hpp:107)
==23595== by 0x528FCD: __static_initialization_and_destruction_0 (registered.hpp:118)
==23595== by 0x528FCD: _GLOBAL__sub_I__ZN6minamo22PyMod_VirtualEvaluatorC2Ev (PyMod_VirtualEvaluator.cpp:188)
==23595== by 0x8A61AC: __libc_csu_init (in /HIDDEN_PATH/BUILD_DEBUG/test/experimentation/MemLeak)
==23595== by 0x68E1C2D: (below main) (libc-start.c:270)
==23595==
==23595== HEAP SUMMARY:
==23595== in use at exit: 86,344 bytes in 24 blocks
==23595== total heap usage: 24 allocs, 0 frees, 86,344 bytes allocated
==23595==
==23595== 32 bytes in 1 blocks are definitely lost in loss record 8 of 24
==23595== at 0x4C378C3: operator new(unsigned long) (vg_replace_malloc.c:422)
==23595== by 0x61AC13: boost::python::converter::registry::insert(void* (*)(_object*), void (*)(_object*, boost::python::converter::rvalue_from_python_stage1_data*), boost::python::type_info, _typeobject const* (*)()) (in /HIDDEN_PATH/BUILD_DEBUG/test/experimentation/MemLeak)
==23595== by 0x628753: boost::python::converter::initialize_builtin_converters() (in /HIDDEN_PATH/BUILD_DEBUG/test/experimentation/MemLeak)
==23595== by 0x61A55B: boost::python::converter::(anonymous namespace)::get(boost::python::type_info, bool) (in /HIDDEN_PATH/BUILD_DEBUG/test/experimentation/MemLeak)
==23595== by 0x528FCD: registry_lookup2<const volatile std::__cxx11::basic_string<char> > (registered.hpp:100)
==23595== by 0x528FCD: registry_lookup1<const volatile std::__cxx11::basic_string<char>&> (registered.hpp:107)
==23595== by 0x528FCD: __static_initialization_and_destruction_0 (registered.hpp:118)
==23595== by 0x528FCD: _GLOBAL__sub_I__ZN6minamo22PyMod_VirtualEvaluatorC2Ev (PyMod_VirtualEvaluator.cpp:188)
==23595== by 0x8A61AC: __libc_csu_init (in /HIDDEN_PATH/BUILD_DEBUG/test/experimentation/MemLeak)
==23595== by 0x68E1C2D: (below main) (libc-start.c:270)
==23595==
==23595== LEAK SUMMARY:
==23595== definitely lost: 32 bytes in 1 blocks
==23595== indirectly lost: 0 bytes in 0 blocks
==23595== possibly lost: 0 bytes in 0 blocks
==23595== still reachable: 86,312 bytes in 23 blocks
==23595== suppressed: 0 bytes in 0 blocks
==23595== Reachable blocks (those to which a pointer was found) are not shown.
==23595== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==23595==
==23595== For lists of detected and suppressed errors, rerun with: -s
==23595== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Illegal instruction (core dumped)
I don't understand what is wrong.
Configuration: CentOS Stream 8, GCC 8.5.0, valgrind 3.19.0, python 3.9.10 static fPIC, boost 1.71.0 static fPIC
Note: I tried with option --suppressions=valgrind-python.supp but no difference.
I've created a c++ app in an arm embedded board .The board uses armbian linux debian flavour. This app in several places execute https request with the help of poco NetSSl library.
When I run the valgrind with the following arguments:
valgrind --leak-check=full --leak-resolution=high --show-reachable=yes --num-callers=20 --track-origins=yes --show-below-main=yes --log-file=valrgind.log ./c++_app
I get the following error message :
==2414== Memcheck, a memory error detector
==2414== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==2414== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info
==2414== Command: ./c++_app
==2414== Parent PID: 1556
==2414==
disInstr(thumb): unhandled instruction: 0xEC51 0x0F1E
==2414== valgrind: Unrecognised instruction at address 0x52a17e7.
==2414== at 0x52A17E6: ??? (in /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.1)
==2414== Your program just tried to execute an instruction that Valgrind
==2414== did not recognise. There are two possible reasons for this.
==2414== 1. Your program has a bug and erroneously jumped to a non-code
==2414== location. If you are running Memcheck and you just saw a
==2414== warning about a bad jump, it's probably your program's fault.
==2414== 2. The instruction is legitimate but Valgrind doesn't handle it,
==2414== i.e. it's Valgrind's fault. If you think this is the case or
==2414== you are not sure, please let us know and we'll try to fix it.
==2414== Either way, Valgrind will now raise a SIGILL signal which will
==2414== probably kill your program.
==2414== Thread 5:
==2414== Syscall param write(buf) points to uninitialised byte(s)
==2414== at 0x5153D12: write (syscall-template.S:84)
==2414== by 0x52B8A29: ??? (in /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.1)
==2414== Address 0x59d78f6 is 382 bytes inside a block of size 16,472 alloc'd
==2414== at 0x483E8DC: malloc (vg_replace_malloc.c:299)
==2414== by 0x5217FCB: ??? (in /usr/lib/arm-linux-gnueabihf/libssl.so.1.1)
==2414== Uninitialised value was created by a heap allocation
==2414== at 0x483E8DC: malloc (vg_replace_malloc.c:299)
==2414== by 0x52CE4FB: BUF_MEM_grow_clean (in /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.1)
==2414==
==2414==
==2414== HEAP SUMMARY:
==2414== in use at exit: 400 bytes in 2 blocks
==2414== total heap usage: 57,828 allocs, 57,826 frees, 4,335,151 bytes allocated
==2414==
==2414== Thread 1:
==2414== 400 bytes in 2 blocks are definitely lost in loss record 1 of 1
==2414== at 0x483E8DC: malloc (vg_replace_malloc.c:299)
==2414== by 0x5332337: CRYPTO_zalloc (in /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.1)
==2414==
==2414== LEAK SUMMARY:
==2414== definitely lost: 400 bytes in 2 blocks
==2414== indirectly lost: 0 bytes in 0 blocks
==2414== possibly lost: 0 bytes in 0 blocks
==2414== still reachable: 0 bytes in 0 blocks
==2414== suppressed: 0 bytes in 0 blocks
==2414==
==2414== For counts of detected and suppressed errors, rerun with: -v
==2414== ERROR SUMMARY: 3 errors from 2 contexts (suppressed: 0 from 0)
Since I've dealt with similar problems when using gdb I gave export OPENSSL_armcap=0 and then I got the following:
==2435== Memcheck, a memory error detector
==2435== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==2435== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info
==2435== Command: ./c++_app
==2435== Parent PID: 1556
==2435==
==2435==
==2435== HEAP SUMMARY:
==2435== in use at exit: 400 bytes in 2 blocks
==2435== total heap usage: 158,181 allocs, 158,179 frees, 11,872,290 bytes allocated
==2435==
==2435== 400 bytes in 2 blocks are definitely lost in loss record 1 of 1
==2435== at 0x483E8DC: malloc (vg_replace_malloc.c:299)
==2435== by 0x5332337: CRYPTO_zalloc (in /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.1)
==2435==
==2435== LEAK SUMMARY:
==2435== definitely lost: 400 bytes in 2 blocks
==2435== indirectly lost: 0 bytes in 0 blocks
==2435== possibly lost: 0 bytes in 0 blocks
==2435== still reachable: 0 bytes in 0 blocks
==2435== suppressed: 0 bytes in 0 blocks
==2435==
==2435== For counts of detected and suppressed errors, rerun with: -v
==2435== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
However no additional info was retrieved even though I've compiled the code with -ggdb3.
The info that I get from openssl version -a is:
OpenSSL 1.1.0j 20 Nov 2018
built on: reproducible build, date unspecified
platform: debian-armhf
options: bn(64,32) rc4(char) des(long) blowfish(ptr)
compiler: gcc -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM -DOPENSSLDIR="\"/usr/lib/ssl\"" -DENGINESDIR="\"/usr/lib/arm-linux-gnueabihf/engines-1.1\""
OPENSSLDIR: "/usr/lib/ssl"
ENGINESDIR: "/usr/lib/arm-linux-gnueabihf/engines-1.1"
I've found several issues regarding memory leaks of the openssl but not one with so limited info.
Does anyone know if this memory leak is caused by libcrypto or false alarm of valgrind and is there any way to get additional info?
I have already seen this a few times. So far it was always a fault in my code. Because you shared no code, I can only give the latest issue in my case which caused this.
I was allocating a MAC code with the new OpenSSL 3 API with:
EVP_MAC *_mac = EVP_MAC_fetch(NULL, "cmac", NULL);
I forgot to deallocate this with:
EVP_MAC_free(_mac);
I try to send via curl request from c++ on my macOS (for example on linux works everything fine). But when I run the program via valgrind and then try to send request over curl then the program fails with a segmentation fault. Even on code from here https://curl.haxx.se/libcurl/c/https.html and I also try the curl command from terminal with valgrind and even then it failed but it must be https. I tried the curl with openssl and darwinssl but without success.
My os is macOS high sierra.
The output from valgrind:
valgrind ./demo
==78893== Memcheck, a memory error detector
==78893== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==78893== Using Valgrind-3.14.0.GIT and LibVEX; rerun with -h for copyright info
==78893== Command: ./demo
==78893==
--78893-- run: /usr/bin/dsymutil "./demo" warning: no debug symbols in executable (-arch x86_64)
--78893-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option
--78893-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option (repeated 2 times)
--78893-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option (repeated 4 times)
--78893-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option (repeated 8 times)
==78893== Thread 2:
==78893== Invalid read of size 4
==78893== at 0x100AB45BA: _pthread_body (in /usr/lib/system/libsystem_pthread.dylib)
==78893== by 0x100AB450C: _pthread_start (in /usr/lib/system/libsystem_pthread.dylib)
==78893== by 0x100AB3BF8: thread_start (in /usr/lib/system/libsystem_pthread.dylib)
==78893== Address 0x18 is not stack'd, malloc'd or (recently) free'd
==78893==
==78893==
==78893== Process terminating with default action of signal 11 (SIGSEGV)
==78893== Access not within mapped region at address 0x18
==78893== at 0x100AB45BA: _pthread_body (in /usr/lib/system/libsystem_pthread.dylib)
==78893== by 0x100AB450C: _pthread_start (in /usr/lib/system/libsystem_pthread.dylib)
==78893== by 0x100AB3BF8: thread_start (in /usr/lib/system/libsystem_pthread.dylib)
==78893== If you believe this happened as a result of a stack
==78893== overflow in your program's main thread (unlikely but
==78893== possible), you can try to increase the size of the
==78893== main thread stack using the --main-stacksize= flag.
==78893== The main thread stack size used in this run was 8388608.
==78893==
==78893== HEAP SUMMARY:
==78893== in use at exit: 840,095 bytes in 3,760 blocks
==78893== total heap usage: 4,784 allocs, 1,024 frees, 1,520,703 bytes allocated
==78893==
==78893== LEAK SUMMARY:
==78893== definitely lost: 5,792 bytes in 78 blocks
==78893== indirectly lost: 416 bytes in 12 blocks
==78893== possibly lost: 4,648 bytes in 111 blocks
==78893== still reachable: 208,644 bytes in 3,290 blocks
==78893== suppressed: 620,595 bytes in 269 blocks
==78893== Rerun with --leak-check=full to see details of leaked memory
==78893==
==78893== For counts of detected and suppressed errors, rerun with: -v
==78893== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 25 from 4) Segmentation fault: 11
Also you can try write to command line: "valgrind curl https://example.com"
It causing same exception.
I'm learning C language from Learn C The Hard Way. I'm on exercise 6 and while I can make it work, valgrind repots a lot of errors.
Here's the stripped down minimal program from a file ex6.c:
#include <stdio.h>
int main(int argc, char *argv[])
{
char initial = 'A';
float power = 2.345f;
printf("Character is %c.\n", initial);
printf("You have %f levels of power.\n", power);
return 0;
}
Content of Makefile is just CFLAGS=-Wall -g.
I compile the program with $ make ex6 (there are no compiler warnings or errors). Executing with $ ./ex6 produces the expected output.
When I run the program with $ valgrind ./ex6 I get errors which I can't solve. Here's the full output:
==69691== Memcheck, a memory error detector
==69691== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==69691== Using Valgrind-3.11.0.SVN and LibVEX; rerun with -h for copyright info
==69691== Command: ./ex6
==69691==
--69691-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option
--69691-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option (repeated 2 times)
--69691-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option (repeated 4 times)
==69691== Conditional jump or move depends on uninitialised value(s)
==69691== at 0x1003FBC3F: _platform_memchr$VARIANT$Haswell (in /usr/lib/system/libsystem_platform.dylib)
==69691== by 0x1001EFBB6: __sfvwrite (in /usr/lib/system/libsystem_c.dylib)
==69691== by 0x1001FA005: __vfprintf (in /usr/lib/system/libsystem_c.dylib)
==69691== by 0x10021F9CE: __v2printf (in /usr/lib/system/libsystem_c.dylib)
==69691== by 0x10021FCA0: __xvprintf (in /usr/lib/system/libsystem_c.dylib)
==69691== by 0x1001F5B91: vfprintf_l (in /usr/lib/system/libsystem_c.dylib)
==69691== by 0x1001F39F7: printf (in /usr/lib/system/libsystem_c.dylib)
==69691== by 0x100000F1B: main (ex6.c:8)
==69691==
Character is A.
==69691== Invalid read of size 32
==69691== at 0x1003FBC1D: _platform_memchr$VARIANT$Haswell (in /usr/lib/system/libsystem_platform.dylib)
==69691== by 0x1001EFBB6: __sfvwrite (in /usr/lib/system/libsystem_c.dylib)
==69691== by 0x1001FA005: __vfprintf (in /usr/lib/system/libsystem_c.dylib)
==69691== by 0x10021F9CE: __v2printf (in /usr/lib/system/libsystem_c.dylib)
==69691== by 0x10021FCA0: __xvprintf (in /usr/lib/system/libsystem_c.dylib)
==69691== by 0x1001F5B91: vfprintf_l (in /usr/lib/system/libsystem_c.dylib)
==69691== by 0x1001F39F7: printf (in /usr/lib/system/libsystem_c.dylib)
==69691== by 0x100000F31: main (ex6.c:9)
==69691== Address 0x100809680 is 32 bytes before a block of size 32 in arena "client"
==69691==
You have 2.345000 levels of power.
==69691==
==69691== HEAP SUMMARY:
==69691== in use at exit: 39,365 bytes in 429 blocks
==69691== total heap usage: 510 allocs, 81 frees, 45,509 bytes allocated
==69691==
==69691== LEAK SUMMARY:
==69691== definitely lost: 16 bytes in 1 blocks
==69691== indirectly lost: 0 bytes in 0 blocks
==69691== possibly lost: 13,090 bytes in 117 blocks
==69691== still reachable: 26,259 bytes in 311 blocks
==69691== suppressed: 0 bytes in 0 blocks
==69691== Rerun with --leak-check=full to see details of leaked memory
==69691==
==69691== For counts of detected and suppressed errors, rerun with: -v
==69691== Use --track-origins=yes to see where uninitialised values come from
==69691== ERROR SUMMARY: 5 errors from 2 contexts (suppressed: 0 from 0)
I'm on OS X yosemite. Valgrind is installed via brew with this command $ brew install valgrind --HEAD.
So, does anyone know what's the issue here? How do I fix the valgrind errors?
If the programme you are running through Valgrind is exactly the one you posted in your question, it clearly doesn't have any memory leaks. In fact, you don't even use malloc/free yourself!
It looks to me like these are spurious errors / false positives that Valgrind detects on OS X (only!), similar to what happened to myself some time ago.
If you have access to a different operating system, e.g. a Linux machine, try to analyze the programme using Valgrind on that system.
EDIT: I haven't tried this myself, since I don't have access to a Mac right now, but you should try what
M Oehm suggested: try to use a supressions file as mentioned in this other SO question.
This issue is fixed for Darwin 14.3.0 (Mac OS X 10.10.2) using Valgrind r14960 with VEX r3124 for Xcode6.2 and Valgrind r15088 for Xcode 6.3.
If you are using Macports (at this time of writing), sudo port install valgrind-devel will give you Valgrind r14960 with VEX r3093.
Here's my build script to install Valgrind r14960 with VEX r3124:
#! /usr/bin/env bash
mkdir -p buildvalgrind
cd buildvalgrind
svn co svn://svn.valgrind.org/valgrind/trunk/#14960 valgrind
cd valgrind
./autogen.sh
./configure --prefix=/usr/local
make && sudo make install
# check that we have our valgrind installed
/usr/local/bin/valgrind --version
(reference: http://calvinx.com/2015/04/10/valgrind-on-mac-os-x-10-10-yosemite/)
My macports-installed valgrind is located at /opt/local/bin/valgrind.
If I now run
/opt/local/bin/valgrind --leak-check=yes --suppressions=`pwd`/objc.supp ./ex6
I will get exactly the same errors you described above. (Using my objc.supp file here https://gist.github.com/calvinchengx/0b1d45f67be9fdca205b)
But if I run
/usr/local/bin/valgrind --leak-check=yes --suppressions=`pwd`/objc.supp ./ex6
Everything works as expected and I do not get the system level memory leak errors showing up.
Judging from this topic, I assume that valgrind is not guaranteed to give correct results on your platform. If you can, try this code on another platform.
The culprit is either in valgrid itself or in your system's implementation of printf, both of which would be impractical for you to fix.
Rerun with --leak-check=full to see details of leaked memory. This should give you some more information about the leak you are experiencing. If nothing helps, you can create a suppression file to stop the errors from being displayed.
I'm learning C language from Learn C The Hard Way. I'm on exercise 6 and while I can make it work, valgrind repots a lot of errors.
Here's the stripped down minimal program from a file ex6.c:
#include <stdio.h>
int main(int argc, char *argv[])
{
char initial = 'A';
float power = 2.345f;
printf("Character is %c.\n", initial);
printf("You have %f levels of power.\n", power);
return 0;
}
Content of Makefile is just CFLAGS=-Wall -g.
I compile the program with $ make ex6 (there are no compiler warnings or errors). Executing with $ ./ex6 produces the expected output.
When I run the program with $ valgrind ./ex6 I get errors which I can't solve. Here's the full output:
==69691== Memcheck, a memory error detector
==69691== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==69691== Using Valgrind-3.11.0.SVN and LibVEX; rerun with -h for copyright info
==69691== Command: ./ex6
==69691==
--69691-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option
--69691-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option (repeated 2 times)
--69691-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option (repeated 4 times)
==69691== Conditional jump or move depends on uninitialised value(s)
==69691== at 0x1003FBC3F: _platform_memchr$VARIANT$Haswell (in /usr/lib/system/libsystem_platform.dylib)
==69691== by 0x1001EFBB6: __sfvwrite (in /usr/lib/system/libsystem_c.dylib)
==69691== by 0x1001FA005: __vfprintf (in /usr/lib/system/libsystem_c.dylib)
==69691== by 0x10021F9CE: __v2printf (in /usr/lib/system/libsystem_c.dylib)
==69691== by 0x10021FCA0: __xvprintf (in /usr/lib/system/libsystem_c.dylib)
==69691== by 0x1001F5B91: vfprintf_l (in /usr/lib/system/libsystem_c.dylib)
==69691== by 0x1001F39F7: printf (in /usr/lib/system/libsystem_c.dylib)
==69691== by 0x100000F1B: main (ex6.c:8)
==69691==
Character is A.
==69691== Invalid read of size 32
==69691== at 0x1003FBC1D: _platform_memchr$VARIANT$Haswell (in /usr/lib/system/libsystem_platform.dylib)
==69691== by 0x1001EFBB6: __sfvwrite (in /usr/lib/system/libsystem_c.dylib)
==69691== by 0x1001FA005: __vfprintf (in /usr/lib/system/libsystem_c.dylib)
==69691== by 0x10021F9CE: __v2printf (in /usr/lib/system/libsystem_c.dylib)
==69691== by 0x10021FCA0: __xvprintf (in /usr/lib/system/libsystem_c.dylib)
==69691== by 0x1001F5B91: vfprintf_l (in /usr/lib/system/libsystem_c.dylib)
==69691== by 0x1001F39F7: printf (in /usr/lib/system/libsystem_c.dylib)
==69691== by 0x100000F31: main (ex6.c:9)
==69691== Address 0x100809680 is 32 bytes before a block of size 32 in arena "client"
==69691==
You have 2.345000 levels of power.
==69691==
==69691== HEAP SUMMARY:
==69691== in use at exit: 39,365 bytes in 429 blocks
==69691== total heap usage: 510 allocs, 81 frees, 45,509 bytes allocated
==69691==
==69691== LEAK SUMMARY:
==69691== definitely lost: 16 bytes in 1 blocks
==69691== indirectly lost: 0 bytes in 0 blocks
==69691== possibly lost: 13,090 bytes in 117 blocks
==69691== still reachable: 26,259 bytes in 311 blocks
==69691== suppressed: 0 bytes in 0 blocks
==69691== Rerun with --leak-check=full to see details of leaked memory
==69691==
==69691== For counts of detected and suppressed errors, rerun with: -v
==69691== Use --track-origins=yes to see where uninitialised values come from
==69691== ERROR SUMMARY: 5 errors from 2 contexts (suppressed: 0 from 0)
I'm on OS X yosemite. Valgrind is installed via brew with this command $ brew install valgrind --HEAD.
So, does anyone know what's the issue here? How do I fix the valgrind errors?
If the programme you are running through Valgrind is exactly the one you posted in your question, it clearly doesn't have any memory leaks. In fact, you don't even use malloc/free yourself!
It looks to me like these are spurious errors / false positives that Valgrind detects on OS X (only!), similar to what happened to myself some time ago.
If you have access to a different operating system, e.g. a Linux machine, try to analyze the programme using Valgrind on that system.
EDIT: I haven't tried this myself, since I don't have access to a Mac right now, but you should try what
M Oehm suggested: try to use a supressions file as mentioned in this other SO question.
This issue is fixed for Darwin 14.3.0 (Mac OS X 10.10.2) using Valgrind r14960 with VEX r3124 for Xcode6.2 and Valgrind r15088 for Xcode 6.3.
If you are using Macports (at this time of writing), sudo port install valgrind-devel will give you Valgrind r14960 with VEX r3093.
Here's my build script to install Valgrind r14960 with VEX r3124:
#! /usr/bin/env bash
mkdir -p buildvalgrind
cd buildvalgrind
svn co svn://svn.valgrind.org/valgrind/trunk/#14960 valgrind
cd valgrind
./autogen.sh
./configure --prefix=/usr/local
make && sudo make install
# check that we have our valgrind installed
/usr/local/bin/valgrind --version
(reference: http://calvinx.com/2015/04/10/valgrind-on-mac-os-x-10-10-yosemite/)
My macports-installed valgrind is located at /opt/local/bin/valgrind.
If I now run
/opt/local/bin/valgrind --leak-check=yes --suppressions=`pwd`/objc.supp ./ex6
I will get exactly the same errors you described above. (Using my objc.supp file here https://gist.github.com/calvinchengx/0b1d45f67be9fdca205b)
But if I run
/usr/local/bin/valgrind --leak-check=yes --suppressions=`pwd`/objc.supp ./ex6
Everything works as expected and I do not get the system level memory leak errors showing up.
Judging from this topic, I assume that valgrind is not guaranteed to give correct results on your platform. If you can, try this code on another platform.
The culprit is either in valgrid itself or in your system's implementation of printf, both of which would be impractical for you to fix.
Rerun with --leak-check=full to see details of leaked memory. This should give you some more information about the leak you are experiencing. If nothing helps, you can create a suppression file to stop the errors from being displayed.