Simulation program [closed] - c++

This question is unlikely to help any future visitors; it is only relevant to a small geographic area, a specific moment in time, or an extraordinarily narrow situation that is not generally applicable to the worldwide audience of the internet. For help making this question more broadly applicable, visit the help center.
Closed 10 years ago.
I'm making a simulation for severals queues.
I'm supposed to input number of queues in the beginning and then simulate all thoose.
Output for each queue each "round" is meantime, total number of served and size of each queue.
My program is crashing and dosen't respond.
It writes out the first queue och then crashes...
Help!
I think my calculations is wrong to but i don't know since it's all crashing.
Here it is:
#include <iostream>
#include <cstdlib>
#include <list>
#include <ctime>
#include<conio.h>
#include <time.h>
#include <stdlib.h>
#include<dos.h>
#include<windows.h>
using namespace std;
class Customer
{
public:
int servicet;
int served;
Customer()
{
servicet= rand()%150+30;
}
int getServicetime()
{
return servicet;
}
int getServed()
{
return served;
}
int decreaseServeTime()
{
servicet --;
}
};
int totServed=0;
int queues=0;
int inLine=0;
int totTime=0;
int smallestQueue=0;
int temp=0;
int ran=0;
double mean=0;
int served=0;
int serviceTime=0;
int help=0;
int sim=0;
int n=0;
using namespace std;
int main()
{
cout<<"Number of Cashiers?: "<<endl;
cin >> queues;
cout <<"How long simulation?: "<<endl;
cin >> sim;
list<Customer> *cashiers[queues];
list<Customer> *cust;
for(int i=0; i<=queues; i++)
{
cust = new list<Customer>;
cashiers[i] = cust;
}
srand(time(0));
while(n<sim)
{
Sleep(2000);
ran= rand()%4;
smallestQueue = cashiers[0] ->size();
for(int j=0; j<ran; j++)
{
for(int k=0; k<queues; k++)
{
temp = cashiers[k]->size();
if(temp<=smallestQueue)
{
smallestQueue = temp;
help=k;
}
}
Customer C;
cashiers[help]->push_back(C);
inLine++;
}
for(int i=0; i<queues; i++)
{
if(serviceTime>0)
{
serviceTime = cashiers[i]->front().getServicetime();
cashiers[i]->front().decreaseServeTime();
}
else if(serviceTime==0)
{
cashiers[i]->pop_front();
served++;
}
}
totTime++;
int cash=1;
for(int i=0; i<queues; i++)
{
if(inLine!=0)
{
cout <<"Kassa: "<<cash<<endl;
inLine = cashiers[i]->size();
mean = (totTime/inLine);
totServed +=served;
cash++;
}
cout <<inLine<<" "<<mean<<" "<<totServed<<endl;
}
n++;
}
system("pause");
}

I recommend that you use a program such as Application Verifier to find the issue that is causing the crash:
http://www.microsoft.com/en-us/download/details.aspx?id=20028
It's important that you learn how to debug your software and understand what is going on. Please run your code in a debugger (Visual Studio, Eclipse) and take a look at where it stops. If you used Application Verifier, then it will likely stop where the issue originates. Take a look at the variables and see whether they make sense. Look at whether you're accessing memory locations you shouldn't.
To use Application Verifier with Visual Studio, install it then find the appVerifier.exe in the System32 folder in C:\Windows. Then open the file and point it to your executable. Enable what you think are the proper checks. Then run it in visual Studio.

