Valgrind shows question marks - c++

I have compiled a program using Code::Blocks. I have turned on "produce debugging symbols" under the "Debug" target, and also turned off "strip all symbols..." But when I run the program with Valgrind I get question marks in the output:
$ valgrind --leak-check=yes --track-origins=yes --log-file=valgrind_output.txt
~/bin/myprg
==3766== Memcheck, a memory error detector
==3766== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==3766== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==3766== Command: /home/xxxxxx/bin/myprg
==3766== Parent PID: 3209
==3766==
==3766== Warning: client switching stacks? SP change: 0xffefff978 --> 0xffed13da0
==3766== to suppress, use: --max-stackframe=3062744 or greater
==3766== Invalid write of size 4
==3766== at 0x40892B: ??? (in /home/xxxxxx/bin/myprg)
==3766== by 0x40275C: ??? (in /home/xxxxxx/bin/myprg)
==3766== by 0x56FB82F: (below main) (libc-start.c:291)
==3766== Address 0xffed13ddc is on thread 1's stack
==3766==
==3766== Invalid write of size 4
==3766== at 0x408931: ??? (in /home/xxxxxx/bin/myprg)
==3766== by 0x40275C: ??? (in /home/xxxxxx/bin/myprg)
==3766== by 0x56FB82F: (below main) (libc-start.c:291)
==3766== Address 0xffed13dd4 is on thread 1's stack
==3766==
...
What is the meaning of this output, and how do I find the piece of code that is causing this error?
Update: Solution
The problem was with Code::Blocks. It is necessary to correctly configure the project build options for the whole project and not just the "Debug" target. So all flags except "-std=c++11" were removed from the "whole project" options, so nothing was overriding the "Debug" options. Also the linker ".o" files need to be deleted when the options are changed, to force Code::Blocks to rebuild the executable.

The code needs to be compiled and linked with debug info (-g command line option) and -fno-omit-frame-pointer for valgrind to show correct stack traces.
See The stack traces given by Memcheck (or another tool) aren't helpful. How can I improve them? for more details.

I recently had this problem and was able to resolve it by using the "--keep-debuginfo=yes" option, as suggested by the FAQ on this page.

Related

Valgrind reporting memory leak in RocksDB

I am trying to profile the performance of RocksDB using Callgrind / KCacheGrind on a mac. I am running the command valgrind --tool=callgrind ./simple_example on one of the example programs that comes with RocksDB in the examples folder. I seem to be getting a memory leak, though, which prevents me from being able to do the performance profiling that I ultimately want to do.
==54628== Callgrind, a call-graph generating cache profiler
==54628== Copyright (C) 2002-2017, and GNU GPL'd, by Josef Weidendorfer et al.
==54628== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==54628== Command: ./simple_example
==54628==
==54628== For interactive control, run 'callgrind_control -h'.
==54628==
==54628== Process terminating with default action of signal 11 (SIGSEGV)
==54628== Access not within mapped region at address 0x18
==54628== at 0x1016D25BA: _pthread_body (in /usr/lib/system/libsystem_pthread.dylib)
==54628== by 0x1016D250C: _pthread_start (in /usr/lib/system/libsystem_pthread.dylib)
==54628== by 0x1016D1BF8: thread_start (in /usr/lib/system/libsystem_pthread.dylib)
==54628== If you believe this happened as a result of a stack
==54628== overflow in your program's main thread (unlikely but
==54628== possible), you can try to increase the size of the
==54628== main thread stack using the --main-stacksize= flag.
==54628== The main thread stack size used in this run was 8388608.
--54628:0:schedule VG_(sema_down): read returned -4
==54628==
==54628== Events : Ir
==54628== Collected : 14961779
==54628==
==54628== I refs: 14,961,779
Segmentation fault: 11

Valgrind `Unsupported arch_prctl option`

