| Main Page -> ProbeVue -> On Using ProbeVue |
On Using ProbeVue
| Item: | Passing string parameters is non-standard |
| System: | 6100 |
| Description: | Passing (explicit) strings to probevue is difficult and not the
"Unix standard" way. For example see this code:
#!/bin/probevue
Produces this result:@@BEGIN { printf("$1 = %s\n$2 = %d\n", $1, $2); exit(); }
# ./stringprob.e 1 2
$1 = $2 = 2 # ./stringprob.e \"1\" \"2\" $1 = 1 $2 = 43 # ./stringprob.e \"1\" 2 $1 = 1 $2 = 2 |
| Fix: | Wrap the code in a shell script. (Note that to print the "$"
character it must be escaped and ${1} & ${2} are now shell variables.)
#!/bin/ksh
Here is the results when running it as a shell script:
probevue <<EOF @@BEGIN { printf("\$1 = %s\n\$2 = %d\n", \"${1}\", ${2}); exit(); } EOF
# ./stringprob.sh 1 2
$1 = 1 $2 = 2 |
| Notes: |
The is not a probevue bug - but a design "issue" with the Vue language. A
probe language is not designed to work like shell or C code where you can explicitly validate
input and call a "usage()" function if the user does not enter proper data. If your
goal is to write ProbeVue scripts that act like standard Unix utilities, you need to either rely
upon probevue to validate input (such as insuring that user enters a PID instead of a process
name) or do it yourself with a wrapper script. The use of Shell ($1, $2, $3...) parameters, and relying upon ProbeVue to catch the resulting input errors can cause varied messages depending on where in the script they were used. If the target user is unfamiliar with the Vue language or probevue messages, this can be difficult to diagnose the problem. Calling probevue from a shell script also allows for passing parameters to probevue that cannot be passed from the shell interpreter string (specifically options like -X). |
| Item: | printf() does not warn on format / variable mismatch |
| System: | 6100-02 |
| Description: | Unlike the C version (of printf()), probevue does not issue compile time warnings when specifying the wrong format specifier for the supplied variable to printf(). If you pass a long long to an "%d" format specifier you may not see the proper value displayed by printf(). |
| Fix: | The trace() call provides a more reliable method of displaying data as it will determine type at compile time and is not sensitive to the type/format mismatch issue. |
| Notes: | It is important to properly type variables in Vue. Vue will promote varaibles as necessary but counting on the promotion in cases where this works in C can lead to unanticipated results. |
| Item: | Implicit declaration of variables |
| System: | 6100-02 |
| Description: | Typos lead to new variables. If you typo a complex variable name in an action block, probevue will not generate an error, but instead will implicitly declare a new variable of a type that it determines. |
| Fix: | This is normal behavior. |
| Notes: | There is no switch (like ksh -u) to check for implicit initialitation of new variables. |
| Item: | Unable to get tenative tracing to work |
| System: | 6100-02 |
| Description: | Even when running the sample code (tentative.e) found in au_probevue.pdf, the session terminates with: # probevue tentative.e $$ 2 Unable to start session 0x0000000096284047 The problem has been reduced to calling trace() within a tentative "block". Code that demonstrates the problem can be found in tprob.e. |
| Fix: | Still an open PMR with IBM (PMR number 56579,7TD). The temporary fix appears to be to avoid using trace() in a tentative tracing "block". |
| Notes: | This most likely a bug in TL2 as it has worked sucessfully in versions before and after. |
| Item: | Unable to access second paramater (__arg2) in the @@syscall:*:shmget:entry probe |
| System: | 6100-02 |
| Description: | Any access of __arg2 terminates the session with: Probevue session has been aborted 0x00000000962840fe Additional analysis suggests that this is really about the data type and not the shmget:entry probe as this same behavior is seen in other syscall entry probes that utilize a long. Additional discussion can be found in the "long" problem. |
| Fix: | Confirmed bug. PMR opened with IBM (PMR number is 39215, 7TD). A temporary fix is to change the data type from long to int. A fix has been provided by IBM for this problem. The fix was for PMR 39215,7TD but also resolves PMR 59435,7TD (see The "unsigned long" problem). |
| Notes: | This is a bug. The (temporary) fix is to change the data type from a long to an int. The int data type should be 4 bytes, and the long data type should vary depending on where it was declared in the Vue script and the bitness (32/64) of the probed binary. So according to the specification, you should have a data type mismatch if you are probing a 64 bit process. I have not seen evidence of this to date. Additional discussion is listed in the the "long" problem on this page. The issue at hand is the use of the size_t value that is popular in many file and memory access system calls. This value should be size variant as it is directly relevant to the bitness of the binary / environment. Setting it to an int may be fine for most applications, but will (technically) break any 64 bit applications that support a larger offset. |
| Item: | Calling strlen() on String data type fails |
| System: | 6100-02 |
| Description: | strlen($1); (When $1 is properly passed as a string) works. strlen(mystring); fails with: Unable to start session 0x0000000096284047 |
| Fix: | Do not run strlen() on TL2 systems. It is a TL3 and later feature. |
| Notes: |
| Item: | Calling trace() on an entry type variable |
| System: | 6100-02 |
| Description: | trace(__arg1); fails with: ERR-105: Line: n Column: n Argument type mismatch. |
| Fix: | Declare an automatic / local variable in the action block, assign it the value of __arg1, then trace() it. |
| Notes: | [Potential PMR] |
| Item: | The size of longs and pointers should be variable based upon where they are declared. |
| System: | 6100-02 |
| Description: | According to the Extended Users Guide Specification, the size of a long is variable based upon either where it is declared, or the bitness (32 or 64) of the probed process. The size of a globally declared long should be 8 bytes. The size of a long declared in a BEGIN/END block should also be 8 bytes. Only longs declared local (to action block or thread) in a probe for a 32 bit process should be 4 bytes. |
| Fix: | There are more factors in the size of a long or pointer than where it is declared. The most notable of these is the (32|64) bitness of a process that is passed using the -X parameter to probevue. |
| Notes: | Contrast this with The "unsigned long" problem. Originally this was classified as one problem. It is now broken into two parts. This is more of a documentation issue, while the unsigned long issue is a bug. |
| Item: | Some scripts appear to be suffering from scoping problems. Variables change type and hold the wrong values based upon scope. |
| System: | 6100-02 |
| Description: | Use of the long data type seems to suffer from scoping problems. This might be related to The "long" problem but that is not clear. Code demonstrating the problem can be found in scopeprob.e and the results of a run of the script can be found in scopeprob.out. |
| Fix: | PMR has been opened with IBM (PMR number 55409,7TD). Awaiting a response. |
| Notes: |
| Item: | Unable to start session 0x0000000096284061 |
| System: | 6100-02 |
| Description: | This is caused by divide by zero errors. |
| Fix: | This is informational only - Check the value of a denominator before dividing. |
| Notes: | Why IBM decided to forgo "normal" error messages is a mystery to me. |
| Item: | Recognizing messages from NULL and bad pointers to get_userstring() |
| System: | 6100-02 |
| Description: | NULL pointers produce the following message: Probevue session has been aborted 0x000000008c284163 A (known) bad address causes this: Illegal address passed to the get_userstring function The Extended Users Guide Specification says this is bad pointer error: 0xEEEE000096284131 |
| Fix: | This is informational only - Check to see if a pointer is NULL before passing it to get_userstring(). |
| Notes: | I have not seen the error found in the Users Guide, but have instead seen the first two errors. |
| Item: | The "unsigned long" problem |
| System: | 6100-02 |
| Description: | Unsigned longs are always 4 bytes, while longs will vary in size based upon the probed process. If a probed process (using the -X switch) is 64 bit, then the size of all pointers and longs will change to 8 bytes in the ProbeVue environment. (This is slightly different than expected behavior, see The "long" problem, but proper.) The size of an unsigned long should also change, but it does not. Additional notes and specific examples can be found in ulong-problem.tar.gz |
| Fix: | PMR number 59435,7TD open with IBM. A fix has been provided by IBM and has shown to resolve this problem. The fix was for PMR 39215,7TD (see problem with long data type in entry probes) but resolves this problem. |
| Notes: | This problem is derived from the "long" problem. There it was mostly a documentation issue, here it is more problematic. |