A good place to start is with a debugger (e.g. gdb). First we compile with debugging enabled (g++ -ggdb) and try running in the debugger,
$ g++ hi.cpp -ggdb
$ gdb ./a.out
GNU gdb (GDB) 7.5-ubuntu
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/ben/a.out...done.
(gdb) run
Starting program: /home/ben/a.out
Number of Cashiers?:
5
How long simulation?:
5
Kassa: 1
Program received signal SIGSEGV, Segmentation fault.
0x0000000000401827 in std::_List_const_iterator<Customer>::operator++ (
this=0x7fffffffdd10) at /usr/include/c++/4.7/bits/stl_list.h:236
236 _M_node = _M_node->_M_next;
(gdb) backtrace
#0 0x0000000000401827 in std::_List_const_iterator<Customer>::operator++ (
this=0x7fffffffdd10) at /usr/include/c++/4.7/bits/stl_list.h:236
#1 0x0000000000401665 in std::__distance<std::_List_const_iterator<Customer> >
(__first=..., __last=...)
at /usr/include/c++/4.7/bits/stl_iterator_base_funcs.h:82
#2 0x0000000000401492 in std::distance<std::_List_const_iterator<Customer> > (
__first=..., __last=...)
at /usr/include/c++/4.7/bits/stl_iterator_base_funcs.h:118
#3 0x000000000040135b in std::list<Customer, std::allocator<Customer> >::size
(this=0x604010) at /usr/include/c++/4.7/bits/stl_list.h:855
#4 0x0000000000401122 in main () at hi.cpp:125
Here we see that the program crashed with a segmentation fault in a
function of the std::list. After programming for a while, you will
gain an intuition that this is probably due to your program trampling
on some memory it shouldn't be. Having identified roughly the nature
of the problem, we will now switch to valgrind, a tool for tracking
down specifically this sort of issue.
$ valgrind ./a.out
==13751== Memcheck, a memory error detector
==13751== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==13751== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==13751== Command: ./a.out
==13751==
Number of Cashiers?:
5
How long simulation?:
5
Kassa: 1
==13751== Invalid read of size 8
==13751== at 0x401422: std::list<Customer, std::allocator<Customer> >::begin() const (stl_list.h:749)
==13751== by 0x40134F: std::list<Customer, std::allocator<Customer> >::size() const (stl_list.h:855)
==13751== by 0x401121: main (hi.cpp:125)
==13751== Address 0x5a06040 is 0 bytes inside a block of size 16 free'd
==13751== at 0x4C2A44B: operator delete(void*) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==13751== by 0x4018E7: __gnu_cxx::new_allocator<std::_List_node<Customer> >::deallocate(std::_List_node<Customer>*, unsigned long) (new_allocator.h:100)
==13751== by 0x4017D9: std::_List_base<Customer, std::allocator<Customer> >::_M_put_node(std::_List_node<Customer>*) (stl_list.h:339)
==13751== by 0x4015C0: std::list<Customer, std::allocator<Customer> >::_M_erase(std::_List_iterator<Customer>) (stl_list.h:1549)
==13751== by 0x4013E9: std::list<Customer, std::allocator<Customer> >::pop_front() (stl_list.h:983)
==13751== by 0x40108B: main (hi.cpp:113)
==13751==
==13751==
==13751== Process terminating with default action of signal 8 (SIGFPE)
==13751== Integer divide by zero at address 0x402CCCE98
==13751== at 0x40113C: main (hi.cpp:126)
Here we see valgrind telling us that your program attempted a read
operation on unallocated memory. In particular, this seems to be
happening as a result of a pop_front operation. Looking at the
source, you indeed attempt to pop from cashiers[i] without first
checking it's size.
We can add an appropriate check,
...
else if(serviceTime==0)
{
if (!cashiers[i]->empty()) {
cashiers[i]->pop_front();
served++;
}
}
...
The actual cause of the crash, however, is a division by zero in computing the
mean, as noted at the end of valgrind's output. This is due to the fact that the case where no Customers are inLine is not handled when computing mean.

Related

a bizarre "Project.exe has triggered a breakpoint."?