I have a program that I know has some weird memory issues going on, so I turned to Valgrind. However, I am getting the following mysterious output:
==32006== Memcheck, a memory error detector
==32006== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==32006== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==32006== Command: ./012
==32006== Parent PID: 29454
==32006==
valgrind: the 'impossible' happened:
Unsupported arch_prctl option
host stacktrace:
==32006== at 0x580441BA: show_sched_status_wrk (m_libcassert.c:355)
==32006== by 0x580442D4: report_and_quit (m_libcassert.c:426)
==32006== by 0x58044517: panic (m_libcassert.c:502)
==32006== by 0x58044517: vgPlain_core_panic_at (m_libcassert.c:507)
==32006== by 0x5804454A: vgPlain_core_panic (m_libcassert.c:512)
==32006== by 0x580DAE22: vgSysWrap_amd64_linux_sys_arch_prctl_before (syswrap-amd64-linux.c:286)
==32006== by 0x580A0C23: vgPlain_client_syscall (syswrap-main.c:1857)
==32006== by 0x5809D48A: handle_syscall (scheduler.c:1126)
==32006== by 0x5809EBB6: vgPlain_scheduler (scheduler.c:1443)
==32006== by 0x580AED50: thread_wrapper (syswrap-linux.c:103)
==32006== by 0x580AED50: run_a_thread_NORETURN (syswrap-linux.c:156)
sched status:
running_tid=1
Thread 1: status = VgTs_Runnable (lwpid 32006)
==32006== at 0x401A1C5: ??? (in /usr/lib/ld-2.28.so)
==32006== by 0xBFEBFBFE: ???
Note: see also the FAQ in the source distribution.
It contains workarounds to several common problems.
In particular, if Valgrind aborted or crashed after
identifying problems in your program, there's a good chance
that fixing those problems will prevent Valgrind aborting or
crashing, especially if it happened in m_mallocfree.c.
If that doesn't help, please report this bug to: www.valgrind.org
In the bug report, send all the above text, the valgrind
version, and what OS and version you are using. Thanks.
The original bug I am trying to diagnose occurs when I am trying to insert uint64_ts into a std::set based on values in a std::vector (not a pointer in sight).
Try installing valgrind-git package from AUR and it may work

Performance testing in C++ project

I wrote a project in c++ with 10 threads. One thread loads the data into memory(write the buffer) and other 9 threads are simultaneously read the buffer and store data in SQLite database, All threads are handled with the mutex to avoid conflicts.
Now I need to evaluate the performance of this project such as time to success per threads, memory usages etc. How can I go it in c++ environment? I used Valgrind to check these. But I think it not working.
This is the code I run with Valgrind,
valgrind --tool=memcheck --leak-check=yes ./executable
It gives a message like this,
callers=20 --track-fds=yes ./monerosci
==24262== Memcheck, a memory error detector
==24262== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==24262== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==24262== Command: ./monerosci
==24262==
valgrind: m_syswrap/syswrap-linux.c:5361
(vgSysWrap_linux_sys_fcntl_before): Assertion 'Unimplemented
functionality' failed.
valgrind: valgrind
host stacktrace:
==24262== at 0x38083F48: ??? (in /usr/lib/valgrind/memcheck-amd64-linux)
==24262== by 0x38084064: ??? (in /usr/lib/valgrind/memcheck-amd64-linux)
==24262== by 0x380841F1: ??? (in /usr/lib/valgrind/memcheck-amd64-linux)
==24262== by 0x380FB399: ??? (in /usr/lib/valgrind/memcheck-amd64-linux)
==24262== by 0x380D6234: ??? (in /usr/lib/valgrind/memcheck-amd64-linux)
==24262== by 0x380D2D2A: ??? (in /usr/lib/valgrind/memcheck-amd64-linux)
==24262== by 0x380D43DE: ??? (in /usr/lib/valgrind/memcheck-amd64-linux)
==24262== by 0x380E3946: ??? (in /usr/lib/valgrind/memcheck-amd64-linux)
How can I test the performance of the project in C++?
Well it seems there's two separate problems here:
1) memcheck is failing to run due to a bug or some limitation. Apparently one variation of a fcntl call is not supported by your version of valgrind. Maybe you should reduce the code size, remove libraries, until you can pinpoint which call is triggering this problem. Or just run it under a different version of valgrind. However, I think memcheck will not give you the data you want...
2) memcheck is not a tool for profiling. Valgrind is composed of several different tools that can be switched by using the --tool parameter. Here's an overview of them. The one that most likely will give you the info you want is callgrind.

