An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/dtrace-discuss/attachments/20080425/07667b4a/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: left Type: image/gif Size: 2548 bytes Desc: not available URL: <http://mail.opensolaris.org/pipermail/dtrace-discuss/attachments/20080425/07667b4a/attachment.gif> -------------- next part -------------- A non-text attachment was scrubbed... Name: bottom Type: image/gif Size: 1557 bytes Desc: not available URL: <http://mail.opensolaris.org/pipermail/dtrace-discuss/attachments/20080425/07667b4a/attachment-0001.gif> -------------- next part -------------- A non-text attachment was scrubbed... Name: wan_sam.vcf Type: text/x-vcard Size: 166 bytes Desc: not available URL: <http://mail.opensolaris.org/pipermail/dtrace-discuss/attachments/20080425/07667b4a/attachment.vcf>
> I''m learning translators recently and find some problems which > make me confused.You''re something of a pioneer ;-)> Question# 1: > [snip] > Why do we define translator of psinfo_t for 2 times in this > way? Could someone give the detailed explanation.The input types are different; one takes a proc_t, and the other takes a kthread_t.> Question# 2: > > I wrote a small script to print out the session''s credential > information of running processes as below: > [snip] > I ran this script in a x86 vmware Solaris 10 8/07 server > and login to it using ssh, then I got below messages: > ------------------ > root at solaris1 # ./sesscred.d > dtrace: error on enabled probe ID 2 (ID 45960: > syscall::exece:return): invalid address (0x4) in action #1 at DIF > offset 64 > [snip] > > I searched dtrace discuss list and found that > all similiar cases of error ''invalid address .. in action .. at DIF > offset ...'' are related to accessing not faulted in pages. But here > the proc and thread information should have already been in kernel > memory, why does this error occur still?cr_uid is at offset 4. The problem you''re seeing is that p_sessp- >s_cred is NULL. I suggest you use p_cred instead. You may be able to debug problems like this by explicitly expanding the translator and checking each pointer value along the way. Adam -- Adam Leventhal, Fishworks http://blogs.sun.com/ahl
An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/dtrace-discuss/attachments/20080425/90c1bc47/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: left Type: image/gif Size: 2548 bytes Desc: not available URL: <http://mail.opensolaris.org/pipermail/dtrace-discuss/attachments/20080425/90c1bc47/attachment.gif> -------------- next part -------------- A non-text attachment was scrubbed... Name: bottom Type: image/gif Size: 1557 bytes Desc: not available URL: <http://mail.opensolaris.org/pipermail/dtrace-discuss/attachments/20080425/90c1bc47/attachment-0001.gif> -------------- next part -------------- A non-text attachment was scrubbed... Name: wan_sam.vcf Type: text/x-vcard Size: 166 bytes Desc: not available URL: <http://mail.opensolaris.org/pipermail/dtrace-discuss/attachments/20080425/90c1bc47/attachment.vcf>
>> The input types are different; one takes a proc_t, and the other takes >> a kthread_t. >> > Q: I know that the input types are different, but my point is why we > use 2 different input types to translate for the same psinfo_t? Why > just only one? What''s the purpose?So that we can translate for SDT probes that have different arguments.>> cr_uid is at offset 4. The problem you''re seeing is that p_sessp- >> >s_cred is NULL. I suggest you use p_cred instead. >> > Q: I guessed that p_sessp->s_cred might be NULL but I''m not willing to > believe itIt''s easily verified: # dtrace -n ''syscall::exec:return,syscall::exece:return{ @[curthread->t_procp->p_sessp->s_cred == NULL] = count(); }'' dtrace: description ''syscall::exec:return,syscall::exece:return'' matched 2 probes ^C 1 227 0 307 Adam