> Just to be sure that you know, free(3c) does not > return memory back to > system. Sorry if I repeat well known fact. > > ============================= man free(3c) > ============================= > The argument to free() is a pointer to a block > previously > allocated by malloc(), calloc(), or realloc(). > After free() > is executed, this space is made available for > further allo- > cation by the application, though not returned > to the sys- > tem. Memory is returned to the system only upon > termination > of the application. If ptr is a null pointer, > no action > occurs. If a random number is passed to free(), > the results > are undefined. > ====================================================== Yes i did thought in that angle so far thank for reminiding . Since the application is real-time in nature and runs continoulsy , termiantion is rulled out. Also we are facing problem in particular site implemntations at other implentations it runs fine.
> ============== > > This means that if you allocate 100Mb buffer, free it > and allocate 30Mb > buffer, you will see still 100Mb RSS. C++ delete and > delete[] operators > are built on top of the same mechanism. > It is left to the OS to swap out unused memory pages. > > 1) Is there any way where I can restrict dtrace to > look for probe only > > certain source files or functions? > > Source files, AFAIK no. Functions yes. I guess that > you want to > distinguish between allocations made in some specific > functions and the > rest of the allocations ? > > > > 3) I got a clue of using "libgc.so" which acts as > garbage collector is > > there any problem in using and how reliable and > effective is this. > > I would also be interested. > > > ( it works fine on sample application but not > improvement in real > > application ). I just linked the library "libgc.so" > at compile time ? > > Anything else need to done for this ? > > For C++ I think that you have to use -library=gc > > > > Your inputs will be highly appreciated. Please do > share your thoughts > > and techniques. > > I would try to make libumem work, it should give you > the data. > > Not sure if this helps :) this whats i have done to use libumem and mdb ... #UMEM_DEBUG=default;export UMEM_DEBUG=default #UMEM_LOGGING=transaction;export UMEM_LOGGING=transaction #LD_PRELOAD=libumem.so.1;export LD_PRELOAD=libumem.so.1 # ./myapp Generate core from live system with pid #gcore 21250 bash-3.00$ mdb core.21250 Loading modules: [ libumem.so.1 libc.so.1 ld.so.1 ] > ::findleaks mdb: findleaks: No allocations have occured -- no possible leaks. Anything else is missing from my sequence of steps ? Do i need to do add anything during compilation ? > Vlad > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.9 (SunOS) > > iEYEARECAAYFAkhNGbcACgkQqVN0MVP42YwBKACgvwl7wn9uDWrrOL > nF5JSp0W0f > YXYAnR8Rlc9x1P7fntZXWbic8hv9LsQK > =y2EK > -----END PGP SIGNATURE----- > _______________________________________________ > dtrace-discuss mailing list > [email protected] -- This message posted from opensolaris.org _______________________________________________ dtrace-discuss mailing list [email protected]