Valgrind report write error? why?

When running Valgrind's memcheck, occasionally valgrind report error like this:
==2745== Memcheck, a memory error detector
==2745== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==2745== Using Valgrind-3.6.0 and LibVEX; rerun with -h for copyright info
==2745== Command: ./HSFramework
==2745==
==2745== Invalid write of size 8
==2745== at 0x3B81C097C0: do_lookup_x (in /lib64/ld-2.12.so)
==2745== by 0x1C31032D: ???
==2745== by 0x3B81C09E19: _dl_lookup_symbol_x (in /lib64/ld-2.12.so)
==2745== Address 0x7feffee78 is on thread 1's stack
==2745==
platform: Linux 2.6.32-220.el6.x86_64 x86_64 x86_64 x86_64 GNU/Linux
There is not clue about my code from this error report.
I had no idea about this error report.
What reasons will lead to this error?
This error means you are getting a buffer overrun in do_lookup_x, if you got its source look at that or share with us.
http://valgrind.org/docs/manual/quick-start.html
This means that the do_lookup_x function has performed an invalid write access. That function is part of the runtime library (and not likely the origin of the issue). I would contact the author of HSFramework to see if they can fix this issue by running valgrind as you did

Is it possible that valgrind reports fatal errors of my program which runs correctly?

When I run my program or when I run it with gdb it seems to run correctly, there are no errors and I get an output as expected.
But when I run it with valgrind via valgrind ./program, it does not even get far. I get an VALGRIND INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - exiting
at the very beginning. The valgrind output does not help me at all. I invoke a childprocess, but valgrind does not follow it. I tried to use the --trace-children=yes option, but no change.
Another question: What is the difference between the calls valgrind program and valgrind ./program?
The output I get is:
$ valgrind --tool=memcheck --trace-children=yes ./program
==2616== Memcheck, a memory error detector
==2616== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==2616== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
==2616== Command: ./program
==2616==
Parent pid is 2616
Child pid is 2619
main() could not create fifo
--2619-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - exiting
--2619-- si_code=2; Faulting address: 0x400DFD; sp: 0x403277b70
valgrind: the 'impossible' happened:
Killed by fatal signal
==2619== at 0x3802D33A: mash_colon_env (m_libcproc.c:195)
==2619== by 0x3802D6FD: vgPlain_env_remove_valgrind_env_stuff (m_libcproc.c:254)
==2619== by 0x3806EB7C: vgSysWrap_generic_sys_execve_before (syswrap-generic.c:2622)
==2619== by 0x38068750: vgPlain_client_syscall (syswrap-main.c:1443)
==2619== by 0x380651E9: handle_syscall (scheduler.c:895)
==2619== by 0x38066D6A: vgPlain_scheduler (scheduler.c:1091)
==2619== by 0x380763FC: run_a_thread_NORETURN (syswrap-linux.c:94)
sched status:
running_tid=1
Thread 1: status = VgTs_Runnable
==2619== at 0x567D957: execve (execve.c:60)
==2619== by 0x567E1E8: execvpe (execvpe.c:151)
==2619== by 0x400B2D: main (program2.cpp:34)
Thanks in advance.
That error indicates that you have most likely encountered a bug in valgrind. In fact it has already been reported (https://bugs.kde.org/show_bug.cgi?id=271582) so you should add yourself to that bug to be kept up to date with work on fixing it.
In general such "VALGRIND INTERNAL ERROR" messages should be reported at https://bugs.kde.org/enter_valgrind_bug.cgi, making sure you you include the full output from running valgrind -v on your program.
You should be using Valgrind "follow-fork-mode" child.
That is why Valgrind might not be following your child process.