> kgardas, check out this blog entry that's called
> "Finding memory leaks on Solaris systems":
>
> http://prefetch.net/blog/index.php/2006/02/19/finding-
> memory-leaks-on-solaris-systems/
>
> Basically, there's live kernel debugging tool in
> Solaris called "mdb" that will let you debug a live
> kernel with the "mdb -k" version of the command:
>
> http://www.princeton.edu/~unix/Solaris/troubleshoot/ad
> b.html
>
> and it has a "::findleaks" command that's useful for
> finding memory leaks.
As I already wrote, I used mdb/libumem in the past on SXDE 1/08, but I'm not so
successful using it on OS 2009.06. Let's have for example this testcase:
#include <iostream>
#include <vector>
#include <unistd.h>
using namespace std;
class test
{
public:
test()
{
for (int i = 0; i < 10; i++) {
buf[i] = i;
}
}
int buf[1024];
};
int
main()
{
vector<test*> vectest;
for (int i = 0; i < 10; i++) {
vectest.push_back(new test);
for (int j = 0; j < 10; j++) {
cout << "(" << i << ", " << j << "): " << vectest[i]->buf[j] <<
endl;
}
}
return 0;
}
printing is just for doing something there to force C++ compiler to really
generate code. Anyway, I've compiled by:
$ CC -g test.cc -o test-cxx-leaks
and then run:
$ mdb test-cxx-leaks
> ::load libumem
> ::sysbp _exit
> ::run
[....]
mdb: stop on entry to _exit
mdb: target stopped at:
0xfecb3a38: addb %al,(%eax)
>
> ::findleaks -d
mdb: findleaks: umem is not loaded in the address space
> ::load libumem
mdb: libumem module is already loaded
>
My question is why this happen? I.e. findleaks complain about non loaded
libumem yet, mdb claims libumem is already loaded? As I said, I would bet that
this was working well on SXDE 1/08.
Anyway, let's try second attempt with preloaded libumem and gcore generating
core of running application. I've added following code to the end of `main'
function:
cout << "end loop, please use `gcore " << getpid() << "' to generate core
of this process" << endl;
for (;;) {
}
compiled with:
$ CC -g test.cc -o test-cxx-leaks2
and run with:
$ LD_PRELOAD=libumem.so UMEM_DEBUG=default ./test-cxx-leaks2
[...]
end loop, please use `gcore 2628' to generate core of this process
and then in another terminal:
$ gcore 2628
gcore: core.2628 dumped
$ mdb core.2628
Loading modules: [ libumem.so.1 ld.so.1 ]
> ::findleaks -dv
findleaks: maximum buffers => 76
findleaks: actual buffers => 56
findleaks:
findleaks: potential pointers => 134508
findleaks: dismissals => 106203 (78.9%)
findleaks: misses => 27264 (20.2%)
findleaks: dups => 985 ( 0.7%)
findleaks: follows => 56 ( 0.0%)
findleaks:
findleaks: peak memory usage => 56 kB
findleaks: elapsed CPU time => 0.0 seconds
findleaks: elapsed wall time => 0.0 seconds
findleaks:
findleaks: no memory leaks detected
>
So it thinks there are no memory leaks yet, still there are some. For your
comparison the same program running inside valgrind on linux shows correctly:
$ valgrind --leak-check=yes ./test-cxx-leaks
[...]
==2016== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 19 from 1)
==2016== malloc/free: in use at exit: 400 bytes in 10 blocks.
==2016== malloc/free: 15 allocs, 5 frees, 524 bytes allocated.
==2016== For counts of detected errors, rerun with: -v
==2016== searching for pointers to 10 not-freed blocks.
==2016== checked 108,396 bytes.
==2016==
==2016== 400 bytes in 10 blocks are definitely lost in loss record 1 of 1
==2016== at 0x402377E: operator new(unsigned) (vg_replace_malloc.c:224)
==2016== by 0x8048925: main (test.cc:25)
==2016==
==2016== LEAK SUMMARY:
==2016== definitely lost: 400 bytes in 10 blocks.
==2016== possibly lost: 0 bytes in 0 blocks.
==2016== still reachable: 0 bytes in 0 blocks.
==2016== suppressed: 0 bytes in 0 blocks.
so either I'm doing something wrong on OS or OS 2009.06 libumem/mdb is buggy
and really does not work. In both cases I would like to ask for help either
with correcting my mistake(s) or for telling me where I shall report such issue.
Thanks,
Karel
--
This message posted from opensolaris.org
_______________________________________________
opensolaris-discuss mailing list
[email protected]
