Gangadhar Mylapurm
2006-Sep-21 09:02 UTC
[dtrace-discuss] Dtrace script compilation error.
Hi All, One of the customer is seeing the following error messages. He is using a S10U1 system with all latest patches. Dtrace script is attached. I am not seeing these error messages on S10U2 system. What could be the problem? Thanks, Gangadhar. ------------------------------------------------------------------------ rroberto at njengsunu60-2:~$ dtrace -AFs /lib/svc/share/kcfd.d dtrace: failed to compile script /lib/svc/share/kcfd.d: line 26: args[ ] may not be referenced because probe description ::crypto_register_provider:entry matches an unstable set of probes rroberto at njengsunu60-2:~$ dtrace -AFs /lib/svc/share/kcfd.d dtrace: failed to compile script /lib/svc/share/kcfd.d: line 26: args[ ] may not be referenced because probe description ::crypto_register_provider:entry matches an unstable set of probes It was reporting this: dtrace: cleaned up old anonymous enabling in /kernel/drv/dtrace.conf dtrace: cleaned up forceload directives in /etc/system dtrace: saved anonymous enabling in /kernel/drv/dtrace.conf dtrace: added forceload directives to /etc/system dtrace: run update_drv(1M) or reboot to enable changes But now just reports the above. Rebooting can sometimes get it to run one time, but never twice ... ------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: <mail.opensolaris.org/pipermail/dtrace-discuss/attachments/20060921/69a1bfb8/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: crypto.d Type: text/x-dsrc Size: 1273 bytes Desc: not available URL: <mail.opensolaris.org/pipermail/dtrace-discuss/attachments/20060921/69a1bfb8/attachment.bin>
Gangadhar, The usual cause for this error message is when more than one probe matches a probe specification where the probe clause uses the "args" array. Since the type of args elements can be different for each probe, the D compiler doesn''t know what to do with the type when the probe spec matches more than one probe. Clearly, "crypto_register_provider:entry" (line 26 appears to be within this probe clause) should only be matching one probe. However, you did say that rebooting can sometimes get it to run once. Perhaps the system is eventually loading another provider with the same probe function name, as strange as that sounds. You might have them try fully qualifying the probe specification (on my system, I''m seeing the name as "fbt:kcf:crypto_register_provider:entry") Barring that, a work around is to use the builtin integer arg0, and cast it. Chip Gangadhar Mylapurm wrote:> Hi All, > > One of the customer is seeing the following error messages. > He is using a S10U1 system with all latest patches. > Dtrace script is attached. > > I am not seeing these error messages on S10U2 system. > > What could be the problem? > > Thanks, > Gangadhar. > ------------------------------------------------------------------------ > rroberto at njengsunu60-2:~$ dtrace -AFs /lib/svc/share/kcfd.d > dtrace: failed to compile script /lib/svc/share/kcfd.d: line 26: args[ ] > may not be referenced because probe description > ::crypto_register_provider:entry matches an unstable set of probes > rroberto at njengsunu60-2:~$ dtrace -AFs /lib/svc/share/kcfd.d > dtrace: failed to compile script /lib/svc/share/kcfd.d: line 26: args[ ] > may not be referenced because probe description > ::crypto_register_provider:entry matches an unstable set of probes > > It was reporting this: > > dtrace: cleaned up old anonymous enabling in /kernel/drv/dtrace.conf > dtrace: cleaned up forceload directives in /etc/system > dtrace: saved anonymous enabling in /kernel/drv/dtrace.conf > dtrace: added forceload directives to /etc/system > dtrace: run update_drv(1M) or reboot to enable changes > > But now just reports the above. Rebooting can sometimes get it to run > one time, but never twice ... > ------------------------------------------------------------------------- > > > ------------------------------------------------------------------------ > > modload:entry > { > printf("\n\nModule name: %s \n", stringof(arg1)); > printf("Excutable name: %s \n",execname); > printf("pid id: %d\n", pid); > stack(10); > self->trace = 1; > } > > modctl_modload:entry > { > printf("\n\nModule name: %s \n", copyinstr(arg1)); > printf("Excutable name: %s \n",execname); > printf("pid id: %d\n", pid); > stack(10); > self->trace1 = 1; > } > fbt::mod_install: > /self->trace || self->trace1/ > { > trace(arg1); > } > crypto_register_provider:entry > /self->trace || self->trace1/ > { > printf("\nProvider Description: %s",stringof(((crypto_provider_info_t *)args[0])->piu.piu_v1.pi_provider_description)); > trace(execname); > } > fbt:kcf:: > /self->trace || self->trace1/ > { > trace(arg1); > } > fbt:doorfs:: > /self->trace || self->trace1/ > { > trace(arg1); > } > crypto_register_provider:return > /self->trace || self->trace1/ > { > trace(arg1); > } > modload:return, modctl_modload:return > { > trace(arg1); > } > > proc:::signal-send > /stringof(args[1]->pr_fname) == "kcfd"/ > { > @[execname, stringof(args[1]->pr_fname), args[2]] = count(); > } > > END > { > printf("%20s %20s %12s %s\n", > "SENDER", "RECIPIENT", "SIG", "COUNT"); > printa("%20s %20s %12d %@d\n", @); > } > > ------------------------------------------------------------------------ > > _______________________________________________ > dtrace-discuss mailing list > dtrace-discuss at opensolaris.org
Possibly Parallel Threads
- 6284138 cryptoadm stop (still) fails if kcfd is not running
- prop.trend.test issue
- [inline-asm][asm-goto] Supporting "asm goto" in inline assembly
- [inline-asm][asm-goto] Supporting "asm goto" in inline assembly
- [inline-asm][asm-goto] Supporting "asm goto" in inline assembly