You can also try LD_DEBUG and compare the output on different machines.
http://docs.sun.com/app/docs/doc/817-1984/chapter3-31?a=view
Rayson
On 2/26/08, LiJIan <[EMAIL PROTECTED]> wrote:
> I used "ldd" to see the libraray linked, result shows libmtmalloc.so.1 is
> linked correctly.
>
> Strange
We're going to need some more information to diagnose your problem.
For example,
can you send the mem.d script? It's actually important to use pldd
rather than ldd
since pldd will actually show the libraries being used at runtime. Is
this problem
always reproducible? Are you able to just enab
I used "ldd" to see the libraray linked, result shows libmtmalloc.so.1 is
linked correctly.
Strange thing is if I start dtrace script at the same time runing the programme
i.e. using "dtrace -qs ./mem.d -c ./test", libmtmalloc.so.1:malloc:entry can be
found. I don't know the difference betwee
There are smarter people than me that can go into better detail, but
I'll give it a shot. All the memory allocators you're usually going
to see grow your address space using brk(1)/sbrk(1). They generally
don't shrink the address space back down.
If you really need the address space to shrink (t
In the vmstat output under the 'kthr' colums I can see a good number of swapped
out LWP's (the 'w') column. Is there a Dtrace tool (or other tool) that will
show me which LWP's are swapped?
Jesse
--
This message posted from opensolaris.org
___
dtrace
I wanted to post a closing message for this thread.
I resolved the system contention on this Solaris VM - although it was not by
way of Dtrace.
Turns out the VMWare settings in the vmx file for this Solaris VM were not
optimal:
> memsize = "2048" (old file)
> sched.mem.max = "256" (old file) - (If
Hi,
We would like to add USDT probes to Memcached (
http://www.danga.com/memcached ). This is our current proposal:
provider memcached {
/**
* Fired when a connection object is allocated from the connection pool
* @param connid the connection id
*/
probe conn_allocate(int conni
N_conreq:entry {
self->x=1;
calledaddr=(struct xaddrf *)arg3;
callingaddr=(struct xaddrf *)arg4;
trace(calledaddr->link_id);
tracemem(calledaddr->DTE_MAC.lsap_add, 80);
trace(callingaddr->link_id);
tracemem(callingaddr->DTE_MAC.lsap_add, 80
Hello Everybody,
we are teaching a class on Operating Systems at Dartmouth and we came across a
strange
behavior we can not find an explanation to. I forward here what Sean Smith has
found so far:
When playing around in class with memory faults and dtrace, we noticed
something interesting:
the
