Memory leak detection with boost::test - c++

I try to enable msvc memory leak detection with line number like this snippet I found here:
Detected memory leaks!
Dumping objects ->
C:\PROGRAM FILES\VISUAL STUDIO\MyProjects\leaktest\leaktest.cpp(20) : {18}
normal block at 0x00780E80, 64 bytes long.
Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
Object dump complete.
I tried to set the preprocessor define
_CRTDBG_MAP_ALLOC
manually in the project properties but I only get this:
Dumping objects ->
{1466} normal block at 0x00BD4DD0, 40 bytes long.
Data: <(o; ; (o; 1 > 28 6F 3B 00 90 A9 3B 00 28 6F 3B 00 00 D6 31 10
without line numbers. I also tried to manually define main by using BOOST_TEST_NO_MAIN and dump by myself like this:
int main( int argc, char* argv[] )
{
int res = ::boost::unit_test::unit_test_main( &init_function, argc, argv );
_CrtDumpMemoryLeaks();
return res;
}
But also without any success. How can this be done?

Using Boost.Test you can use --detect_memory_leaks="allocation number"

In MSVC you can set a breakpoint to the allocation number 1466, in the code:
_crtBreakAlloc = 1466
or in the Watch window you can add _crtBreakAlloc and value 1466 once the application started (of course you need a breakpoint in the main function). More details on MSDN

Try to use the debugger! For example, with help of deleaker can select the stack to see where memory was allocated

Related

Configure ocamlopt so gdb can get source location information

The native OCaml compiler exposes options that control whether debug information is emitted. For instance -g controls whether to record information needed to reconstruct exception backtraces. Is there an option to emit the debug information that would be needed for gdb to associate breakpoints with source information like file name and line number?
I don't think OCaml is, at present, a fully supported language for gdb and it isn't possible to pretty-print values or evaluate OCaml expressions. That is okay, I'm just wondering how to configure the ocamlopt compiler or gdb in such a way that gdb can find the source file. Ideally I'd like to be able to see both the OCaml sources and the C source files that implement OCaml runtime when they are present (i.e. when building a compiler by hand rather than through OPAM).
For instance,
(* hello.ml *)
let main () =
Printf.printf "hi there\n%!";;
let () = main ()
compiled using corebuild hello.native, produces a symlink to an executable, hello.native.
and then, when starting gdb:
(gdb) file hello.native
Reading symbols from hello.native...done.
(gdb) start
Temporary breakpoint 1 at 0x405580: file main.c, line 32.
Starting program: /home/g/ws/tmp/ocaml/hello/hello.native
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Temporary breakpoint 1, main (argc=0x1, argv=0x7fffffffdaf8) at main.c:32
32 main.c: No such file or directory.
We can see that it was unable to determine where the file is.
When you hit C-x a and switch gdb to tui mode, then the message [ No Source Available ] is visible in the top pane.
Use the dir directive in gdb to point it to the place where is the source code of the OCaml runtime, e.g.,
(gdb) dir ~/warehouse/ocaml/byterun/
Source directories searched: /home/ivg/warehouse/ocaml/byterun:$cdir:$cwd
(gdb) l
27 #endif
28
29 CAMLextern void caml_main (char_os **);
30
31 #ifdef _WIN32
32 CAMLextern void caml_expand_command_line (int *, wchar_t ***);
33
34 int wmain(int argc, wchar_t **argv)
35 #else
36 int main(int argc, char **argv)
Few more tips. You can link your program with the debugging runtime, e.g.,
ocamlopt -runtime-variant x -g hello.ml -o hello
It won't have the source code embedded though.
Also, OCaml has quite a good support for gdb, you can step, backtrace, and even observe the source code. The only problem is that names are usually mangled, so it is hard to set up a breakpoint. However, you can use objdump to reverse engineer your file. It is easy if it is built with the -g option:
$ objdump -S hello | grep hello.ml -A 10
(* hello.ml *)
let main () =
404a70: 48 8d 1d 81 a6 24 00 lea 0x24a681(%rip),%rbx # 64f0f8 <camlHello__5>
404a77: 48 8d 05 da b3 24 00 lea 0x24b3da(%rip),%rax # 64fe58 <camlPervasives>
Printf.printf "hi there\n%!";;
404a7e: 48 8b 80 d0 00 00 00 mov 0xd0(%rax),%rax
404a85: e9 66 ae 01 00 jmpq 41f8f0 <camlPrintf__fprintf_1294>
404a8a: 66 0f 1f 44 00 00 nopw 0x0(%rax,%rax,1)
0000000000404a90 <camlHello__entry>:

How do I create the database files when using MySQL as an embedded server

I'm attempting to build an application which will use a MySQL embedded database (currently on OS X, but ultimately on both OS X and Windows), and I'm using this example as a starting point. I've successfully been able to build it, using cmake with this CMakeLists file:
cmake_minimum_required(VERSION 3.3)
project(Demo)
set(TARGET_NAME Demo)
add_executable(${TARGET_NAME} test2_libmysqld.cpp)
target_include_directories(${TARGET_NAME}
PRIVATE /usr/local/include/mysql
)
find_library(LIBMYSQLD NAMES libmysqld.a)
find_library(LIBSSL NAMES libssl.a PATHS /Users/stebro/test/openssl/openssl)
find_library(LIBCRYPTO NAMES libcrypto.a PATHS /Users/stebro/test/openssl/openssl)
# target_include_directories(${TARGET_NAME} PUBLIC ${LIBMYSQLD_INCLUDE_DIRS})
target_link_libraries(${TARGET_NAME}
${LIBMYSQLD}
${LIBSSL}
${LIBCRYPTO}
)
(I built ssl locally in /Users/stebro/test/openssl, and I had to change the name of the demo file to .cpp in order for cmake to create the proper linkages to STL & other runtime stuff. I'm using mysql installed via homebrew which is "mysql Ver 14.14 Distrib 5.7.19, for osx10.10 (x86_64) using EditLine wrapper").
When I run the program, I get the error:
bash$ ./Demo --defaults-file=../my.cnf
InnoDB: Progress in percent: 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
mysql_real_connect failed: Unknown database 'test'
my.cnf looks like this:
[Demo_SERVER]
language = /usr/local/Cellar/mysql/5.7.19/share/mysql/english
[libmysqd_server]
datadir = ./data
language = ./english
skip-innodb
[libmysqld_client]
language = ./english
I'm assuming this error is happening because the test is attempting to connect to a database "test", but I've never taken any steps to create this database (or any other files needed by the embedded server).
How to I create the starting file state for the embedded server to function correctly? Do I create a database on my local MySQL instance with instructions like these, then shut down that server & copy the files over to some local space? Or are apis in the mysqld server library I use to create the initial files (and subsequent database "test")?
Okay, misconfiguration on my part. The my.cnf file I was using was a merge of two different examples I found online. The correct my.cnf file for my example looks like this:
[test2_libmysqld_SERVER]
language = /usr/local/Cellar/mysql/5.7.19/share/mysql/english
datadir = ./data
[test2_libmysqld_CLIENT]
language = /usr/local/Cellar/mysql/5.7.19/share/mysql/english
The demo program now works with the operation on connection "two" (which connects without a database specifier), but still fails on "one", but that is because no "test" db has been yet created - I think I can figure that one out.

Additional output from program built with the UB sanitizer of Clang

On travis CI where I use clang version 3.4 (tags/RELEASE_34/final) which is already installed, I build my code with this:
clang++ main.cpp -m64 -fsanitize=undefined -Werror -std=c++98 -pedantic -pedantic-errors -fvisibility=hidden -fstrict-aliasing -Weverything -Qunused-arguments -fcolor-diagnostics -O3 -DNDEBUG
(this command is obtained from compile_commands.json which is generated from cmake)
And in the output after the program quits some numbers (like hex representation of memory) appear:
00 00 00 10 70 fb 01 00 00 00 00 10 70 fb 01
My guess is this is from the UB sanitizer because when I build with ASAN or no sanitizer at all these numbers aren't there.
So what do they mean? How do I diagnose my UB error (if this is indeed such)?
I thought when a sanitizer encounters an error it crashes the program and prints a big message with explanation. So what is this?
This is a deal breaker for me because I compare reference output in a text file with the output of the program from the current build and such additional output breaks everything.
I tried locally using Clang 3.6, which is the default for my Ubuntu using the same build command, but when I run the executable I get no errors or such additional output.
here is the failing build on travis - and I don't think my code is relevant because my problem is with the sanitizer output not being helpful at all.
I also enabled the builds with clang 3.5/3.6/3.7/3.8 and turns out clang 3.5 behaves the same way...
clang 3.6 however gives more output!
20 6c 98 01 00 00 00 00 20 6c 98 01 00 00 00 00 20 6c 98 01
^
/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../include/c++/4.6/bits/stl_tree.h:247:17: runtime error: upcast of address 0x00000115e090 with insufficient space for an object of type 'std::_Rb_tree_node<doctest::detail::TestData>'
0x00000115e090: note: pointer points here
00 00 00 00 00 00 00 00 00 00 00 00 20 6c 98 01 00 00 00 00 20 6c 98 01 00 00 00 00 20 6c 98 01
clang 3.7 and 3.8 give the same output as 3.6
I am using libstdc++ so I will switch to libc++ to hopefully remove this error (which I think is not from my code!)
I was using a simple TestData structure inside a std::set<>...

Visual Leak Detector - File and line number not available

I am debugging an MFC program and have come to a point where I am trying to find and resolve memory leaks. First I tried the built-in leak detector in VC, but once I redefined the new operator I got lots of problems with redefinitions of "new" and errors.
Moved on to Visual Leak Detector. I have got it up and running and it seems to find the leaks, but it cannot seem to find the file and line numbers. This is what it looks like:
WARNING: Visual Leak Detector detected memory leaks!
---------- Block 2 at 0x0343F718: 67 bytes ----------
Call Stack:
0x00B88E2F (File and line number not available): program.exe!for__get_vm + 0x1F bytes
0x00B8FC28 (File and line number not available): program.exe!for_rtl_init_wrap_ + 0x118 bytes
f:\dd\vctools\crt_bld\self_x86\crt\src\crt0dat.c (873): MSVCR100D.dll!_initterm
f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c (473): program.exe!__tmainCRTStartup + 0xF bytes
f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c (371): program.exe!wWinMainCRTStartup
0x7540338A (File and line number not available): kernel32.dll!BaseThreadInitThunk + 0x12 bytes
0x77819F72 (File and line number not available): ntdll.dll!RtlInitializeExceptionChain + 0x63 bytes
0x77819F45 (File and line number not available): ntdll.dll!RtlInitializeExceptionChain + 0x36 bytes
Data:
43 3A 5C 50 72 6F 6A 65 63 74 5C 50 72 6F 70 63 ........ ........
61 6C 63 5C 53 65 6B 6F 6E 64 65 6E 54 72 75 6E ........ ........
6B 5C 77 42 6C 61 64 65 45 64 5C 2E 5C 44 65 62 .Random. .Symbols
75 67 5C 77 42 6C 61 64 65 45 64 2E 65 78 65 00 ........ ........
CD CD CD ........ ........
Having checked the FAQ on the Visual Leak Detector (VLD) website, there is a section stating that if this error occurs, then it may be so that VLD cannot find the debug symbols located in programname.pdb, since it must be situated alongside the programname.exe file. I have checked (and rebuilt), making sure that my project has the "Generate Debug Symbols" option turned on and that the programname.exe file gets created and put next to the programname.exe file in the debug folder.
Still, I refuses to show me the file and line numbers.
Also, at the very top of my "output window" in Visual Studio i can see the following line:
'Program.exe': Loaded 'C:\Project\Program\Debug\Program.exe', Symbols loaded.
So, the symbols are loaded?
Any ideas?
Thanks!

Teach emacs recognize Boost.Test errors

This is an output of Boost.Test when test case failes:
bjam toolset=msvc
...patience...
...found 1287 targets...
...updating 4 targets...
compile-c-c++ ..\bin\test\Function.test\msvc-8.0\debug\link-static\threading-multi\Function.obj
Function.cpp
msvc.link ..\bin\test\Function.test\msvc-8.0\debug\link-static\threading-multi\Function.exe
msvc.manifest ..\bin\test\Function.test\msvc-8.0\debug\link-static\threading-multi\Function.exe
testing.capture-output ..\bin\test\Function.test\msvc-8.0\debug\link-static\threading-multi\Function.run
====== BEGIN OUTPUT ======
Running 1 test case...
Function.cpp(26): fatal error in "FunctionConstruction": critical check pf->Name() == "F13" failed [F1 != F13]
*** 1 failure detected in test suite "foo_test"
Detected memory leaks!
Dumping objects ->
{235} normal block at 0x003A7C88, 32 bytes long.
Data: 00 00 00 00 CD CD CD CD 54 31 00 CD CD CD CD CD
{234} normal block at 0x003A7E00, 96 bytes long.
Data: 00 00 00 00 CD CD CD CD 54 31 00 CD CD CD CD CD
{233} normal block at 0x003A7D88, 76 bytes long.
Data: F4 D9 45 00 00 00 00 00 CD CD CD CD 00 7E 3A 00
Object dump complete.
EXIT STATUS: 201
====== END OUTPUT ======
MSVC parses this errors correctly so i can double click and jump to place in code. But emacs can't parse this output. How to teach it?
The solution will involve customizing the variables: 'compilation-error-regexp-alist, 'compilation-error-regexp-alist-alist, 'compilation-directory-matcher.
The first, 'compilation-error-regexp-alist is just a list of symbols telling the compilation mode what to look up in the second variable `'compilation-error-regexp-alist-alist', so you'll probably just add something for boost:
(add-to-list 'compilation-error-regexp-alist 'boost)
Then, to make that work, you need to add a list to the second variable, 'compilation-error-regexp-alist-alist. This is where it starts to get tricky. You'll need to read the documentation for the first variable to get the regexp right, but it'll be something like:
(add-to-list 'compilation-error-regexp-alist-alist
'(boost
"^\\(.*\\)(\\([0-9]+\\)): fatal error in" 1 2))
The regexp matches the error line, and the 1 and 2 specify the sub expression specifying the filename and line number respectively. There are other things you can specify (see the documentation).
Though, to be honest, the above two settings are probably unnecessary as I'm pretty sure one of the existing regexps will match the format. The problem really exists with the directory tracking.
The last variable, `'compilation-directory-matcher' is the one that lets the next-error track where to find the files. So it needs to be updated appropriately. It doesn't look like the boost test spits out the somewhat standard "Entering directory ..." that Emacs looks for, but the information seems to be there in the compile line...
You might also try asking on the boost user mailing list to see if someone there has solved this problem. The mailing list can be found here.