Depois que você determinar o consumidor de seu interesse, poderá recuperar os dados correspondentes aos buffers não consumidos, especificando o endereço da estrutura do estado como o dcmd ::dtrace. O exemplo a seguir mostra o resultado do dcmd ::dtrace em uma habilitação anônima de syscall:::entry com a ação trace(execname):
> ::dtrace_state ADDR MINOR PROC NAME FILE cbfb7a40 2 - <anonymous> - > cbfb7a40::dtrace CPU ID FUNCTION:NAME 0 344 resolvepath:entry init 0 16 close:entry init 0 202 xstat:entry init 0 202 xstat:entry init 0 14 open:entry init 0 206 fxstat:entry init 0 186 mmap:entry init 0 186 mmap:entry init 0 186 mmap:entry init 0 190 munmap:entry init 0 344 resolvepath:entry init 0 216 memcntl:entry init 0 16 close:entry init 0 202 xstat:entry init 0 14 open:entry init 0 206 fxstat:entry init 0 186 mmap:entry init 0 186 mmap:entry init 0 186 mmap:entry init 0 190 munmap:entry init ... |
O dcmd ::dtrace trata os erros da mesma maneira que o dtrace(1M): se eliminações, erros, eliminações especulativas ou similares forem encontrados durante a execução do consumidor, o ::dtrace emitirá uma mensagem correspondente à mensagem do dtrace(1M).
A ordem dos eventos exibidos por ::dtrace é sempre do mais antigo para o mais recente em uma determinada CPU. Os buffers da CPU são exibidos em ordem numérica. Se uma ordem for necessária para eventos em CPUs diferentes, rastreie a variável timestamp.
Você pode exibir somente os dados de uma determinada CPU, especificando a opção - c como ::dtrace:
> cbfb7a40::dtrace -c 1 CPU ID FUNCTION:NAME 1 14 open:entry init 1 206 fxstat:entry init 1 186 mmap:entry init 1 344 resolvepath:entry init 1 16 close:entry init 1 202 xstat:entry init 1 202 xstat:entry init 1 14 open:entry init 1 206 fxstat:entry init 1 186 mmap:entry init ... |
Observe que ::dtrace processa somente dados do DTrace no kernel . Os dados que tenham sido consumidos no kernel e processados (através do dtrace(1M) ou outros meios) não estarão disponíveis para ser processados com o ::dtrace. Para garantir que a maior quantidade possível de dados esteja disponível no momento da falha, use uma política de armazenamento em buffer em anel. Consulte o Capítulo 11Buffers e armazenamento em buffer para obter mais informações sobre as políticas de buffer.
O exemplo a seguir cria um buffer em anel muito pequeno (16K) e registra todas as chamadas do sistema e o processo que as faz:
# dtrace -P syscall'{trace(curpsinfo->pr_psargs)}' -b 16k -x bufpolicy=ring dtrace: description 'syscall:::entry' matched 214 probes |
A observação de um despejo de memória obtido quando o comando acima estava sendo executado produz um resultado similar ao seguinte exemplo:
> ::dtrace_state ADDR MINOR PROC NAME FILE cdccd400 3 d15e80a0 dtrace ced065f0 > cdccd400::dtrace CPU ID FUNCTION:NAME 0 139 getmsg:return mibiisa -r -p 25216 0 138 getmsg:entry mibiisa -r -p 25216 0 139 getmsg:return mibiisa -r -p 25216 0 138 getmsg:entry mibiisa -r -p 25216 0 139 getmsg:return mibiisa -r -p 25216 0 138 getmsg:entry mibiisa -r -p 25216 0 139 getmsg:return mibiisa -r -p 25216 0 138 getmsg:entry mibiisa -r -p 25216 0 139 getmsg:return mibiisa -r -p 25216 0 138 getmsg:entry mibiisa -r -p 25216 0 17 close:return mibiisa -r -p 25216 ... 0 96 ioctl:entry mibiisa -r -p 25216 0 97 ioctl:return mibiisa -r -p 25216 0 96 ioctl:entry mibiisa -r -p 25216 0 97 ioctl:return mibiisa -r -p 25216 0 96 ioctl:entry mibiisa -r -p 25216 0 97 ioctl:return mibiisa -r -p 25216 0 96 ioctl:entry mibiisa -r -p 25216 0 97 ioctl:return mibiisa -r -p 25216 0 16 close:entry mibiisa -r -p 25216 0 17 close:return mibiisa -r -p 25216 0 124 lwp_park:entry mibiisa -r -p 25216 1 68 access:entry mdb -kw 1 69 access:return mdb -kw 1 202 xstat:entry mdb -kw 1 203 xstat:return mdb -kw 1 14 open:entry mdb -kw 1 15 open:return mdb -kw 1 206 fxstat:entry mdb -kw 1 207 fxstat:return mdb -kw 1 186 mmap:entry mdb -kw ... 1 13 write:return mdb -kw 1 10 read:entry mdb -kw 1 11 read:return mdb -kw 1 12 write:entry mdb -kw 1 13 write:return mdb -kw 1 96 ioctl:entry mdb -kw 1 97 ioctl:return mdb -kw 1 364 pread64:entry mdb -kw 1 365 pread64:return mdb -kw 1 366 pwrite64:entry mdb -kw 1 367 pwrite64:return mdb -kw 1 364 pread64:entry mdb -kw 1 365 pread64:return mdb -kw 1 38 brk:entry mdb -kw 1 39 brk:return mdb -kw > |
Observe que os registros mais recentes da CPU 1 incluem uma série de chamadas do sistema de write(2) por um processo mdb -kw. Esse resultado provavelmente está relacionado ao motivo da falha do sistema porque um usuário pode modificar texto ou dados em execução no kernel com mdb(1) quando executados com as opções -k e - w. Nesse caso, os dados do DTrace fornecem pelo menos um meio interessante de investigação, se não a causa principal da falha.