just don't tell me google that, because I did it for the last 48 hours.
this is my problem; I create a lon program, which execute many itterations; but in few itterations, this error comes ...
Critical error detected c0000374
Project.exe has triggered a breakpoint.
The program '[4452] Project.exe' has exited with code 0 (0x0).
so, Visual Studio 2012 opens newaop.cpp; which contains few line
// newaop -- operator new[](size_t) REPLACEABLE
#include <new>
void *__CRTDECL operator new[](size_t count) _THROW1(std::bad_alloc)
{ // try to allocate count bytes for an array
return (operator new(count));
}
/*
* Copyright (c) 1992-2007 by P.J. Plauger. ALL RIGHTS RESERVED.
* Consult your license regarding permissions and restrictions.
V5.03:0009 */
pointing to the return line...
I searched so many; but nothing works; the problem in that, my program works for few itterations
I tried to locate the instructions generating this erreor (with cout's) and I found this loop
for (int i = OriginalCadre.X.x + 1; i < OriginalCadre.X.x + OriginalCadre.height; i++){
for (int j = OriginalCadre.X.y + 1; j < OriginalCadre.X.y + OriginalCadre.width; j++){
QuantityColor[Pattern_init[i][j]] ++;
}
}
this loop works at the begening for few itterations; which is bizarre !
Critical error detected c0000374 is a sign of heap corruption, which means you might be doing bad things with memory e.g. writing after the end of a buffer, or writing to a buffer after it's been freed back to the heap.
I don't see any tell tale signs in that small loop, but likely you are writing past the memory location of QuantityColor or something similar.
Debugging heap corruption errors

../mingwrt-4.0.3-1-mingw32-src/src/libcrt/crt/crt1.c: No such file or directory

I am new to program world. I am learning C with Dev-cpp 5.6.1
I had a problem with my Debugger (GNU gdb (GDB) 7.6.1). When I debug any program, the debugger warned me
Single stepping until exit from function main,
which has no line number information.
and
__mingw_CRTStartup ()
at ../mingwrt-4.0.3-1-mingw32-src/src/libcrt/crt/crt1.c:260
260 ../mingwrt-4.0.3-1-mingw32-src/src/libcrt/crt/crt1.c: No such file or directory.
The problem happened before. I solved it by reinstalling Dev-Cpp (also reset old configure). But after a little time the problem came back again.
Example code:
#include <stdio.h>
int main(void)
{
int a, b;
printf("Please give me number 1: ");
scanf("%d", &a);
printf("Please give me number 2: ");
scanf("%d", &b);
printf("Sum = %d", a + b);
}
The debugger warned me:
C:\Users\Nam\Dropbox\code>gdb sum.exe
GNU gdb (GDB) 7.6.1
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "mingw32".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from C:\Users\Nam\Dropbox\code\sum.exe...done.
(gdb) b main
Breakpoint 1 at 0x4016b3
(gdb) n
The program is not being run.
(gdb) r
Starting program: C:\Users\Nam\Dropbox\code/sum.exe
[New Thread 7148.0x1b6c]
Breakpoint 1, 0x004016b3 in main ()
(gdb) n
Single stepping until exit from function main,
which has no line number information.
Please give me number 1: 3
Please give me number 2: 4
Sum = 7__mingw_CRTStartup ()
at ../mingwrt-4.0.3-1-mingw32-src/src/libcrt/crt/crt1.c:260
260 ../mingwrt-4.0.3-1-mingw32-src/src/libcrt/crt/crt1.c: No such file or di
rectory.
(gdb)
I couldn't know how to fix it.
Anyone helps me please :(. Thanks in advance
I couldn't know how to fix it.
I don't think it is necessary to fix it. You got this message since you had already returned from main() and now you are not in your code, it is mingw code that calls your main(). I did the same test as you and this is backtrace after finishing main:
10 printf("Sum = %d", a + b);
(gdb)
Sum = 311 }
(gdb) bt
#0 main () at t.c:11
(gdb) n
__mingw_CRTStartup () at ../mingw/crt1.c:250
250 ../mingw/crt1.c: No such file or directory.
(gdb) bt
#0 __mingw_CRTStartup () at ../mingw/crt1.c:250
#1 0x00401284 in mainCRTStartup () at ../mingw/crt1.c:264
(gdb) n
252 in ../mingw/crt1.c
(gdb) n
[Inferior 1 (process 1448) exited normally]
(gdb)
Again - you don't have to debug mingw startup code. Just give gdb command "continue" so that it can finish executing your process.
I have found source of this __mingw_CRTStartup here http://gitorious.org/mingw/mingw-runtime/source/be97f73714b4e267e5903fc9bdeb0f23fcc3ac8f:crt1.c#L200. You can take a look at what steps mingw library does after returning from main:
static void __attribute__((noreturn))
__mingw_CRTStartup (void)
{
int nRet;
/* skipped some lines ... */
nRet = main (_argc, _argv, environ);
/*
* Perform exit processing for the C library. This means
* flushing output and calling 'atexit' registered functions.
*/
_cexit ();
ExitProcess (nRet);
}
Some useful links:
1) https://stackoverflow.com/a/4988376/184968

