Re: [dtrace-discuss] dtrace script
On Dec 23, 2011, at 13:29, Anne Adema aron.ad...@gmail.com wrote: Hi James, What I'm looking for in a while true loop to see amount fopen calls for a certain pid while true do cmd for amount fopen call for certain pid dtrace script sleep 60 done or dtrace script with same loop Gr Anne If you want to monitor one or more processes to see what files they open and close over a given period (while being monitored), then that sort of thing is doable. But just sampling at intervals to get a count won't work, unless you can find something in the program to read that gives you what you wanted. You can use the pid provider to catch calls inside the application, and the profile provider to sample them. Maybe that's what you're getting at. Truss might be easier -- it can count calls into a library (fopen(3C) is in libc) and give statistics. Can you explain why those other mechanisms don't work for you? They look well suited to the task. I really do think that a higher level description of what you're trying to accomplish will be needed in order to get useful suggestions. ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] dtrace script
Anne Adema wrote: Hi Does anyone has a dtrace script which determine in a life system the amount of open files per process id in a Non Global Zone. In general, dtrace allows you to look at *events* as they occur. It's not so good at summarizing system state at a point in time. GZ lsof -z zonename -p pid Does not give the right output. ls /proc/pid/fd | wc -l gives not the open files per process id. Both of those work fine for me. It might help if you can describe what you see that's wrong with the output of those sorts of commands. Otherwise, it will probably be hard to determine what sort of solution might help you. -- James Carlson 42.703N 71.076W carls...@workingcode.com ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] concatenate structure members into one variable
Mehul Choube wrote: Hi, I want the guid in a variable. I tried stringof(), strjoin(), copyinstr() but none works L As defined, it's a structure containing longs and binary data, not a string. Can you describe what sort of result you'd like to see? Or perhaps what sort of problem you'd like to solve? The output is: Id: 11E109F8702B323E9CAF5000568000D0 Is that output wrong ... ? -- James Carlson 42.703N 71.076W carls...@workingcode.com ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] concatenate structure members into one variable
Mehul Choube wrote: Hi, I want to collect the performance information for each myFunc call. The program is multi-threaded and uses multiple queues which can be served by any thread. GUID is the unique handle for each request. I can collect the information and store it based on GUID something like: @[guid] = ... I think the ID is correct. Then just use the data as they are. Dtrace doesn't have functions that translate buffers into D strings. (The trace() mechanism actually logs the raw data; the printing occurs well after the fact when the user-space code gets ahold of the sampled data.) -- James Carlson 42.703N 71.076W carls...@workingcode.com ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] concatenate structure members into one variable
Mehul Choube wrote: Hi, self-d4 = ((GUID_t *)this-sptr)-Data4[0]; works but self-d4 = ((GUID_t *)this-sptr)-Data4; doesn't with following error: dtrace: failed to compile script nums.d: line 20: operator = may not be applied to operand of type unsigned char [8] Since it's an internal array, you should be able to cast it to unsigned char *. Or, if you really want to keep broken out values instead of a structure (why?), you could individually address each byte. It might be helpful to have something like: #define DATA4(d4) (((uint64_t)(d4)[0]56) \ ((uint64_t)(d4)[1]48) \ ((uint64_t)(d4)[2]40) \ ((uint64_t)(d4)[3]32) \ ((uint64_t)(d4)[4]24) \ ((uint64_t)(d4)[5]16) \ ((uint64_t)(d4)[6]8) \ ((uint64_t)(d4)[7])) so you can treat that last one as an integral quantity. -- James Carlson 42.703N 71.076W carls...@workingcode.com ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] following a packet from sendto() to wire (and reverse)
Mathias Koerber wrote:
We did use Dtrace with syscall::sendto:entry/exit to prove that the
application did send the packet, but so far we have no clue how to
determine what happens to the packet afterwards.
Can you show us the trace script you used and the output it showed? How
about details on the network configuration and the packet being sent?
Perhaps there's something in the details that someone here (or on
networking-discuss) will recognize.
For what it's worth, I was able to use the following trivial dtrace
script to follow a packet all the way from sendto in the kernel down to
the device driver on a Solaris 10 system, and see the MIB updates along
the way. MIB updates provide a fair indication of error activity.
(Note that tracing 'sendto' might not work for all UDP sockets ... if
the socket is connected and uses write(), you won't see any trace
activity.) (Also note that on a busy system, you may need to provide
more conditions on the initial probe [such as checking execname], and
may want to limit the module[s] in which you're tracing.)
#!/usr/sbin/dtrace -Fs -
syscall::sendto:entry
{
self-trace++;
}
fbt:::
/self-trace/
{
}
mib:::
/self-trace/
{
}
syscall::sendto:return
/self-trace/
{
self-trace = 0;
}
--
James Carlson 42.703N 71.076W carls...@workingcode.com
CPU FUNCTION
3 - sendto32
3 - sendto32
3 - sendto
3- sendit
3 - getsonode
3- getf
3 - set_active_fd
3 - set_active_fd
3- getf
3 - getsonode
3 - sotpi_sendmsg
3- sosend_dgram
3 - so_addr_verify
3 - so_addr_verify
3- sosend_dgram
3- sodgram_direct
3 - canput
3 - canput
3 - mcopyinuio
3- allocb_cred
3 - allocb
3- kmem_cache_alloc
3- kmem_cache_alloc
3 - allocb
3 - crhold
3 - crhold
3- allocb_cred
3- uiomove
3- uiomove
3 - mcopyinuio
3 - udp_wput_data
3- UDP_WR
3- UDP_WR
3- udp_output
3 - udp_output_v4
3- mblk_setcred
3- mblk_setcred
3 | udp_output_v4:udpOutDatagrams
3- udp_send_data
3 - crgetlabel
3 - crgetlabel
3 - ire_cache_lookup
3 - ire_cache_lookup
3 | udp_send_data:ipOutRequests
3 - ire_to_ill
3 - ire_to_ill
3 - putnext
3- ce_wput
3 - vlan_set_fast_b_band_q
3 - vlan_set_fast_b_band_q
3 - ce_start
3- WR
3- WR
3- ddi_get_devstate
3- ddi_get_devstate
3- hcksum_retrieve
3- hcksum_retrieve
3- pci_dma_sync
3 - ddi_get_instance
3 - ddi_get_instance
3 - ddi_get_soft_state
3 - ddi_get_soft_state
3- pci_dma_sync
3- pci_dma_sync
3 - ddi_get_instance
3 - ddi_get_instance
3 - ddi_get_soft_state
3 - ddi_get_soft_state
3- pci_dma_sync
3- ddi_check_acc_handle
3- ddi_check_acc_handle
3 - ce_start
3- ce_wput
3 - putnext
3- udp_send_data
3 - udp_output_v4
3- udp_output
3
Re: [dtrace-discuss] general documentation of all dtrace probes
goinsane wrote: Is there a complete overview and documentation of all probes available? I'm wondering about the guys who are using probes like fbt:sockfs:sotpi_accept: and do processing of arguments I've no idea where these are taken from. -( fbt is function based tracing. I'd expect that the 'documentation' of these is essentially the source code itself. For things that are in section 9F of the man pages, the man page should provide adequate documentation. But for things not present there, there's at most a detailed design document available from the original project team that wrote the code, and likely not even that. You might want to review the dtrace stability level information in the tracing guide. -- James Carlson 42.703N 71.076W carls...@workingcode.com ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] general documentation of all dtrace probes
goinsane wrote: fbt is function based tracing. I'd expect that the 'documentation' of these is essentially the source code itself. That's right. A understanding of the source seems essential. Unfortunately I'm feeling lost between thousands of symbols, typedefs and lines of code. Well, at least in the US we've got a long weekend coming. Time to study. ;-} Seriously, though, there are some books that may be helpful. The Magic Garden Explained does a pretty good job of explaining the internals of System V Release 4, which is at least the basis for much of OpenSolaris. There's no substitute, though, for reading the code. One really good way to learn how the code works is to trouble-shoot a problem. You'll be motivated (and forced) to figure out what the code is doing. Another good way to get going is to look at other D scripts that folks have written. You can find quite a few by searching the web (in addition to the ones in /usr/demo/dtrace). If you don't feel that's a good path for you, then you might want to search around for layered tools built on top of dtrace and/or consultants who can help with the task you have at hand. -- James Carlson 42.703N 71.076W carls...@workingcode.com ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] save and recall more than one value of the same thread
goinsane wrote: Hi, I'd like to know if D enables to save and recall values of the same thread in a way like self-... does. Let's say a thread fires syscall::open:entry two times and gets 2 filedescriptors. How could I save those in syscall::open:return for later reuse? The use of just 1 variable (e.g.self-fd) only would overwrite the value at the 2nd call. Maybe an associative array would tend to a solution, like self-fd[port] = ... ? Yep; that's how you'd do it. Note that this might not work quite the way you want for multi-threaded programs that use the same fd in more than one thread. To handle that case (which is a superset of the case you're looking at), I think you'd need a global array indexed on pid and fd, because fds are allocated to a process, not a thread, and D doesn't seem to have a per-process storage mechanism. And how could I evaluate them in a predicate of another probe? self-fd[port] -- where port needs to be the fd. Depending on the definition of the probe and the way you write your code, port might be argv0, or it might be self-port, or perhaps something else. -- James Carlson 42.703N 71.076W carls...@workingcode.com ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] dtrace: no struct definition available
Saadia Fatima wrote: Hi I have been using dtrace script to monitor WiFi frames. For some reason, when I run the script I get the following error: dtrace: failed on compile scriptline 56: operator - can not be applied to a forward declaration: no struct ieee80211_frame definition is avaiable. And this is happening in all the scripts that use this structure. They were running fine previously. I had a few system freeze-reboot cycles in between though. How can I resolve this issue and run them again. That structure isn't normally a packaged part of the system. It's in $SRC/uts/common/sys/net80211_proto.h, which I suppose you could copy from the source tree to any place you want. Or you could try contacting the folks who maintain that file (laptop-disc...@opensolaris.org would be a good choice) and see why it's not normally delivered and whether you could get it to be included. Most likely, your D script depends on an implementation artifact, and this is an early warning that the underlying code you're trying to use may change incompatibly without warning. -- James Carlson 42.703N 71.076W carls...@workingcode.com ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] values from a struct
goinsane wrote:
This becomes interesting. truss shows an ipv6 address for some processes,
like sshd (ipv4 encapsulated in ipv6), although there is no configured ipv6
interface.
909:accept(3, 0x08047A10, 0x08047E78, SOV_DEFAULT) = 4
909:AF_INET6 name = :::172.31.70.6 port = 64625
When the probe fbt:sockfs:accept:return is fired , af_family is set to 26
(INET6) instead of 2 (INET). The return of an ipv6 address seems to be the
reason for the value of 0 of (uint_t)self-sockcont-sin_addr.s_addr . I
still have no glue how the struct sin_addr for ipv6 does look like, if and
how it differs from the original ipv4 one.
Is there a way to find out the structs getting accessed when a probe is fired?
No. The program itself doesn't even know that. That's why sa_family
exists. You're supposed to switch out based on that value.
In a D script, you switch out by having multiple probes with different
conditions.
With the following D I could catch the source ip and port. You're right, I've
to distinguish the endianness. So it won't work on sparc.
What predicate could be used to differentiate between little and big endian?
Do you see a simpler way of the bit operations I'm doing to get the port and
ip?
There are two distinct endian issues here.
On SPARC, the network values (port numbers and addresses) will all be in
the right order, but you have to pay attention to 32/64. I've forgotten
how to do that, but I'm sure there's someone on this list who knows.
On x86, the network values will all be in reverse order, because network
data is big-endian. That means you have to swap it yourself.
I'd recommend having this clause first:
fbt:sockfs:accept:entry
{
self-socklenp = 0;
}
That way, all tests after the first one can be /self-socklenp/ rather
than doing a string compare on execname. It should be a little better
performing.
fbt:sockfs:accept:return
/ self-socklenp execname == tcps.pl /
{
self-socklen = *(int *)copyin(self-socklenp, 4);
self-sockcont = (struct sockaddr_in *)copyin(self-sockaddr,
self-socklen);
That's where I think you're going wrong. You need to copy in the family
first, so something like this:
self-family = *(short *)copyin(self-sockaddr, sizeof (short));
Then just end that clause and start a new one:
fbt:sockfs:accept:return
/self-socklenp self-family == 2/
{
/* this is the AF_INET case */
You can then copy in the full sockaddr_in and drive on.
For AF_INET6, you have to use sockaddr_in6 and sin6_addr. See the
netinet/in.h header file and the inet6(7P) man page.
D trace clauses are like 'if' statements in other languages. You can
have multiple, and they're executed in the order they appear in the file.
--
James Carlson 42.703N 71.076W carls...@workingcode.com
___
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] values from a struct
On 09/17/10 09:34, goinsane wrote:
Yes, you're right, the manpage expresses this, too.
But how to get the value? copyin returns the address of the scratch buffer.
could this be used as argument of the 2nd copyin of fbt:sockfs:accept:return ?
fbt:sockfs:accept:entry
{
self-sockaddr = arg1;
self-socklen = (int*)copyin(arg2, 4);
}
It's an in-out parameter. The value at entry is just the _maximum_ size
of the caller's buffer, and not the _actual_ size of the returned data.
fbt:sockfs:accept:return
{
self-sockcont = (struct sockaddr_in*)copyin(self-sockaddr,
self-socklen);
}
I would do this in the entry clause:
self-sockaddr = arg1;
self-socklenp = arg2;
and then this in the return clause:
self-socklen = *(int *)copyin(self-socklenp, 4);
self-sockcont = (struct sockaddr_in *)copyin(self-sockaddr,
self-socklen);
(This assumes the application is 32-bit or at least that the system is
little-endian. Things get more complicated if you have to deal with
64-bit big-endian systems.)
To be really robust, you could have multiple return causes -- one to get
the return length, another to check it and fetch the contents, still
another to look at the sa_family, and so on.
--
James Carlson 42.703N 71.076W carls...@workingcode.com
___
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] values from a struct
goinsane wrote: (This assumes the application is 32-bit or at least that the system is little-endian. Things get more complicated if you have to deal with 64-bit big-endian systems.) Hm, that's a point I had not noticed yet. I expected the D scripts running independent from the system's arch. But as it becomes more complex, it seems this has to be handled, too. D scripts run in the context of the kernel. If you've got a 64-bit kernel, then your D scripts run as (effectively) 64-bit applications. User-space applications on a 64-bit system, though, may be either 32-bit or 64-bit; the system supports both simultaneously. That's what adds in a bit of complexity. Things running in the kernel (such as D scripts) need to be aware of what flavor of application is out there when they go mucking around with application data structures -- as with copyin. Right now, I'm running at 64 bit i86pc . I'm getting a value of the port (have to verify it), but no value of the ip address. self-port = self-sockcont-sin_port; self-ip_int = (uint_t)self-sockcont-sin_addr.s_addr; Don't forget that the port number will be in network (big-endian) byte order. As for the problem with the IP address, I don't know what could be going on. You might want to try a truss -vall to see if the values you're getting are the ones you're expecting. The alignment of sockaddr_in is such that I'd expect it to work fine over the 32/64 boundary without special handling, so if you're seeing unexpected behavior here, it's time to start dumping everything -- start by printing out the length of the structure that's being copied (perhaps that's wrong) and the first few bytes of the structure to see if it's what you expect. -- James Carlson 42.703N 71.076W carls...@workingcode.com ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] How does DTrace find the proc_t definition?
Rui Paulo wrote:
Hi,
While working on FreeBSD DTrace I came across this problem:
dtrace: failed to compile script callout.d: /usr/lib/dtrace/psinfo.d, line
53: operator - cannot be applied to a forward declaration: no struct proc
definition is available
psinfo.d is FreeBSD specific (we don't rely on procfs). Line 53 is:
translator psinfo_t struct proc *T {
..
The error message is clear, but the way to fix it isn't clear to me right now.
How does Solaris DTrace find the 'proc_t' struct in /usr/lib/dtrace/procfs.d
?
It gets it from the kernel's symbol table using CTF.
--
James Carlson 42.703N 71.076W carls...@workingcode.com
___
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] tcptop and tcpsnoop
Charles Meo wrote: Apologies definitely not needed. I think everyone appreciates the massive amount of work involved and it's hardly your fault that S'noracle has shall we say lost focus over the last few months, and not just on engineering issues. I work for a Sun partner and the ride has been bumpy to say the least. Things seem to be improving across the board though. Uh, no, it's not that sort of thing. It's great that Brendan Gregg is offering to clean up the scripts that exist, and I wish him luck in tracking down all the patch levels required to do that, but the truth is that the scripts were originally written to use internal interfaces that are _intentionally_ not stable. That internal interfaces are not stable has been true since the beginning of time and is still true now for those same interfaces in OpenSolaris. What's actually changed in OpenSolaris is that *NEW* stable interfaces were introduced on which scripts like those could safely be (re)written. It just was not safe to write those scripts before there were stable interfaces that could be used, and that lack of safety is what's showing up. Blaming the problem on a lack of focus or something having to do with Oracle is to completely miss the point. The problem was an inappropriate (albeit unavoidable) reliance on undocumented implementation artifacts, and the issues you experienced are the unavoidable outcome of that sort of design. This sort of problem has happened many times in the past, and will almost certainly happen many times again in the future. As long as there are folks writing independently delivered and maintained software that depends on undocumented and unstable interfaces, you're going to have field breakage and unhappy users. For what it's worth, that's exactly why Sun has run an architecture review board for 20 years, and why Oracle continues to do so. -- James Carlson 42.703N 71.076W carls...@workingcode.com ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] tcptop and tcpsnoop
Charles Meo wrote: Thanks Peter, but nearly everyone in customerland is using commercial Solaris and that's the answer I really need... I'll just have to wing it in the meantime. On Solaris 10, those dtrace scripts are built on top of unstable implementation artifacts, which means that they can (and do) break when patches are released. And, unfortunately, the folks maintaining the kernel bits aren't necessarily the same ones maintaining the dtrace examples. So breakage of the sort you've seen is unfortunately common. Since you're talking about S10 rather than OpenSolaris, your best bet is to contact either the dtrace toolkit's author or Oracle's customer support group for help. It's not that S10 is unknown on these OpenSolaris lists, but so much has changed since then that discussion here is sometimes less than helpful. -- James Carlson 42.703N 71.076W carls...@workingcode.com ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] Need some help
On 03/15/10 08:20, tester wrote:
fbt::door_call:entry
/curpsinfo-pr_dmodel == PR_MODEL_LP64/
{
printf(entry args are %lx and %lx \n, arg0,
, *(uint64_t *)copyin(arg1, 8));
}
Nico
Thanks Nico. Since arg1 is a pointer to a struct in userland, can I use
ptr = *(uint32_t *)copyin(arg1, 4);
tracemem(ptr,10);
to dump the structure. I tried this and getting invalid address (0xfb07bc75)
in action #4.
If arg1 is a userland pointer to a structure, then your copyin just
copied in the first four bytes of that structure. And your tracemem is
trying to use those first four bytes as though they were a kernel
pointer. That's not going to work.
You might want this:
this-ptr = copyin(arg1, 10);
tracemem(this-ptr, 10);
--
James Carlson 42.703N 71.076W carls...@workingcode.com
___
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] Replacing libumem's debug with dtrace?
Pierre-Olivier Gaillard wrote: So I was hoping to get into mdb after the crash and retrieve the above information but libumem runs out of memory before the problem occurs. I suppose that libumem's debug features have a big memory overhead but I could not figure out what to disable to avoid running out of memory before I can reproduce my problem. One option would be to recompile as a 64-bit application, so you have fewer limits to worry about. If you suspect a double free (or at least a use-after-free), and you can't use libumem, one possible technique is to use the object itself to gather debug information. Change your object free function so that, before calling free(), it writes some recognizable pattern to the object (modifying some oft-used pointer inside the structure to NULL is usually a good bet), and then use the backtrace() function to store a backtrace into any remaining space inside the object. Something like this (assuming a large-enough object): void **optr = (void **)obj; assert(sizeof (*obj) = 10 * sizeof (*optr)); assert(optr[0] != NULL optr[1] != (void *)0x12345678); optr[0] = NULL; optr[1] = (void *)0x12345678; /* a pattern to recognize */ backtrace(optr + 2, sizeof (*obj) / sizeof (*optr) - 2); That way, when you dump, you'll be able to see where the first free came from. -- James Carlson 42.703N 71.076W carls...@workingcode.com ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] new dtrace toolkit?
Brendan Gregg - Sun Microsystems wrote: On Mon, Mar 08, 2010 at 04:07:23PM -0800, Otto P. wrote: New to opensolaris and dtrace. I'm interested in the network scripts but I find that many don't work. Should my expectations be low right now? Only for networking, which is probably the most difficult area to start with. There is work underway for a stable DTrace TCP network provider; until that exists, any scripts written based on the unstable fbt provider tend to break from release to release, such as the tcpsnoop/tcptop scripts. This will get a lot better, but we aren't there yet. There are quite a lot more TCP scripts I would like to write and add to the DTraceToolkit, but I've held back until the stable provider is available, otherwise it could just annoy people more. I agree that networking has some difficult problems compared with other areas, but I don't think that's the only problem here. If folks actually want to rely on these scripts, perhaps they ought to be tested regularly, made the subject of integration requirements (so that others modifying the stack are required to update them), and even moved out of /usr/demo. That which isn't tested doesn't work. -- James Carlson 42.703N 71.076W carls...@workingcode.com ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] fire probe when parent is foo
Jonathan Adams writes: Always predicate this with '/self-flag/', or threads which are currently in 'foo' when tracing is started will trace all activity after it returns. Yep; noted by meem as well. Sorry about that omission. -- James Carlson, Solaris Networking james.d.carl...@sun.com Sun Microsystems / 35 Network Drive71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] fire probe when parent is foo
rickey c weisner writes:
In the kernel.
I am executing in function foo.
foo calls putnext.
I want a predicate that allows my
fbt::putnext:entry
to fire only when the parent is foo.
Any suggestions ?
fbt::foo:entry
{
self-flag++;
}
fbt::putnext:entry
/self-flag/
{
printf(hi there);
}
fbt::foo:return
{
self-flag--;
}
--
James Carlson, Solaris Networking james.d.carl...@sun.com
Sun Microsystems / 35 Network Drive71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
___
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] TCP provider
vattini giacomo writes:
Hi there sorry about my ignorance,reading the NETWORK dtrace provider i tried
some oneliners scripts,
but i think is not working on my System
$name -a=SunOS opensolaris 5.11 snv_101b i86pc i386 i86pc Solaris
dtrace -n 'tcp:::receive { @[args[2]-ip_saddr] = count(); }'
running this command i do not have any response, as
dtrace: invalid probe specifier tcp:::receive { @[args[2]-ip_saddr] =
count(); }: probe description tcp:::receive does not match any probes
any clue?
It's a little tough, but this will do roughly the same job:
dtrace -n 'ip:::receive/args[2]-ip_ver==4args[4]-ipv4_protocol==6/ {
@[args[2]-ip_saddr] = count(); }'
You might also want to look at the tcp-trace-* sdts; see
/usr/demo/dtrace/tcprst.d.
--
James Carlson, Solaris Networking james.d.carl...@sun.com
Sun Microsystems / 35 Network Drive71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
___
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] dtrace at startup
Mike Gerdts writes: http://alexeremin.blogspot.com/2009/01/boot-chart-with-help-of-dtrace-and.html http://www.milax.org/img/pybootchart.png Wow. gdmgreeter sure sticks out there. -- James Carlson, Solaris Networking james.d.carl...@sun.com Sun Microsystems / 35 Network Drive71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] no Dtrace hooks for monitoring ddi put/get
J writes: There doesn't seem to be any Dtrace hooks for monitoring ddi put/get. I think this would be a great feature for developers as they would be able to monitor hardware access at the register level. Is there any reason why these hooks do not exist already? (bofi is not really suitable because it requires that the driver is taken off-line) This is CR 4969919. Yes, it's extremely annoying when debugging drivers, and the RE has suggested that it be closed as will not fix. -- James Carlson, Solaris Networking james.d.carl...@sun.com Sun Microsystems / 35 Network Drive71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] Just like WindView
Matthew Bromley-Barratt writes: Thanks for the various replies I've had. Not been able to get on to a solaris box for various reasons so I've not been able to pursue anything yet. Will do so soonest. From what I've seen dtrace seems to be about measuring programme metrics without adding anything to the programme's source code. However, I don't mind instrumenting my own application. Windview works by letting you place calls to a function wvevent(unique_id) which results in unique_id appearing as a unique event in that thread's timeline. It is very useful indeed! That'd be DTRACE_PROBE() in dtrace. See: http://wikis.sun.com/display/DTrace/Statically+Defined+Tracing+for+User+Applications -- James Carlson, Solaris Networking james.d.carl...@sun.com Sun Microsystems / 35 Network Drive71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] lsof vs Dtrace
Nicolas Williams writes: But the point is that kmdb scripting and lsof are on the same footing. Yes, it's exactly the same thing by slightly different means. The difference, and it's not much, is that a user of mdb looking at the kernel likely knows that unless the target is stopped (as with mdb -K), the data structures are volatile, and that the contents of most of the structures is undocumented territory, so you need to have cscope open in another window while you try this trick. The user of 'lsof', on the other hand, is likely an administrator who believes he's getting the truth about what his system is actually doing. Unfortunately, that faith is at least a little misplaced due to the nature of reading from live kernel memory. -- James Carlson, Solaris Networking james.d.carl...@sun.com Sun Microsystems / 35 Network Drive71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] Show file descriptors returned by pipe()
Beat Vontobel writes: Hi James, thanx for your quick reply! printf(pipe(%d, %d) in %s\n, arg0 0x, arg0 32, Unfortunately, the higher 32 bits are always 0 for me with this approach, even though the lower 32 bits correctly hold the first of the two file descriptors. Sounds like a 32-bit kernel. In that case, try using arg0 and arg1. Did Apple maybe break something when they integrated your code into OS X? :) (I know they broke some other stuff in dtrace, some of it intentionally... :) ) I don't think so. The issue here is that syscall itself exposes kernel implementation details, so it's highly dependent on how your system is put together. Check out: http://wikis.sun.com/display/DTrace/Stability and try this: dtrace -ev -n syscall::pipe:return -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 35 Network Drive71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] DTrace Analytics open source?
frank gleason writes: Analytics by itself does not sell the 7000 series, it's the integration that does. Analytics could sell a lot of production systems since it finally allows more than two eyeballs to look at dtrace. Fishworks created value by taking a lot of great technology and integrating it. Creating value from the pieces. Pieces of technology created for the 7000 should be given back. Thinking Analytics is the secret sauce to beat the storage competitors is wrong, the secret sauce is Sun itself and the value that has been created was built on a great collection of technologies that where made available so others could build on them. You could be right, but I don't think this is really the right forum to debate Sun's (or really anyone's) marketing choices. It's unlikely to change things. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 35 Network Drive71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] Parameters TCP
Wesley Naves de faira writes:
Hi,
I need tunning my Solaris 10 8/07 with the following parameter
using ndd -set
tcp_conn_req_max_q0
tcp_conn_req_max_q
There are some probe to view this and other parameters the stack
TCP ? I saw that in OpenSolaris have probe tcp, but in Solaris no. How
can i do this ?
I think we'll need more information about what you're trying to
accomplish in order to provide a complete answer, but these functions
are called for those parameters when getting and setting /dev/tcp via
ndd:
tcp_param_get
tcp_param_set
The function arguments are visible in the source code, and it'd be
best to refer to that when writing such a script, but here's a start:
#!/usr/sbin/dtrace -qs -
fbt:ip:tcp_param_get:entry
{
self-tcppa = (tcpparam_t *)arg2;
}
fbt:ip:tcp_param_get:entry
/self-tcppa-tcp_param_name == tcp_conn_req_max_q0 ||
self-tcppa-tcp_param_name == tcp_conn_req_max_q/
{
printf(get %s: %d\n, stringof(self-tcppa-tcp_param_name),
self-tcppa-tcp_param_val);
}
fbt:ip:tcp_param_set:entry
{
self-tcppa = (tcpparam_t *)arg3;
}
fbt:ip:tcp_param_set:entry
/self-tcppa-tcp_param_name == tcp_conn_req_max_q0 ||
self-tcppa-tcp_param_name == tcp_conn_req_max_q/
{
printf(set %s: from %d to %s\n,
stringof(self-tcppa-tcp_param_name),
self-tcppa-tcp_param_val, stringof(arg2));
}
--
James Carlson, Solaris Networking [EMAIL PROTECTED]
Sun Microsystems / 35 Network Drive71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
___
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] Silly error messages.
Brian Utterback writes: So, two comments: 1. This is a case where a more general error message would probably have been more helpful than the more specific ones. True. 2. Why can't they be combined? If the data recording actions are not after a speculate, I don't even see how they are related. I could see if the commit went off into some other part of the dtrace code and the rest of the actions were not executed that having the commit be first would be a problem, but then a commit at the end should work. What is the reasoning here? I think dtrace is exposing a little internal architecture here. A rule that does a commit() has special properties because it needs to synchronize where those just printing into a speculation do not. You can only commit once, no matter how many CPUs there are. It's simple to work around, though. Just copy the clause into two pieces. Delete the commit(...); from the first one, and the speculate(...); and printing from the second. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 35 Network Drive71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] dtrace_probe#() disassembly
Rafael Vanoni writes: I was looking at some assembly on mdb and noticed that calls to DTRACE_PROBE1() were seen as ~5 nops. Could anyone explain me why's that ? That's where the probes are patched in at run time. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 35 Network Drive71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] mblk chains?
Andrew Gallatin writes:
Is it possible to write a dtrace script which can tell me the number of
mblks, and total chain length, upon entry to a function (gldv3 nic driver's
xmit function). I naively tried to iterate over mp-b_cont, but there is no
while or for in dtrace..
Dtrace intentionally doesn't have looping -- for safety reasons.
Eg, what I want to do is:
for (pkt_size=0, count=0,bp = mp; bp != NULL; bp = bp-b_cont) {
You could do something like this:
fbt:mymodule:myfunc:entry
/arg1 != 0/
{
this-mp = (mblk_t *)arg1;
this-size = this-mp-b_wptr - this-mp-b_rptr;
}
fbt:mymodule:myfunc:entry
/this-mp this-mp-b_cont/
{
this-mp2 = this-mp-b_cont;
this-size += this-mp2-b_wptr - this-mp2-b_rptr;
}
fbt:mymodule:myfunc:entry
/this-mp2 this-mp2-b_cont/
{
this-mp3 = this-mp2-b_cont;
this-size += this-mp3-b_wptr - this-mp3-b_rptr;
}
and repeat a few times to catch as many cases as you feel is
necessary. (Perhaps add an assertion at the end to make sure you run
out of b_conts in all of the cases of interest.)
--
James Carlson, Solaris Networking [EMAIL PROTECTED]
Sun Microsystems / 35 Network Drive71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
___
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] mblk chains?
Andrew Gallatin writes: Thanks! That seems to work. That's cool. I didn't even test it. ;-} FWIW, recursion also seems to work. Eg: I don't see the recursion here. Those two probe points will fire sequentially. The second one will _not_ loop, so what you've created with those two entries is something that'll handle chains of length 1 and 2, but nothing longer. (Note that it's customary to check for the first M_DATA message in the chain before counting up bytes, and I didn't do that ...) -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 35 Network Drive71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] mblk chains?
Andrew Gallatin writes: OK, so recursion does not work, and the probe will fire only once. Drat. I'll just have to put up with a script that looks like something I'd have flunked as a CS1 TA.. But if the language doesn't support it, I guess there's not much to do. The thing to remember is that it's intentional. The TA who passed remembers that the halting problem is undecidable (and also NP-hard but not NP-complete), and therefore it's not possible to know whether a given D script (a program) containing loops would be safe (would ever halt). Since one of the fundamental rules of dtrace is that it's safe to use, scripts that run forever cannot be allowed. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 35 Network Drive71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] What is wrong with this code?
Christophe Kalt writes:
syscall::connect:entry
{
self-to = (char *) copyin(arg1, arg2);
self-ftp = ( self-to[0] == 0 self-to[1] == 2 self-to[3] == 21 ) ?
1 : 0;
Is this on SPARC or x86? That expression is sensitive to byte order:
it's assuming that sin_family is going to be in big-endian order,
which is true only on SPARC.
(The port number in struct sockaddr_in is always big-endian, because
it's in network byte order.)
Not testing self-to[2] for zero seems odd.
In the printf, self-to contents aren't always what they were when the
variable was assigned. Why not?
Good question ... for which I don't have an answer. But for what it's
worth, I always copy the information I want to save across probe
clauses into scalars in 'self-'. I don't really trust pointers here.
--
James Carlson, Solaris Networking [EMAIL PROTECTED]
Sun Microsystems / 35 Network Drive71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
___
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] can i use if/else/for/while in dtrace script?
Roman Shaposhnik writes:
fbt:foo:bar:entry
/arg0 == 1234/
{
trace(arg1);
self-test = arg2;
Am I missing something or would this-test be more appropriate in
this case?
self is local to the thread executing, and thus crosses the
boundaries between the separate probe points. this is local to a
single probe clause.
this-test wouldn't work here.
--
James Carlson, Solaris Networking [EMAIL PROTECTED]
Sun Microsystems / 35 Network Drive71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
___
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] can i use if/else/for/while in dtrace script?
Roman Shaposhnik writes: On Wed, 2008-06-04 at 14:06 -0400, James Carlson wrote: self is local to the thread executing, and thus crosses the boundaries between the separate probe points. this is local to a single probe clause. this-test wouldn't work here. That's why I asked. And based one the quote from Adam's blog -- your interpretation is NOT what I believe probe-local variables do: http://blogs.sun.com/ahl/entry/pid2proc_for_dtrace: [...] Thanks; I wasn't aware that 'this' would span distinct clauses as long as the probe point itself remains the same. That's surprising and useful. ;-} -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 35 Network Drive71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] Capability of memory overwritten detection
Mitsuhiro Nakamura writes: Thanks lots for all information!! We are indeed provide API to the certain customer and they have a problem at the their production. We are not able to reproduce the problem at our local test environment. And customer want neither to use debugger nor to accept rebuild(for debugging) on the production. Therefore, I will prefer to try Vladimirs suggested dtrace procedure (attached mail) or mdb. However, I am still missing for DABR register on Power PC. Access to the hardware debug features is exactly what the proc(4) interfaces give you. (And what the debuggers use.) I don't think you're missing much here, though I agree that some of the PPC family members have some *really* slick debug features. (The 860 family comes to mind ...) I have general question here! How do you manage this kind of problem at the customer site? I have worked many years for developing of hard and soft ware. It is often very difficult situation if the problem is concerning on a interaction between the application and API. Surely, it is nice to have a good relationship, such customer/user as partner. However, it is not often the case. Therefore, we must often pinpoint what is fault, like show the stack-chain in this case. Sorry this kind of discussion does not belong to this mail-list, but I am very curious!! It depends. As you note, some customers are interested in getting rapid and accurate support, and are thus very good about allowing for test runs and debug to get at the root of an issue. Other customers clearly are not -- they sometimes demand that we magically fix a problem without knowing exactly what it is. There are a huge number of techniques available -- probably too many to name here. A few I've seen and/or used: - Event logs: just keep a static buffer around in memory to record whatever events you feel are significant in your application. If the application crashes, the core file (or system dump, if it's a kernel module) will have that buffer and may provide some clues. - Good ol' printf: sending messages to syslog or to a text log file of some sort can be helpful. It gives you more room and flexibility than the typical circular event log, but costs a lot more in performance. - Assertions: not just assert(3C), but deliberate self-checks in the code (verifying the integrity of data structures, and making sure that invariants are in fact true) can help isolate problems and prove that certain parts of a large complex system are not the source of the fault. - Intentional damage: deliberately change some part of the system so that it either fails intermittently (e.g., make malloc return NULL every now and then), or perhaps so it fails completely (e.g., insert a packet filter that drops all application data), or so that the timing changes (e.g., insert a delay loop in the middle of some block of code that's running without locks and that you suspect looks like a timing hole). It is sometimes possible to reproduce (and diagnose) customer problems by making things worse. - Impromptu code review: sometimes, a hard-to-fix bug is just the computer's way of saying that perhaps right now would be a good time to stop everyone's work, print out the code on paper, and go through it line-by-line looking for problems. - Staring at a core dump until your eyes bleed: the usual way to deal with problems at a recalcitrant customer site. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 35 Network Drive71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] Invalid address in action
prasad writes: Now with this: printf(%Y: , walltimestamp); this-text = copyinstr(self-bufp,self-size); printf(%s(PID:%d) called %s with fd=%d, size= %d, and \nbuf=\%s\\n\n, execname, pid, probefunc, self-fd, self-size, this-text); I am getting this: 2008 Feb 22 14:30:00: dataPump(PID:6658) called aiowrite with fd=8, size= 204, and buf= why am I getting nothing in the buffers? At a guess, the first byte in the buffer is zero. A zero (ASCII NUL) byte is a C string terminator, so %s doesn't print anything else. (Wasn't that also what you were seeing the last time you posted ... ?) -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 35 Network Drive71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] Missing syscall provider probes for unlinkat(2) and friends?
Peter Memishian writes: The problem is really in the distinction between section two of the man pages (the historical system call interface) and the real OpenSolaris system call interface that dtrace exposes as syscall. Dtrace syscall isn't the same thing as man page section two, as the former is an undocumented implementation detail and the latter is a standard interface. Precisely. Seems like an RFE is warranted to allow the system call names in our manpages to be used. This would eliminate both (a) the current surprise and confusion, and (b) the dependency on the system call implementation details (which are inherently unstable). Another nice side effect would be that the stability level of the probe could match the stability level given in the section two manpage. I mostly agree with that ... I just think that effort is what Adam was referring to as putting lipstick on a pig. My understanding of the rationale is that it's better to have access to a raw, undoctored syscall interface when you really need it, than to have a prettified interface that might not let you see all the details when you want to. In other words, a better answer might be to create an abi provider that maps into the stable programming interface, and leave syscall alone. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 35 Network Drive71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] Missing syscall provider probes for unlinkat(2) and friends?
Nicolas Williams writes: On Mon, Feb 04, 2008 at 05:44:05PM +0100, Joerg Schilling wrote: Nicolas Williams [EMAIL PROTECTED] wrote: This pig isn't very attractive. Is a system call number shortage the underlying problem? And is the fix to this ultimately about fixing the syscall number shortage? grouping several syscalls under a single entry is nothting new. I am aware. However, I think, e.g., unlinkat(2) should be just like unlink(2), from a DTrace syscall provider p.o.v. Adam called this a pig for a reason; I agree with that characterization. The problem is really in the distinction between section two of the man pages (the historical system call interface) and the real OpenSolaris system call interface that dtrace exposes as syscall. Dtrace syscall isn't the same thing as man page section two, as the former is an undocumented implementation detail and the latter is a standard interface. I agree that it'd be nice to throw a few bones at the poor user when he does something obvious and still wrong, but I agree that it's just a pig. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 35 Network Drive71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] ARC case for Contract 'decoration' with service FMRI
Antonello Cruz writes: Creator Auxiliary: This term allows a particular creator to further describe the purpose of a contract. In general, the values of this term are undefined by this case; it is up to individual creators to create and follow conventions. For example, svc.startd could (and will, see below) use this field to store the method name. More generally, is this expected to be an arbitrary text string defined by the creator of the contract? If so, then I think some advice about (or perhaps restrictions on) character sets and languages used might be needed. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 35 Network Drive71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] Getting total memory allocated so far
Lally Singh writes: I'd like to track to total amount of memory the application's actually using right now. More specifically, I guess these rules would do it: 1. start at M=0 2. for each call to malloc(): set M += size of block returned by malloc 3. for each call to free(): set M -= size of block freed. Using env LD_PRELOAD=libumem.so myapp with mdb's umem support should get you that (plus quite a bit more). -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 35 Network Drive71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] Aggregations and negative values
Alexander Kolbasov writes: Filed 6624541 dtrace aggregations should assume signed arguments Perhaps a silly question ... but why not just follow the signedness of the argument provided? If the user provides an unsigned data type to the aggregation, then do unsigned arithmetic on it. If he provides a signed type, do signed arithmetic. (Just like the Fortran intrinsic functions. ;-}) -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 35 Network Drive71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] Aggregations and negative values
Alexander Kolbasov writes: Alexander Kolbasov writes: Filed 6624541 dtrace aggregations should assume signed arguments Perhaps a silly question ... but why not just follow the signedness of the argument provided? If the user provides an unsigned data type to the aggregation, then do unsigned arithmetic on it. If he provides a signed type, do signed arithmetic. This would be nice, but I don't know whether DTrace framework allows passing argument types to aggregation functions. I'm not sure I understand. If I say this: @foo[execname] = sum(bar); Doesn't 'bar' have some type, at least by default? I had thought that dtrace tracked types dynamically. It seems to do so when I cast a value and assign it to self-blah. It also seems to keep track of types if I try to pass in something that can't work. Why doesn't the expression have a type? -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 35 Network Drive71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] Capture of loopback interface messages
Pierre-Olivier Gaillard writes: That's a coincidence. This morning I tried to do snoop -d lo0 and it wouldn't work. Is it really impossible to just snoop on loopback as you would on Linux with wireshark or tcpdump ? Yes. That's why this feature is being added by the Clearview project. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
