The UEK5 kernel is out and as usually there is many enhancements and new features included in it ! One of the notable new feature is the dtrace PID provider Which allow setting “function boundary probes on user space functions, and to probe most arbitrary instructions within user space functions” check uek5-features-dtrace
Let’s give it a try :
TEST ENV : OEL 7.5 / UEK5 / ORACLE 12.2.0.1 /stap 4.0 /dtrace: Sun D 1.6.4
The first thing that i wanted to test is if the “UPROBE” problem that i described here is still there (Tracing function kskthbwt ) .
So the problem is not fixed yet ! 524 error returned !
Let’s test the new dtrace PID Provider (A simple example without any use just tracing call to function kskthbwt – kernel service resource manager thread begin wait ) :
The thing is that even no error is return nothing is traced so i decided to take a closer look !
A quick analyze of the source code indicate that the PID provider seem to rely on UPROBE :
So i used a tiny systemtap script to analyze what’s going on :
stap -v -e 'probe kernel.function("uprobe_register") { printf("Uprobe register inode :%d offset :%x\n", $inode->i_ino ,$offset); } probe kernel.function("uprobe_register").return { printf("Uprobe register return:%d \n" , register("eax")); } probe kernel.function("uprobe_unregister") { printf("Uprobe unregister\n"); }'
159235483 is the inode of the oracle executable :
The “uprobe_register” function return an error 524 !
The new dtrace PID provider rely on uprobe and is then subject to the same problem !
A quick fix as described in my old blog posts is to trace the next instruction by adding two bytes in this case :
We can confirm that the uprobe is successfully registered :
That’s it 😀
Hatem Mahmoud's blog 