Cygwin g++ x86_64 segmentation fault (core dumped) when using > 2GB memory

I've written a prime sieve program in c++, which uses ~12GB ram to calculate all primes below 100,000,000,000 (100 Billion).
The program works fine when compiled with Visual Studio 2012 (in a project set up for x64) as well as g++ on 64 bit linux. However, when compiled with g++ in cygwin64 on Windows 7 Home Premium 64 bit, a segmentation fault occurs when attempting to use more than ~2GB ram (running the sieve for > ~17,000,000,000)
I'm fairly sure it's running as a 64 bit process as there's no *32 next to the process name in task manager.
The code:
#include <iostream>
#include <vector>
#include <cmath>
#include <cstdlib>
using namespace std;
long long sieve(long long n);
int main(int argc, char** argv) {
const long long ONE_BILLION = 1000*1000*1000;
if(argc == 2)
cout << sieve(atol(argv[1])) << endl;
else
cout << sieve(ONE_BILLION * 100) << endl;
}
long long sieve(long long n) {
vector<bool> bools(n+1);
for(long long i = 0; i <=n; i++)
bools[i] = true;
double csqrtn = sqrt(n);
for (long long i = 2; i < csqrtn; ++i)
if (bools[i])
for (long long j = i * i; j < n; j += i)
bools[j] = false;
long long primes2 = 0;
for (long long i = 2; i < n; i++)
if (bools[i])
primes2++;
return primes2;
}
Working fine in Visual studio:
Working fine on x64 linux:
Compiled with the command:
$ g++ -O3 sieve.cpp -o sieve.exe
Running for 18 billion fails:
$ ./sieve.exe 18000000000
Segmentation fault (core dumped)
Works fine (using 2,079,968 K memory according to task manager, though my reputation doesn't allow me to post a third link.)
$ ./sieve.exe 17000000000
755305935
g++ version:
$ g++ --version
g++ (GCC) 4.8.1
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Note: if you are going to try and run this yourself, it can take quite a long time. On a 3570k # 4.2GHz running 100 billion in visual studio takes around 30 mins, 1 billion around 10 seconds. However you might be able to duplicate the error with just the vector allocation.
Edit: since I didn't explicitly put a question: Why does this happen? Is it a limitation of the cygwin64 dll (cygwin64 was only released fully about a month ago)?
Try increasing the cygwin memory limit. This cygwin documentation suggests that the default maximum application heap size on 64-bit platforms is 4GB... although, this may be referring to 32-bit executables on 64-bit platforms... not sure what restrictions cygwin64 64-bit applications would have regarding their maximum heap size.

setting Watch in GDB not working for me

I am facing problem While using watch in gdb . I am trying to keep a
watch on variable m in my code . But for some reason i am getting the following message
no symbol m in current context. I have kept a break point at line 7 so that scope of m is known .
steps performed by me :-
1>g++ -g a.cpp
2>gdb a.out
3>(gdb)break 7
4>(gdb)watch m
Below is my program :-
# include<iostream>
# include<stdio.h>
using namespace std;
int main()
{
int m=10;
char *abc = (char *)"ritesh";
cout << abc << endl ;
m=11;
m=13;
abc=NULL;
cout << *abc <<endl;
return 0;
}
I have also seen How can I use "watch" GDB? But it did not help me much . Can someone explain this problem i am facing.Below are information related to my GNU
ritesh#ubuntu:~$ gdb a.out
GNU gdb (Ubuntu/Linaro 7.3-0ubuntu2) 7.3-2011.08
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-linux-gnu".
For bug reporting instructions, please see:
<http://bugs.launchpad.net/gdb-linaro/>...
Reading symbols from /home/ritesh/a.out...done.
When you load your program into a debugger it is not being run yet. However, you try to watch a symbol, which will start to "live" in a function -- main() function -- and will "disappear" when you return from the function.
For example, in this code
void func() {
int b = 1;
++b;
cout << b << endl;
}
int main() {
int a = 1;
func();
cout << a << endl;
}
you can't set a watch of the value of a before start executing a program, and a watch on the value of b until the execution enters func().

Issue on RHEL4 release using boost 1.36 and C++

I am struggling with a mysterious problem
I only see on my RHEL4 release build. Some of my unit tests (using boost 1.36 unit test framework) fail on RHEL4 (gcc 3.4.6) and using release build-type. I do not see the problem using RHEL5 release or debug build types (gcc 4.1.2, boost-1.39); neither do I
see it on Windows 32 bit or 64 bit using either Visual Studio 2005 (using boost-1.36) or 2008 (using boost-1.39).
Suspecting that this may be due to some subtle memory issue, I proceeded to run valgrind on the test application (minimal case that preserved the problem). Here is what I got when I ran valgrind using "full, no-reachable" mode:
==12285== Memcheck, a memory error detector.
==12285== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al.
==12285== Using LibVEX rev 1575, a library for dynamic binary translation.
==12285== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP.
==12285== Using valgrind-3.1.1, a dynamic binary instrumentation framework.
==12285== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al.
==12285== For more details, rerun with: -v
==12285==
==12285== My PID = 12285, parent PID = 12284. Prog and args are:
==12285== ./myprojd
==12285==
==12285== Syscall param sigaltstack(ss) points to uninitialised byte(s)
==12285== at 0x3AD682EDA9: sigaltstack (in /lib64/tls/libc-2.3.4.so)
==12285== by 0x6488638: boost::detail::signal_handler::~signal_handler()
(in /<path_to>/libboost_unit_test_framework-gcc34-mt-1_36.so.1.36.0)
==12285== by 0x648975E: boost::execution_monitor::catch_signals
(boost::unit_test::callback0<int> const&)
(in /<path_to>/libboost_unit_test_framework-gcc34-mt-1_36.so.1.36.0)
==12285== by 0x6489813: boost::execution_monitor::execute
(boost::unit_test::callback0<int> const&)
(in /<path_to>/libboost_unit_test_framework-gcc34-mt-1_36.so.1.36.0)
==12285== by 0x648F2E4: boost::unit_test::framework::run(unsigned long, bool)
(in /<path_to>/libboost_unit_test_framework-gcc34-mt-1_36.so.1.36.0)
==12285== by 0x649BD02: boost::unit_test::unit_test_main(bool (*)(), int, char**)
(in /<path_to>/libboost_unit_test_framework-gcc34-mt-1_36.so.1.36.0)
==12285== by 0x4147F0: main (init.cpp:132)
==12285== Address 0x7FEFFF3B0 is on thread 1's stack
==12285==
==12285== ERROR SUMMARY: 6 errors from 1 contexts (suppressed: 4 from 1)
==12285== malloc/free: in use at exit: 190,112 bytes in 1,869 blocks.
==12285== malloc/free: 23,128 allocs, 21,259 frees, 2,520,845 bytes allocated.
==12285== For counts of detected errors, rerun with: -v
==12285== searching for pointers to 1,869 not-freed blocks.
==12285== checked 2,184,272 bytes.
==12285==
==12285== LEAK SUMMARY:
==12285== definitely lost: 0 bytes in 0 blocks.
==12285== possibly lost: 0 bytes in 0 blocks.
==12285== still reachable: 190,112 bytes in 1,869 blocks.
==12285== suppressed: 0 bytes in 0 blocks.
==12285== Reachable blocks (those to which a pointer was found) are not shown.
==12285== To see them, rerun with: --show-reachable=yes
Ofcourse, I ran this in debug mode (although as I mentioned the error occurs only in release mode). If I run valgrind in release mode, I get the same output (with perhaps
less detail such as line #s). From this it appears that the problem is somehow in boost-1.36, or perhaps my definition of init_unit_test_suite? Clearly one thing I can try is
to run using boost-1.39 on all platforms; but unfortunately, we're currently on boost-1.36 for RHEL4 and VS2005, and so this may not be practical yet.
I also observe that forcing a certain logger output to console at a point where the test fails, enables the test to pass (not good, I know)! Suspecting that this might be due that I commented all logger output and ran valgrind - so that's what's posted above. If you need some code snippets of the init_unit_test_suite function; I can post that, if it helps. Any ideas to resolve this are welcome and greatly appreciated.
05/26/2011 Edit:
Here's the init_unit_test_suite - appreciate if somebody could take a look.
std::ofstream log_stream;
std::ofstream report_stream;
const_string retrieve_framework_parameter( const_string cla_name, int argc, char** argv ) {
//- first try to find parameter among command line arguments if present
if( argc ) {
//- locate corresponding cla name
if( !cla_name.is_empty() ) {
for( int i = 1; i < argc; ++i ) {
if( cla_name == const_string( argv[i], cla_name.size() ) && argv[i][cla_name.size()] == '=' ) {
const_string result = argv[i] + cla_name.size() + 1;
for( int j = i; j < argc; ++j ) {
argv[j] = argv[j+1];
}
--argc;
return result;
}
}
}
}
return std::getenv( cla_name.begin() );
}
//! Format results to CPP UNIT xml
class simple_report_formatter : public results_reporter::format {
public:
virtual void results_report_start( std::ostream&) {
}
virtual void results_report_finish( std::ostream&) {
}
virtual void test_unit_report_start(test_unit const&, std::ostream&) {
}
virtual void test_unit_report_finish(test_unit const& tu, std::ostream& out) {
if( tu.p_type == tut_case ) {
const test_results& r = results_collector.results(tu.p_id);
if( r.passed() ) {
out<<"[PASS] ";
} else {
out<<"[FAIL] ";
}
out<<"Test Case <unit_"<<tu.p_name.get()<<"> ";
if( !r.passed() ) {
out<<" - ";
out<<"!! Assertions failed: "<<r.p_assertions_failed;
out<<" - See log files for details on failures !!";
}
out<<std::endl;
#if defined(MYPROJ_WINDOWS) && defined(MYPROJ_DEBUG)
if( !r.passed() ) {
std::ostringstream msg;
msg<<"!! "<<tu.p_name.get()<<" FAILED !!"<<std::endl;
OutputDebugStringA(msg.str().c_str());
}
#endif
}
}
virtual void do_confirmation_report(test_unit const&, std::ostream&) {
}
};
bool init_unit_test_suite() {
const_string log_file = retrieve_framework_parameter(
"--log_file",
framework::master_test_suite().argc,
framework::master_test_suite().argv
);
if( !log_file.empty() ) {
log_stream.open(log_file.begin());
unit_test_log.set_stream(log_stream);
}
const_string report_file = retrieve_framework_parameter(
"--report_file",
framework::master_test_suite().argc,
framework::master_test_suite().argv
);
if( !report_file.empty() ) {
report_stream.open(report_file.begin());
results_reporter::set_stream(report_stream);
}
if( runtime_config::report_format() == CLF ) {
results_reporter::set_format(new simple_report_formatter);
}
// This is providing the sensible default configuration when the test is being run
// without any input parameters whatsoever: print the final report to console
if( framework::master_test_suite().argc <= 1 ) {
results_reporter::set_stream(std::cout);
results_reporter::set_format(new simple_report_formatter);
results_reporter::set_level(DETAILED_REPORT);
}
framework::master_test_suite().p_name.set(MYPROJ_TEST_SUITE_NAME);
return true;
}
This "error" in valgrind is not necessarily a problem. When a system call is called in Linux the memory often has to be copied from users space to kernel space. In doing so the it may copy uninitialized bytes.
Just because it copies these bytes into kernel space does not mean the kernel will actually do anything with the uninitialized bytes. What the kernel does with the bytes depends heavily on the semantics of the system call in question.
Valgrind has no simple way of knowing if it is OK that some of the bytes passed in the system call are uninitialized so it always signals an error. Many of similar errors are suppressed by valgrind.
You can see some of valgrind's default suppressions in this file: /usr/lib/valgrind/default.supp You can also create your own suppression files if you like and use them in your unit test to suppress the error message. If you are not experiencing any actual problems on this system them suppressing the error is probably a good idea. See valgrind's command line options.