Does anyone know how to display the address of a pointer in a TAL program using Inspect? For example, if I have a pointer variable named PTR, and while in Inspect I do "d (@ptr)", the value displayed is the address that PTR points to, not the address of the pointer variable itself. Is it possible to see the address of the pointer variable itself? I am debugging a memory corruption issue, and the ability to do this would help considerably.

On Thursday, January 26, 2023 at 11:55:36 AM UTC-8, rayje...@westernunion.com wrote:
> Does anyone know how to display the address of a pointer in a TAL program using Inspect? For example, if I have a pointer variable named PTR, and while in Inspect I do "d (@ptr)", the value displayed is the address that PTR points to, not the address of the pointer variable itself. Is it possible to see the address of the pointer variable itself? I am debugging a memory corruption issue, and the ability to do this would help considerably.

If you can modify the source and recompile the program, you can equivalence a non-pointer to the pointer and display the address of that new variable. For example:

INT .PTR;
INT PTR_X = PTR;

when in Inspect D (@PTR_X) would display the address of PTR, not the address PTR points at.

If you cannot change the source and recompile, you can try using the IDENTIFIER command. That command shows numerous things about the variable you give as its argument. Among them is the memory location of the variable. I don't remember what it shows for global variables, but for variable local to a proc, it shows the location as 'L'+x, where x is the offset from the L register at which the variable is located. There may be a way to display the value of the L register in high level Inspect, but if so, I don't remember it. However, you can switch to low level inspect, display the value of the L register, then return to high level Inspect:

LOW
D L
HIGH

If you are in a subproc, I believe the local variables are given addresses relative to the S register, so you would display the value of the S register instead of the L register when in low-level Inspect.

Memory corruption errors are difficult to track down. Good luck!

(Do you know about memory-change breakpoints? If not, read about them in the description of the BREAK command. They can be helpful for some cases of memory corruption debugging.)