I am currently trying to use the detect_memory_leaks option with boost on my mac (OS: el capitan 10.11.3). So far, everytime I executed my test binary with the option --detect_memory_leaks=1, no matter how much I leak, boost doesn’t complain. If you want to reproduce my problem, here is a way to reproduce:
I’m using boost 1.59 version and compile the unit test framework as static libraries. Then, I create two sample programs:
main.cpp:
#define BOOST_TEST_MODULE test module name
#include <boost/test/unit_test.hpp>
test.cpp:
#include <boost/test/unit_test.hpp>
BOOST_AUTO_TEST_SUITE( TestSuiteSample )
BOOST_AUTO_TEST_CASE( TestCaseSample )
{
int * a = new int[3]; // This will leak memory, boost should complain
BOOST_CHECK(true);
}
BOOST_AUTO_TEST_SUITE_END()
I compile my binary the following way:
g++ -I../boost_1_59_0 -L../boost_1_59_0/stage/lib -lboost_unit_test_framework -lboost_chrono -lboost_prg_exec_monitor -lboost_system -lboost_test_exec_monitor -lboost_timer -lboost_unit_test_framework main.cpp test.cpp
As you can see, I’ve included all the boost libraries generated when compiling boost/test but using -lboost_unit_test_framework only compiles fine also.
Now I have an executable a.out that I launch this way:
./a.out --detect_memory_leaks=1 --log_level=all --report_level=detailed
and I get the following result:
Running 1 test case...
Entering test module "test module name"
test.cpp:3: Entering test suite "TestSuiteSample"
test.cpp:5: Entering test case "TestCaseSample"
test.cpp:8: info: check true has passed
test.cpp:5: Leaving test case "TestCaseSample"; testing time: 60us
test.cpp:3: Leaving test suite "TestSuiteSample"; testing time: 82us
Leaving test module "test module name"; testing time: 105us
Test module "test module name" has passed with:
1 test case out of 1 passed
1 assertion out of 1 passed
Test suite "TestSuiteSample" has passed with:
1 test case out of 1 passed
1 assertion out of 1 passed
Test case "TestSuiteSample/TestCaseSample" has passed with:
1 assertion out of 1 passed
As you can see, there is no complaint from boost about the new int[3] I didn’t delete. At first, I thought it was the compiler that optimizes the code and don’t even allocate my variable, but valgrind sees a leak as definitely lost:
==2571== by 0x10004E5BD: TestSuiteSample::TestCaseSample::test_method() (test.cpp:7)
I don’t get what I’m doing wrong but if anyone knows how to get the error generated by the leak in test.cpp, I’d be glad to know it. I tried several ways to call the option and tried to figure out what to do in the boost documentation, but so far, nothing seems to work.
Help is welcome :)
According to the documentation [1] [2] (emphasis mine):
On platforms where memory leak detection is possible inside of running application (at the moment this is only Windows family) you can switch this feature on and off using this interface.
Since you're on a Mac and building with g++, it won't do anything.
Related
I wrote some simple boost tests.
The test compiles, but starting it does not execute the test body.
Below is an example of a test.
// Windows uses Boost static libraries
#ifndef _WIN32
#define BOOST_TEST_DYN_LINK
#endif
#define BOOST_TEST_MODULE "SimpleTest"
#include <boost/test/unit_test.hpp>
#include "radarInterface/ObjConfiguration.h"
#include "radarInterface/ObjIF.h"
#include "CommonFunctions.h"
#ifndef BOOST_TEST
#define BOOST_TEST(A)
#endif
BOOST_AUTO_TEST_SUITE(_obj_interface_)
BOOST_AUTO_TEST_CASE(init_string)
{
BOOST_TEST_MESSAGE("init_string");
ObjConfiguration conf;
conf.mcastAddress("225.0.0.40");
conf.mcastPort(6310);
conf.ipAddress("127.0.0.1");
conf.tcpPort(6312);
BOOST_TEST(conf.isComplete() == true);
ObjIF objIf;
BOOST_CHECK_NO_THROW(objIf.init(conf));
usleep(3000000);
ri.fini();
}
BOOST_AUTO_TEST_SUITE_END()
Trying to run it looks like everything is fine but in truth the test body is not running.
I use CMake to compile and run tests.
The following is the result of running the tests with CMake (ctest) after their compilation.
Test project C:/Users/kongrosian/SimpleTest/build
Start 1: ObjInterface_test
1/1 Test #1: ObjInterface_test .............. Passed 0.03 sec
100% tests passed, 0 tests failed out of 1
Total Test time (real) = 0.05 sec
Even running it from the command line doesn't seem to work. Using the command
".\ObjInterface_test.exe --log_level=message --run_test=init_string"
I would expect to see at least the "init string" message. Instead I simply get
Process PID: xxxx
If I use the test code written in the comments by sehe in my project the result is the same.
When executing commands
./sotest --log_level=message --run_test=_obj_interface_/init_string
or
./sotest --list_content
I get Process PID: xxxx as command line output.
Do you have any ideas on why this behavior?
The boost version I'm using is 1.72.
I hope I have clarified better.
It's unclear how you arrive at the conclusion the test is not running. It would seem it explicitly states that it is running the test (and passing).
However, the time consumed doesn't match your expectation, which leads to the guess that you may be running the wrong target (an old build e.g. one of a build configuration that is not up-to-date).
Command Line
Given the test suite name, the command line argument should be like:
./sotest --log_level=message --run_test=_obj_interface_/init_string
Which for me prints:
Running 1 test case...
init_string
*** No errors detected
You can use some wildcards if you want:
./sotest -l all -t "*/init_string"
Running 1 test case...
Entering test module "SimpleTest"
/home/sehe/Projects/stackoverflow/test.cpp(20): Entering test suite "_obj_interface_"
/home/sehe/Projects/stackoverflow/test.cpp(22): Entering test case "init_string"
init_string
/home/sehe/Projects/stackoverflow/test.cpp(45): info: check conf.isComplete() == true has passed
/home/sehe/Projects/stackoverflow/test.cpp(53): info: check 'no exceptions thrown by objIf.init(conf)' has passed
/home/sehe/Projects/stackoverflow/test.cpp(22): Leaving test case "init_string"; testing time: 3000212us
/home/sehe/Projects/stackoverflow/test.cpp(20): Leaving test suite "_obj_interface_"; testing time: 3000270us
Leaving test module "SimpleTest"; testing time: 3000294us
*** No errors detected
Use --list_content to ... list the contents:
sehe ~ Projects stackoverflow ./sotest --list_content
_obj_interface_*
init_string*
Warning About Naming
Names starting with underscores (or containing double __ underscores) are reserved. Using them makes your program not well-formed and you may run into issues. See What are the rules about using an underscore in a C++ identifier?
So you should probably change the name of your test suite.
I'm writing a project to learn how to use Rust and I'm calling my project future-finance-labs. After writing some basic functions and verifying the app can be built I wanted to include some tests, located in aggregates/mod.rs. [The tests are in the same file as the actual code as per the documentation.] I'm unable to get the tests to run despite following the documentation to the best of my ability. I have tried to build the project using PowerShell as well as Bash. [It fails to run on Fedora Linux as well]
Here is my output on Bash:
~/future-finance-labs$ cargo test -- src/formatters/mod.rs
Finished test [unoptimized + debuginfo] target(s) in 5.98s
Running target/debug/deps/future_finance_labs-16ed066e1ea3b9a1
running 0 tests
test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
Using PowerShell I get the same output with some errors like the following:
error: failed to remove C:\Users\jhale\AppData\Local\Packages\CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc\LocalState\rootfs\home\jhale\future-finance-labs\target\debug\build\mime_guess-890328c8763afc22\build_script_build-890328c8763afc22.build_script_build.c22di3i8-cgu.0.rcgu.o: The system cannot find the path specified. (os error 3)
After my initial excitement at the prospect of writing a few tests that passed on the first attempt, I quickly realized all the green was indicative; rather, of a failure to even run the tests. I just want to run the unit tests. Running cargo test alone without a separate and file fails as well. Why can't I run any test in this project with my current setup?
It can't find your test because the rust compiler doesn't know about it. You need to add mod aggregates to main.
mod aggregates;
fn main() {
println!("Hello, world!");
}
After you do that, you'll see that your aggregates/mod.rs doesn't compile for many reasons.
And as Mihir was trying to say, you need to use the name of the test, not the name of the file to run a specific test:
cargo test min_works
cargo test aggregates
See also:
How do I “use” or import a local Rust file?
Rust Book: Controlling How Tests Are Run
While searching for an HTTP client C++ based library, I have decided to use the casablanca -- so I needed to build it.
I'm running on Ubuntu 16.04.
While following the "common" build steps described here: How-to-build-for-Linux I have encountered a build error (when running the make command as the last operation of step 4).
The entire error output can be found here (now it is the last comment in the thread cpprestsdk-build-error#266).
Just to be sure my system has the needed build tools and libraries I performed the command mentioned in step 2 and this is the output:
--> Which means my system is "good to go".
So after I struggled it a little more, I have found "an alternative" way to build it:
I have downloaded the source code from here: Source Package: casablanca (2.8.0-2) [universe], and again, followed the same instructions STARTING FROM STEP 4 from the link mentioned in the question (How-to-build-for-Linux).
This time the make phase was successful !! (it is worth to mention that not all the unit tests that are recommended to be run on step 5 passed - I did not spend time trying to understand why...).
Went on and "copied-pasted" the complete sample provided at the bottom of the following link: cpprestsdk-Getting-Started-Tutorial.
Built the program with the following command (the program contained a single cpp file called main):
g++ -std=c++11 main.cpp -o myProg -lboost_system -lcrypto -lssl -lcpprest
Ran the program
./myProg
and it passed (there was output in the console saying:"Received response status code:200").
Would be glad to hear if you have encountered the same issue, or perhaps I did something wrong in my first attempt (or in any other step along the way).
When I execute go test for a whole package the tests fail with:
$ go test github.com/dm03514/go-edu-db/...
# github.com/dm03514/go-edu-db/backends
go1: internal compiler error: in read_type, at go/gofrontend/import.cc:669
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gccgo-4.9/README.Bugs> for instructions.
FAIL github.com/dm03514/go-edu-db/backends [build failed]
? github.com/dm03514/go-edu-db/cmd [no test files]
# github.com/dm03514/go-edu-db/httpd
go1: internal compiler error: in read_type, at go/gofrontend/import.cc:669
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gccgo-4.9/README.Bugs> for instructions.
FAIL github.com/dm03514/go-edu-db/httpd [build failed]
? github.com/dm03514/go-edu-db/logging [no test files]
While the above tests fail go install builds correctly and I can run each of my individual tests correctly:
$ go test github.com/dm03514/go-edu-db/backends/backends_test.go
ok command-line-arguments 0.025s
go test github.com/dm03514/go-edu-db/httpd/handlers_test.go
ok command-line-arguments 0.021s
Has anyone ran into this before? I am brand new to Go, and to get around this I have just been executing each one of my test files individually.
The output of go build is nothing
$ go build github.com/dm03514/go-edu-db/...
$
go version is
$ go version
go version xgcc (Ubuntu 4.9-20140406-0ubuntu1) 4.9.0 20140405 (experimental) [trunk revision 209157] linux/amd64
This happened to me as well. I ended up just commenting out different tests until I was able to see useful output and to see when it would start passing. The root cause was one of my concurrently running test goroutines was calling t.Errorf (specifically, I was using the testify/assert package, but this eventually calls t.Errorf) after the test was completed. The output using go test -v eventually had this error message:
Fail in goroutine after TestTradeReader_Subscribe has completed
For me, this happened because I was using an httptest.Server (which runs concurrently during my test) and was checking input on a test case that exited quickly and didn't require this check.
The thing that helped me.. If you use plenty of tests in a loop and you create some of the mocked services OUTSIDE the loop, it may cause some problem.
TO SOLVE THIS: just move your mocked objects creation for your complex tests inside the loop and it will be done!
There is probably a routine leak. You maybe be modifying/updating a global variable in the test and not reverting for the second test.
Second reason for this error could be your test in not running in a closed env. and effecting other test after.
you can re-structure your test so that the test giving error runs at first so that it succeeds
I've just started learning C++, and to display the outputs of code I found this method. This worked when I first compiled Structure of a Programme.cpp:
#include <iostream>
using namespace std;
int main ()
{
cout << "Hello World!";
return 0;
}
It gave me a .exe, which I opened, ran, and got a lovely 'Hello World!' appearing, but when I tried compiling a second one, Variables.cpp:
#include <iostream>
using namespace std;
int main ()
{
int a, b;
int result;
a=5;
b=2;
a=a+1;
result=a-b;
cout << result;
return 0;
}
I didn't get a .exe at all, so couldn't work out how to open it. I tried re-compiling Structure of a Programme.cpp (after deleting all the associated files), but now that won't create a .exe anymore, either. The only files created are Structure of a Programme.o and Variables.o (in a sub-directory obj\Debug).
The only question I could find that seemed similar was this, but the problem seems to be slightly different, and I tried deleting one of the files (so there was only one of Structure of a Programme.cpp or Variables.cpp in the folder) and I still had the same result.
Also, there were no compiler errors with either file, and I don't think I changed any options in Code Blocks between Structure of a Programme working and everything not working.
Thanks,
Dalkius
edit: Build logs:
Compiling: Structure of a Programme.cpp
Process terminated with status 0 (0 minutes, 0 seconds)
0 errors, 0 warnings
Compiling: Variables.cpp
Process terminated with status 0 (0 minutes, 0 seconds)
0 errors, 0 warnings
edit 2: 'Full Commandline' build logs:
Build started on: 14-12-2011 at 07:57.39
Build ended on: 14-12-2011 at 08:01.03
-------------- Clean: Debug in cplusplus.com Tutorial ---------------
Done.
mingw32-g++.exe -Wall -g -c "D:\My Documents\0HOME\Programming\C++\Code Blocks\cplusplus.com Tutorial\Structure of a Programme.cpp" -o "obj\Debug\Structure of a Programme.o"
Process terminated with status 0 (0 minutes, 1 seconds)
0 errors, 0 warnings
mingw32-g++.exe -Wall -g -c "D:\My Documents\0HOME\Programming\C++\Code Blocks\cplusplus.com Tutorial\Variables.cpp" -o obj\Debug\Variables.o
Process terminated with status 0 (0 minutes, 0 seconds)
0 errors, 0 warnings
From looking at your updated build log, it appears the linking step isn't being performed to generate the final executable. There are a couple of things you can check and some ideas to try out:
Make sure the linker executable and proper path is set so C::B can locate it. For MinGW the linker is invoked through the compiler driver named 'g++.exe'.
Check that 'Console application' is selected under 'Type'.
If everything looks okay but it still doesn't link try creating a new blank console project. Add the existing files to that project and try building it.
Try building it manually from a 'cmd' command prompt to make sure the toolchain itself is functioning. You should find a 'mingwvars.bat' script under your mingw install. Run that script to open up a proper commandline environment. Do a simple test compile using this command:
cd "D:\My Documents\0HOME\Programming\C++\Code Blocks\cplusplus.com Tutorial"
g++.exe -Wall -g Variables.cpp -o Variables.exe
Lastly, this is what your log should approximately look like when it's building correctly:
EXE files are mostly build each time when you run the code. Try finding the exe file of your program where you have installed or copied the C++ program files.
I'm not too familiar with codeblocks, but I'll try to help by explaining what the compiler is doing. Those .o files it's creating are called Object Files. Compilation at a high level works as such:
1) Your source code get's compiled by a compiler.
2) The compiler will interpret your code and create an object (or .o file) for each file you have (in general anyways).
3) These files are then "linked" together in part of the compilation process known as "the linker".
4) Finally, the linker puts out your .exe file.
There's of course more to this (such as library files, pre-compiled dlls, pre-processing, etc.) but for your purposes you can think of it like above as you're just starting out.
My guess would be you may have accidentally modified something with codeblocks linker, or it is looking in the wrong place to link the files - or even the linker is throwing an error (though most IDEs inform you of this). Again, I'm unfortunately not too familiar with codeblocks.
If there is any way in codeblocks to trigger a "clean" you should also try that and try rebuilding. This will remove (clean) up any old files that may still be there from last build.
After building your program, in Build log you can see 'Executing:' where you can find the path of .exe file which your program just created.