> > ============================= man free(3c) =============================
> 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.
That just screams for the question, what's different between the
implementations ? Different load, different compilation environment,
different OS versions ? Anything else ?
[...]
> > 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.
That's strange, most probably it means that libumem wasn't preloaded
successfully. Any chance that your application links the memory
management library statically ? (maybe you are using something else than
libc ?). Can you run pmap on the generated core file ? It should show you few
memory regions used by libumem. Also you can try in mdb
malloc::dis
and you should see
libumem.so.1`malloc: pushl %ebp
...
and not
libc.so.1`malloc: pushl %ebp
...
If you run
nm -C yourbinary | less
You should find 'void operator delete(void*)' and 'void*operator
new(unsigned)'. In my case it's __1c2k6Fpv_v_ and something else. Again in mdb
looking at the core file, you should see traces of libumem
> __1c2k6Fpv_v_::dis ! grep call
libCrun.so.1`__1c2k6Fpv_v_+9: call +0x0 <libCrun.so.1`__1c2k6Fpv_v_+0xe>
libCrun.so.1`__1c2k6Fpv_v_+0x21:call -0x1efe <PLT=libumem.so.1`free>
libCrun.so.1`__1c2k6Fpv_v_+0x37:call -0x1f84
<PLT:__1cG__CrunRex_chk_unexpected6F_v_>
libCrun.so.1`__1c2k6Fpv_v_+0x3c:call -0x1f79
<PLT:__1cG__CrunMex_rethrow_q6F_v_>
> Anything else is missing from my sequence of steps ?
Not really.
> Do i need to do add anything during compilation ?
I do not think so.
--
Vlad
pgpA4emArgiwt.pgp
Description: PGP signature
_______________________________________________ dtrace-discuss mailing list [email protected]
