Re: [Valgrind-users] Does valgrind work with Boehm garbage collector?
On Mon, Feb 18, 2019 at 7:07 PM John Reiser wrote: > On 2/17/19, Peng Yu wrote: > > $ flex -o main.l.c main.l > > $ clang -I. -DGC_DEBUG -Wall -pedantic -g -c -o main.l.o main.l.c # > > rapidstring.h is in . > > $ clang main.l.o -lgc -lfl -o main.l.exe > > $ dsymutil main.l.exe > > What is 'dsymutil', where did you get it, what version? > What is the hardware architecture? That is just the command on Mac to generate the debug symbols. > > > The execution recipe works for me on Fedora 28 using > valgrind-3.14.0-7.fc28.x86_64. > I omitted dsymutil. Why is it essential for you? It is not essential. > > > $ ldd main.l.exe > linux-vdso.so.1 (0x7fffa7d9f000) > libgc.so.1 => /lib64/libgc.so.1 (0x7f255ef81000) > libc.so.6 => /lib64/libc.so.6 (0x7f255ebc2000) > libpthread.so.0 => /lib64/libpthread.so.0 (0x7f255e9a3000) > libdl.so.2 => /lib64/libdl.so.2 (0x7f255e79f000) > libatomic_ops.so.1 => /lib64/libatomic_ops.so.1 > (0x7f255e59c000) > libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x7f255e384000) > /lib64/ld-linux-x86-64.so.2 (0x7f255f2de000) > > $ rpm -qf /lib64/libgc.so.1 > gc-7.6.4-3.fc28.x86_64 > $ rpm -qf /usr/bin/flex > flex-2.6.1-7.fc28.x86_64 > $ rpm -q clang > clang-6.0.1-2.fc28.x86_64 Why there is no segmentation fault in your run? > > > $ valgrind ./main.l.exe ==23299== Memcheck, a memory error detector > ==23299== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. > ==23299== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright > info > ==23299== Command: ./main.l.exe > ==23299== > ==23299== Conditional jump or move depends on uninitialised value(s) > ==23299==at 0x4E4D166: GC_push_all_eager (in /usr/lib64/libgc.so.1.3.2) > ==23299==by 0x4E49D21: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299==by 0x4E4E786: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299==by 0x4E4D896: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299==by 0x4E42C44: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299==by 0x4E43348: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299==by 0x4E5043B: GC_init (in /usr/lib64/libgc.so.1.3.2) > ==23299==by 0x403203: main (main.l:34) > ==23299== > ==23299== Conditional jump or move depends on uninitialised value(s) > ==23299==at 0x4E4D16B: GC_push_all_eager (in /usr/lib64/libgc.so.1.3.2) > ==23299==by 0x4E49D21: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299==by 0x4E4E786: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299==by 0x4E4D896: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299==by 0x4E42C44: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299==by 0x4E43348: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299==by 0x4E5043B: GC_init (in /usr/lib64/libgc.so.1.3.2) > ==23299==by 0x403203: main (main.l:34) > ==23299== > ==23299== Use of uninitialised value of size 8 > ==23299==at 0x4E4CF57: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299==by 0x4E4D171: GC_push_all_eager (in /usr/lib64/libgc.so.1.3.2) > ==23299==by 0x4E49D21: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299==by 0x4E4E786: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299==by 0x4E4D896: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299==by 0x4E42C44: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299==by 0x4E43348: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299==by 0x4E5043B: GC_init (in /usr/lib64/libgc.so.1.3.2) > ==23299==by 0x403203: main (main.l:34) > ==23299== > ==23299== Conditional jump or move depends on uninitialised value(s) > ==23299==at 0x4E4CF66: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299==by 0x4E4D171: GC_push_all_eager (in /usr/lib64/libgc.so.1.3.2) > ==23299==by 0x4E49D21: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299==by 0x4E4E786: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299==by 0x4E4D896: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299==by 0x4E42C44: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299==by 0x4E43348: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299==by 0x4E5043B: GC_init (in /usr/lib64/libgc.so.1.3.2) > ==23299==by 0x403203: main (main.l:34) > ==23299== > ==23299== Use of uninitialised value of size 8 > ==23299==at 0x4E4CF9A: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299==by 0x4E4D171: GC_push_all_eager (in /usr/lib64/libgc.so.1.3.2) > ==23299==by 0x4E49D21: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299==by 0x4E4E786: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299==by 0x4E4D896: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299==by 0x4E42C44: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299==by 0x4E43348: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299==by 0x4E5043B: GC_init (in /usr/lib64/li
Re: [Valgrind-users] Does valgrind work with Boehm garbage collector?
Here is the output. It still fails. So I am not supposed to use valgrind when I use boehm gc? $ valgrind --tool=none ./main.l.exe < You might first try with --tool=none to see if the basis of valgrind+boehm > gc works. -- Regards, Peng ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
[Valgrind-users] Does valgrind work with Boehm garbage collector?
Hi,
I have the follow flex code using Boehm garbage collector.
http://www.hboehm.info/gc/gcinterface.html
The program is compiled with the following commands.
$ flex -o main.l.c main.l
$ clang -I. -DGC_DEBUG -Wall -pedantic -g -c -o main.l.o main.l.c #
rapidstring.h is in .
$ clang main.l.o -lgc -lfl -o main.l.exe
$ dsymutil main.l.exe
rapidstring.h can be downloaded here.
https://raw.githubusercontent.com/boyerjohn/rapidstring/master/include/rapidstring.h
The following commands show that without using valgrind, the program
runs OK. But if valgrind is used, the program will cause a
segmentation fault.
Is it because valgrind does not work with a garbage collector?
$ ./main.l.exe <
#define RS_MALLOC GC_MALLOC
#define RS_REALLOC GC_REALLOC
#define RS_FREE GC_FREE
#include
typedef struct {
int num;
rapidstring str;
} YYSTYPE;
// clang-format off
%}
%option nodefault noinput nounput
%option reentrant bison-bridge
%%
[[:digit:]]+yylval->num=atoi(yytext); return TOK_NUMBER;
[[:alpha:]]+{
// clang-format on
rs_cpy(>str, yytext);
return TOK_STRING;
// clang-format off
}
.|\n
%%
int main() {
// clang-format on
GC_INIT();
yyscan_t scanner;
yylex_init();
int tok;
YYSTYPE lval;
rs_init();
while ((tok = yylex(, scanner))) {
if (tok == TOK_NUMBER) {
printf("tok = %d, yylval= %d\n", tok,
yyget_lval(scanner)->num);
} else if (tok == TOK_STRING) {
printf("tok = %d, yylval= %s\n", tok,
rs_data(_lval(scanner)->str));
}
}
yylex_destroy(scanner);
return 0;
}
--
Regards,
Peng
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
[Valgrind-users] How can valgrind prevent Segmentation fault?
Hi, I have an executable. If I just run on its own, there will be segmentation fault. But if I run it using valgrind, it finishes successfully. Does anybody how can this happen? How to debug such a program? Thanks. -- Regards, Peng ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
[Valgrind-users] Why there is possibly lost on throw std::runtime_error(string)?
Hi,
valgrind reports that there is possible lost. But it doesn't seem
there should be any lost. Why valgrind reports it as possible lost? Is
there a way to remove such 'possible lost' from the valgrind report?
/tmp$ cat main.cpp
#include stdexcept
int main() {
throw std::runtime_error(xx);
}
/tmp$ g++ main.cpp
/tmp$ valgrind ./a.out
==32312== Memcheck, a memory error detector
==32312== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==32312== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
==32312== Command: ./a.out
==32312==
--32312-- ./a.out:
--32312-- dSYM directory is missing; consider using --dsymutil=yes
terminate called after throwing an instance of 'std::runtime_error'
what(): xx
==32312==
==32312== Process terminating with default action of signal 6 (SIGABRT)
==32312==at 0x1001500B6: __kill (in /usr/lib/libSystem.B.dylib)
==32312==by 0x10006F5D1: __gnu_cxx::__verbose_terminate_handler()
(in /usr/lib/libstdc++.6.0.9.dylib)
==32312==by 0x10006DAE0: __cxxabiv1::__terminate(void (*)()) (in
/usr/lib/libstdc++.6.0.9.dylib)
==32312==by 0x10006DB15: std::terminate() (in
/usr/lib/libstdc++.6.0.9.dylib)
==32312==by 0x10006DBFB: __cxa_throw (in /usr/lib/libstdc++.6.0.9.dylib)
==32312==by 0x10DF7: main (in ./a.out)
==32312==
==32312== HEAP SUMMARY:
==32312== in use at exit: 259 bytes in 4 blocks
==32312== total heap usage: 5 allocs, 1 frees, 282 bytes allocated
==32312==
==32312== LEAK SUMMARY:
==32312==definitely lost: 0 bytes in 0 blocks
==32312==indirectly lost: 0 bytes in 0 blocks
==32312== possibly lost: 27 bytes in 1 blocks
==32312==still reachable: 232 bytes in 3 blocks
==32312== suppressed: 0 bytes in 0 blocks
==32312== Rerun with --leak-check=full to see details of leaked memory
==32312==
==32312== For counts of detected and suppressed errors, rerun with: -v
==32312== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Abort trap
--
Regards,
Peng
--
Using storage to extend the benefits of virtualization and iSCSI
Virtualization increases hardware utilization and delivers a new level of
agility. Learn what those decisions are and how to modernize your storage
and backup environments for virtualization.
http://www.accelacomm.com/jaw/sfnl/114/51434361/
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Why there is possibly lost on throw std::runtime_error(string)?
On Wed, Sep 7, 2011 at 1:31 AM, Jeffrey Walton noloa...@gmail.com wrote: Hi Peng, On Wed, Sep 7, 2011 at 2:17 AM, Peng Yu pengyu...@gmail.com wrote: Hi, valgrind reports that there is possible lost. But it doesn't seem there should be any lost. Why valgrind reports it as possible lost? Is there a way to remove such 'possible lost' from the valgrind report? I've found I'll get the same reports when using global objects. If you are using global objects, put them in an accessor function. In an accessor, the dtors will run, and you won't violate C++'s rule on non-local statics (and cross module dependencies). I don't exactly following your instructions. Would you please show me an concrete example on how to change my simple test code? Thanks! -- Regards, Peng -- Using storage to extend the benefits of virtualization and iSCSI Virtualization increases hardware utilization and delivers a new level of agility. Learn what those decisions are and how to modernize your storage and backup environments for virtualization. http://www.accelacomm.com/jaw/sfnl/114/51434361/ ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Why there is possibly lost on throw std::runtime_error(string)?
On Wed, Sep 7, 2011 at 2:42 AM, Tom Hughes t...@compton.nu wrote: On 07/09/11 07:17, Peng Yu wrote: valgrind reports that there is possible lost. But it doesn't seem there should be any lost. Why valgrind reports it as possible lost? Is there a way to remove such 'possible lost' from the valgrind report? Well if you do what it says and use -leak-check=full then you might find out where the leak is coming from. Here is the output with -leak-check=full. How can I tell that there is definitely no memory leak? /tmp$ valgrind --leak-check=full ./a.out ==40738== Memcheck, a memory error detector ==40738== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al. ==40738== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info ==40738== Command: ./a.out ==40738== --40738-- ./a.out: --40738-- dSYM directory is missing; consider using --dsymutil=yes terminate called after throwing an instance of 'std::runtime_error' what(): xx ==40738== ==40738== Process terminating with default action of signal 6 (SIGABRT) ==40738==at 0x1001500B6: __kill (in /usr/lib/libSystem.B.dylib) ==40738==by 0x10006F5D1: __gnu_cxx::__verbose_terminate_handler() (in /usr/lib/libstdc++.6.0.9.dylib) ==40738==by 0x10006DAE0: __cxxabiv1::__terminate(void (*)()) (in /usr/lib/libstdc++.6.0.9.dylib) ==40738==by 0x10006DB15: std::terminate() (in /usr/lib/libstdc++.6.0.9.dylib) ==40738==by 0x10006DBFB: __cxa_throw (in /usr/lib/libstdc++.6.0.9.dylib) ==40738==by 0x10DF7: main (in ./a.out) ==40738== ==40738== HEAP SUMMARY: ==40738== in use at exit: 259 bytes in 4 blocks ==40738== total heap usage: 5 allocs, 1 frees, 282 bytes allocated ==40738== ==40738== 27 bytes in 1 blocks are possibly lost in loss record 2 of 4 ==40738==at 0x100010D7B: operator new(unsigned long) (vg_replace_malloc.c:261) ==40738==by 0x1000534D0: std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocatorchar const) (in /usr/lib/libstdc++.6.0.9.dylib) ==40738==by 0x10005517C: char* std::string::_S_constructchar const*(char const*, char const*, std::allocatorchar const, std::forward_iterator_tag) (in /usr/lib/libstdc++.6.0.9.dylib) ==40738==by 0x1000E: std::basic_stringchar, std::char_traitschar, std::allocatorchar ::basic_string(char const*, std::allocatorchar const) (in /usr/lib/libstdc++.6.0.9.dylib) ==40738==by 0x10D55: main (in ./a.out) ==40738== ==40738== LEAK SUMMARY: ==40738==definitely lost: 0 bytes in 0 blocks ==40738==indirectly lost: 0 bytes in 0 blocks ==40738== possibly lost: 27 bytes in 1 blocks ==40738==still reachable: 232 bytes in 3 blocks ==40738== suppressed: 0 bytes in 0 blocks ==40738== Reachable blocks (those to which a pointer was found) are not shown. ==40738== To see them, rerun with: --leak-check=full --show-reachable=yes ==40738== ==40738== For counts of detected and suppressed errors, rerun with: -v ==40738== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) Abort trap -- Regards, Peng -- Using storage to extend the benefits of virtualization and iSCSI Virtualization increases hardware utilization and delivers a new level of agility. Learn what those decisions are and how to modernize your storage and backup environments for virtualization. http://www.accelacomm.com/jaw/sfnl/114/51434361/ ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Why there is possibly lost on throw std::runtime_error(string)?
On Wed, Sep 7, 2011 at 8:45 AM, Dan Kegel d...@kegel.com wrote:
After a SIGABRT, wouldn't you expect a bunch of memory leaks?
So, basically, you are saying I can ignore all the possibly lost after
SIGABRT, right?
I think that there is problem between std::string and valgrind. I
changed the the std:string used inside std::runtime_error and get a
new class ValgrindRuntimeError. Using this new class, the possibly
lost is gone.
#include stdexcept
#include iostream
#include vector
class ValgrindRuntimeError : public std::exception {
public:
/** Takes a character string describing the error. */
ValgrindRuntimeError(char s[]) {
_s=new char[strlen(s)];
strcpy(_s, s);
}
virtual ~ValgrindRuntimeError() throw() {
delete[] _s;
}
/** Returns a C-style character string describing the general cause of
* the current error (the same string passed to the ctor). */
virtual const char* what() const throw() {
return _s;
}
private:
char *_s;
};
int main() {
ValgrindRuntimeError a(std::string().c_str());
throw a;
}
Or if you just want to get rid of the possibly lost messages, try
--show-possibly-lost=no
I'm afraid that I miss some true lost using this option.
On Wed, Sep 7, 2011 at 6:07 AM, Peng Yu pengyu...@gmail.com wrote:
On Wed, Sep 7, 2011 at 2:42 AM, Tom Hughes t...@compton.nu wrote:
On 07/09/11 07:17, Peng Yu wrote:
valgrind reports that there is possible lost. But it doesn't seem
there should be any lost. Why valgrind reports it as possible lost? Is
there a way to remove such 'possible lost' from the valgrind report?
Well if you do what it says and use -leak-check=full then you might find
out where the leak is coming from.
Here is the output with -leak-check=full. How can I tell that there
is definitely no memory leak?
/tmp$ valgrind --leak-check=full ./a.out
==40738== Memcheck, a memory error detector
==40738== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==40738== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
==40738== Command: ./a.out
==40738==
--40738-- ./a.out:
--40738-- dSYM directory is missing; consider using --dsymutil=yes
terminate called after throwing an instance of 'std::runtime_error'
what(): xx
==40738==
==40738== Process terminating with default action of signal 6 (SIGABRT)
==40738== at 0x1001500B6: __kill (in /usr/lib/libSystem.B.dylib)
==40738== by 0x10006F5D1: __gnu_cxx::__verbose_terminate_handler()
(in /usr/lib/libstdc++.6.0.9.dylib)
==40738== by 0x10006DAE0: __cxxabiv1::__terminate(void (*)()) (in
/usr/lib/libstdc++.6.0.9.dylib)
==40738== by 0x10006DB15: std::terminate() (in
/usr/lib/libstdc++.6.0.9.dylib)
==40738== by 0x10006DBFB: __cxa_throw (in /usr/lib/libstdc++.6.0.9.dylib)
==40738== by 0x10DF7: main (in ./a.out)
==40738==
==40738== HEAP SUMMARY:
==40738== in use at exit: 259 bytes in 4 blocks
==40738== total heap usage: 5 allocs, 1 frees, 282 bytes allocated
==40738==
==40738== 27 bytes in 1 blocks are possibly lost in loss record 2 of 4
==40738== at 0x100010D7B: operator new(unsigned long)
(vg_replace_malloc.c:261)
==40738== by 0x1000534D0: std::string::_Rep::_S_create(unsigned
long, unsigned long, std::allocatorchar const) (in
/usr/lib/libstdc++.6.0.9.dylib)
==40738== by 0x10005517C: char* std::string::_S_constructchar
const*(char const*, char const*, std::allocatorchar const,
std::forward_iterator_tag) (in /usr/lib/libstdc++.6.0.9.dylib)
==40738== by 0x1000E: std::basic_stringchar,
std::char_traitschar, std::allocatorchar ::basic_string(char
const*, std::allocatorchar const) (in
/usr/lib/libstdc++.6.0.9.dylib)
==40738== by 0x10D55: main (in ./a.out)
==40738==
==40738== LEAK SUMMARY:
==40738== definitely lost: 0 bytes in 0 blocks
==40738== indirectly lost: 0 bytes in 0 blocks
==40738== possibly lost: 27 bytes in 1 blocks
==40738== still reachable: 232 bytes in 3 blocks
==40738== suppressed: 0 bytes in 0 blocks
==40738== Reachable blocks (those to which a pointer was found) are not
shown.
==40738== To see them, rerun with: --leak-check=full --show-reachable=yes
==40738==
==40738== For counts of detected and suppressed errors, rerun with: -v
==40738== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Abort trap
--
Regards,
Peng
--
Using storage to extend the benefits of virtualization and iSCSI
Virtualization increases hardware utilization and delivers a new level of
agility. Learn what those decisions are and how to modernize your storage
and backup environments for virtualization.
http://www.accelacomm.com/jaw/sfnl/114/51434361/
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
--
Regards,
Peng
Re: [Valgrind-users] Why there is possibly lost on throw std::runtime_error(string)?
On Wed, Sep 7, 2011 at 9:39 AM, Tom Hughes t...@compton.nu wrote:
On 07/09/11 15:37, Peng Yu wrote:
I think that there is problem between std::string and valgrind. I
changed the the std:string used inside std::runtime_error and get a
new class ValgrindRuntimeError. Using this new class, the possibly
lost is gone.
Please read the FAQ entry about std::string and memory leaks:
http://valgrind.org/docs/manual/faq.html#faq.reports
Using malloc, doesn't help in this case. See below.
/tmp$ cat main.cpp
#include stdexcept
int main() {
throw std::runtime_error(xx);
}
/tmp$ g++ --version
i686-apple-darwin10-g++-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5666) (dot 3)
Copyright (C) 2007 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.
/tmp$ export GLIBCXX_FORCE_NEW
/tmp$ g++ main.cpp
/tmp$ valgrind ./a.out
==42321== Memcheck, a memory error detector
==42321== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==42321== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
==42321== Command: ./a.out
==42321==
--42321-- ./a.out:
--42321-- dSYM directory is missing; consider using --dsymutil=yes
terminate called after throwing an instance of 'std::runtime_error'
what(): xx
==42321==
==42321== Process terminating with default action of signal 6 (SIGABRT)
==42321==at 0x1001500B6: __kill (in /usr/lib/libSystem.B.dylib)
==42321==by 0x10006F5D1: __gnu_cxx::__verbose_terminate_handler()
(in /usr/lib/libstdc++.6.0.9.dylib)
==42321==by 0x10006DAE0: __cxxabiv1::__terminate(void (*)()) (in
/usr/lib/libstdc++.6.0.9.dylib)
==42321==by 0x10006DB15: std::terminate() (in
/usr/lib/libstdc++.6.0.9.dylib)
==42321==by 0x10006DBFB: __cxa_throw (in /usr/lib/libstdc++.6.0.9.dylib)
==42321==by 0x10DF7: main (in ./a.out)
==42321==
==42321== HEAP SUMMARY:
==42321== in use at exit: 259 bytes in 4 blocks
==42321== total heap usage: 5 allocs, 1 frees, 282 bytes allocated
==42321==
==42321== LEAK SUMMARY:
==42321==definitely lost: 0 bytes in 0 blocks
==42321==indirectly lost: 0 bytes in 0 blocks
==42321== possibly lost: 27 bytes in 1 blocks
==42321==still reachable: 232 bytes in 3 blocks
==42321== suppressed: 0 bytes in 0 blocks
==42321== Rerun with --leak-check=full to see details of leaked memory
==42321==
==42321== For counts of detected and suppressed errors, rerun with: -v
==42321== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Abort trap
--
Regards,
Peng
--
Using storage to extend the benefits of virtualization and iSCSI
Virtualization increases hardware utilization and delivers a new level of
agility. Learn what those decisions are and how to modernize your storage
and backup environments for virtualization.
http://www.accelacomm.com/jaw/sfnl/114/51434361/
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
