[dtrace-discuss] Auditing file modification
Hi all.I am new to Dtrace scripting.My problem is that i have a file in my application that i want to monitor.I want to perform a backup of the file every time the file is modified.I want the names of the backup files to have timestamp so that i can track the changes to original file based on time.Anyhelp will be highly appreciated. Regards Wambugu ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] Using DTrace on Kernel Extensions in OS X
On Mar 22, 2008, at 7:33 AM, Kathleen wrote: I am currently working with the ZFS port to OS X which is a kext. I had heard that you cannot use DTrace on kexts in OS X at the moment. Does anyone know why? The dog ate that code. Kexts are SO nineties, we think they're going away. The Brady-Barr kext control act of 2007 required us not to ship that code by law. It's a GPL v4 licensing issue. Or, possibly we just didn't get that functionality implemented yet :-). James M ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
[dtrace-discuss] Iterating over all LWPs
Hi! Here's the problem I'm facing: I need to sample a particular attribute of all the LWPs in a given process. Now, sampling itself is no problem -- I can use profile/tick provider and all is good. The problem is: I can't seem to think of a DTrace-friendly way to iterate over all the LWPs and report the value of the attribute I'm interested in. Any suggestions? Thanks, Roman. ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] Iterating over all LWPs
On Mon, Mar 24, 2008 at 10:35:43AM -0700, Roman Shaposhnik wrote: Any suggestions? Either don't use DTrace if you need to iterate, or start the target via DTrace so you can keep track of all the LWPs in your D script. ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] Iterating over all LWPs
What I meant by the don't use DTrace if you need to iterate option is this: try using MDB. Given what you say you might find it a lot easier to sample the items you need via MDB. ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] stack tracing and uregs[]
Can you send the DTrace invocation that you're using, please?
Adam
On Sun, Mar 23, 2008 at 09:16:25PM -0700, bryan wrote:
I'm doing research into stack monitoring and have made a simple server that
has the following method:
int handle_reply(char *str){
char response[256];
strcpy(response,str);
printf(The client says \%s\\n,response);
return 0;
}
I'm overflowing this with 300 bytes of the letter 'A'. I'm verifying with
gdb that the eip register contains the hex value for 'A' (0x41) but when i
print out the value of eip in dtrace with uregs[R_EIP] on function return, it
is still the original return address, not 0x41414141. The program is seg
faulting so i know the eip is being overwritten but obviously i'm not using
dtrace correctly in this case. I'm under the impression that uregs[] holds
the values of the registers on the stack for the pocess it is instrumenting.
I'm not exactly sure of how dtrace is implemented but i'm thinking dtrace
should be copying the value of the eip register into a local buffer when the
above function returns and therefore should have the value 0x41414141 since
it has already been overwritten with that value. Dtrace does return the value
0x41414141 for the ebp register though, which is what i expected. Should the
value of uregs[R_EIP] not also be 0x41414141?
Any help on this would be appreciated.
--
This message posted from opensolaris.org
___
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
--
Adam Leventhal, Fishworkshttp://blogs.sun.com/ahl
___
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] process snoop (shellsnoop for arbitrary application)
Is there any way to get client pid from a client id? client-auth is the only probe that has client pid as an argument, but this probe is missing from in my OpenSolaris. Also, I need hints about how to get the client id of the process having the keyboard focus. Please help. Thanks! -- This message posted from opensolaris.org ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] stack tracing and uregs[]
Here is the latest script that I used just so i could see the values at both
entry and
return for both handle_reply and strcpy:
-
#!/usr/sbin/dtrace -s
pid$1::handle_reply:entry
{
printf(\nEBP=%x EIP=%x\n, uregs[R_EBP], uregs[R_EIP]);
}
pid$1::strcpy:entry
{
printf(\nEBP=%x EIP=%x\n, uregs[R_EBP], uregs[R_EIP]);
}
pid$1::strcpy:return
{
printf(\nEBP=%x EIP=%x\n, uregs[R_EBP], uregs[R_EIP]);
}
pid$1::handle_reply:return
{
printf(\nEBP%x EIP=%x\n, uregs[R_EBP], uregs[R_EIP]);
}
---
I literally just ran the script below though and i'm getting both registers
showing 0x41414141:
--
#!/usr/sbin/dtrace -s
fbt::strcpy:return
/ pid == $1 /
{
printf(Buffer overflow: eip=%x ebp=%x\n, uregs[R_EIP], uregs[R_EBP]);
}
-
with this output:
CPU IDFUNCTION:NAME
1 22691strcpy:return Buffer overflow: eip=fedc5b35
ebp=8045f4c
0 22691strcpy:return Buffer overflow: eip=41414141
ebp=41414141
0 22691strcpy:return Buffer overflow: eip=41414141
ebp=41414141
0 22691strcpy:return Buffer overflow: eip=41414141
ebp=41414141
0 22691strcpy:return Buffer overflow: eip=41414141
ebp=41414141
^C
Though i'm a little confused on this output, especially the first line and the
multiple outputs for a program that seg faulted. I've been focusing on the pid
provider too much i guess, I would still like to know what i'm doing wrong on
the pid provider or what the difference is as to why it doesn't report the same
back. Thanks for the time and help.
--
This message posted from opensolaris.org
___
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
