Menu
my program processes large errors and during development in produces large amount of output on the console. It suffers from memory corruption and I try to use valgrind to locate the error.
Unfortunately, i can't find the error messages among the output lines, and they flushing by too fast to cancel execution when they pop up. They have to be there in order to locate the error ( which element does cause the error and so on ). Redirecting then within my program doesn't work, just like piping the output does only redirect the program output, not the valgrind output.
Can you give me a hint how to solve this.
602
How to make a suppression file. Run valgrind as usual, but with the extra option --gen-suppressions=all. This tells valgrind to print a suppression after every error it finds. Printing the suppressions inline like this means you have to cut/paste each to the suppression file by hand.
You can't do that. Valgrind doesn't actually execute your code natively - instead it runs it inside a simulator. That's why it's so slow. So, there's no way to make it run faster, and still get the benefit of Valgrind.
My other usual go-to for debugging memory issues, valgrind, also doesn't work very well for stack issues - it's much better at tracking heap allocations and writes than stack problems.
Sometimes, running a program (including with valgrind) can show a double-free error while in reality, it's a memory corruption problem (for example a memory overflow). The best way to check is to apply the advice detailed in the answers : How to track down a double free or corruption error in C++ with gdb.
In addition to redirecting both program and Valgrind output to a file (as already suggested), you can use --db-attach=yes flag, which will cause your program to stop in the debugger right at the error.
This has the advantage that in addition to looking at the log your program produced, you can also look at other program state (that you are not logging).
140
If you want it to stop in the console (not in a file), here is a way to do it :
Use the parameter : --gen-suppressions=yes
When you debug it will stops like this :
==949== Thread 2: ==949== Invalid read of size 4 ==949== at 0x7B62DC0: wcslen (wcslen.S:24) ==949== by 0x7B62D7D: wcsdup (wcsdup.c:29) ==949== by 0x52D0476: de_strdup(wchar_t*) (de_string.cpp:1442) ==949== by 0x437629: void de_format<>(c_de_string&, wchar_t*) (de_string.h:368) ==949== by 0x45F4FB: int db_select_group<>(s_db*, s_pqexec_param*, wchar_t*, wchar_t*, wchar_t*, wchar_t*, int, wchar_t*) (in /corto/goinfre/code2/cortod.repo/bin/x64/Debug/cortod) ==949== by 0x45EA96: check_oldgeom(c_cartod*) (cartod_funcs.cpp:114) ==949== by 0x45EBF8: armserv_update_geom(c_cartod*) (cartod_funcs.cpp:149) ==949== by 0x455EF9: c_cortosrv_thread::on_timeout() (cartod.cpp:163) ==949== by 0x52FE500: c_de_thread::loop() (de_thread.cpp:35) ==949== by 0x52FEE97: thread_loop(void*) (de_thread_priv_linux.cpp:85) ==949== by 0x506E181: start_thread (pthread_create.c:312) ==949== by 0x7BBA47C: clone (clone.S:111) ==949== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==949== ==949== ==949== ---- Print suppression ? --- [Return/N/n/Y/y/C/c] ---- Then you can go to the next one continue all etc.
The normal purpose of this parameter is to remove the false positives, by printing suppression that you can add in a file and pass it to valgrind using the parameter : --suppressions=<filename>
23
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
