| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 1840.1 | first a few static watchpoint comments... | SSPADE::SSPADE::HILDE | | Mon Mar 03 1997 17:25 | 77 |
|
I haven't looked at the EXMEMPOOL yet (I will) although its not surprising in
this case since you are setting a watchpoint on a large array. The internal
workings of the current debugger breaks down the array into its individual
components and sets watchpoint events on each of them. So...that ends up being
a lot of events, in this case, thus the need to expand the debugger kernel
memory. I suspect that is what is happening (again I will verify that soon).
Note the EXPMEMPOOL is just an informational message, "-I-", and, by itself,
should NOT be considered an "error". Indeed, I suspect that in this case
there is no problem with it at all.
I can see how the static watchpoint reporting can be confusing and is not
ideally what we (and our users) would want...but what I see here is not
incorrect! The underlying archeture of ALPHA only allows memory changes
of as big as a quadword at a time, i.e. STQ. Your array elements are bigger
than one quadword...so it takes more than one store for your high level
line deposit to finish. The current debugger static watchpoint implementation
reports any and all changes it sees. That is, it doesn't save up the changes
it detects until the end of the high level source line. This example shows
how confusing this can be for high level language debug users who really
don't know or care about the low level implementations. I will consider an
enhancement that saves up changes until source level line completions for
a future debugger release. Let me illustrate. The following debugger log
shows that to finish stepping over one of your�"move 'aaaaaaaaaa' to RBIDB
(rpsub)" lines requires a 2 GOs because of 2 watchpoint hits because of 2
separate STORE instructions (that's what the real code actually does).
DBG_1> go
break at routine SETWATCH in %PROCESS_NUMBER 1
2: program-id. setwatch.
DBG_1> set watch rp-record
DBG_1> set br %line 31
DBG_1> g
%DEBUG-I-EXPMEMPOOL, expanding debugger memory pool
count: 00
000000001
In Para2
break at SETWATCH\%LINE 31 in %PROCESS_NUMBER 1
31: move 'aaaaaaaaaa' to RPIDA (rpsub)
DBG_1>
DBG_1> set radix hex
DBG_1> step
watch of RPIDA of RPID of SETWATCH\RP-RECORD(1) at SHARE$LIBOTS_CODE0+0F38 in
%PROCESS_NUMBER 1
old value: ".........."
new value: "aaaaaaaa.."
break at SHARE$LIBOTS_CODE0+0F3C in %PROCESS_NUMBER 1
%DEBUG-I-SOURCESCOPE, Source lines not available for .0\%PC
Displaying source in a caller of the current routine
32: move 'aaaaaaaaaa' to RPIDB (rpsub)
DBG_1>
DBG_1> ex/inst SHARE$LIBOTS_CODE0+0F38
SHARE$LIBOTS_CODE0+0F38: STQ R28,(R16)
DBG_1>
DBG_1> go
watch of RPIDA of RPID of SETWATCH\RP-RECORD(1) at SHARE$LIBOTS_CODE0+0F4C in
%PROCESS_NUMBER 1
old value: "aaaaaaaa.."
new value: "aaaaaaaaaa"
break at SHARE$LIBOTS_CODE0+0F50 in %PROCESS_NUMBER 1
%DEBUG-I-SOURCESCOPE, Source lines not available for .0\%PC
Displaying source in a caller of the current routine
32: move 'aaaaaaaaaa' to RPIDB (rpsub)
DBG_1>
DBG_1> ex/inst SHARE$LIBOTS_CODE0+0F4C
SHARE$LIBOTS_CODE0+0F4C: STQ_U R28,#X0007(R16)
DBG_1> g
stepped to SETWATCH\%LINE 32 in %PROCESS_NUMBER 1
32: move 'aaaaaaaaaa' to RPIDB (rpsub)
DBG_1>
So, once again, it looks like the array is changing in bits and pieces...
because it actually is! However, to the high level source debug user this
is of little interest and is perhaps even a bit annoying and confusing.
Lon
|
| 1840.2 | second a nostatic wathcpoint comment | SSPADE::SSPADE::HILDE | | Mon Mar 03 1997 17:48 | 31 |
|
You can get the kind of behavior you desire with the slower nostatic watchpoints
...IF you are very careful about setting them in the correct scope. That is,
in this case, you MUST wait and set them AFTER the initial GO (once again,
the EXPMEMPOOLs are likely expected behavior...but I'll investigate that
further soon). It's the /OVER switch here that in effect waits until the
low level calls to LIBOTS routines (and the individual stores) complete:
DBG_1> go
break at routine SETWATCH in %PROCESS_NUMBER 1
2: program-id. setwatch.
DBG_1> set watch/nostatic/over rp-record
%DEBUG-I-EXPMEMPOOL, expanding debugger memory pool
DBG_1> g
%DEBUG-I-EXPMEMPOOL, expanding debugger memory pool
%DEBUG-I-EXPMEMPOOL, expanding debugger memory pool
count: 00
000000001
In Para2
watch of RPIDA of RPID of SETWATCH\RP-RECORD(1) at SETWATCH\%LINE 31+88 in
%PROCESS_NUMBER 1
31: move 'aaaaaaaaaa' to RPIDA (rpsub)
old value: ".........."
new value: "aaaaaaaaaa"
break at SETWATCH\%LINE 32 in %PROCESS_NUMBER 1
32: move 'aaaaaaaaaa' to RPIDB (rpsub)
DBG_1>
Lon
|
| 1840.3 | no noticeable memory leaks here... | SSPADE::SSPADE::HILDE | | Fri Mar 07 1997 17:00 | 5 |
|
Looks like all the EXPMEMPOOL informations are indeed related to the watchpoint
events...that is, I've looked and found no evidence of kernel memory leaks.
Lon
|
| 1840.4 | - reviewed your input - | CSC32::V_HAVER | | Tue Mar 11 1997 18:56 | 33 |
| Lon,
Re: .1
> Note the EXPMEMPOOL is just an informational message, "-I-", and, by itself,
> should NOT be considered an "error". Indeed, I suspect that in this case
> there is no problem with it at all.
We understood that the error was informational and usually valid.
However, the behavior with the array didn't make much sense. But with your
explanation, I can see that the array really is ok, and the behavior
reasonable (if not pretty). We can suggest the use of nostatic, for those
customers who find the multiple breaks an issue.
Since I don't have any code that produces the ACCVIO, ROPRAND, etc. we will
have to assume that those errors had nothing to do with the EXMEMPOOL. It
may be that the customers have programs with coding errors, and the EXMEMPOOL
message is coincidental. So, we will direct customers to follow the normal
debugging techniques for finding coding problems that often cause process
memory corruption (i.e. check for array subscripts out of bounds).
If we do get more on this, you'll be the first to know! :^)
re: .3
>Looks like all the EXPMEMPOOL informations are indeed related to the watchpoint
>events...that is, I've looked and found no evidence of kernel memory leaks.
This is good to know.
Thanks for your time and efforts.
Vicky H.
|
| 1840.5 | | SSPADE::SSPADE::HILDE | | Wed Mar 12 1997 14:01 | 21 |
|
>Since I don't have any code that produces the ACCVIO, ROPRAND, etc. we will
>have to assume that those errors had nothing to do with the EXMEMPOOL. It
>may be that the customers have programs with coding errors, and the EXMEMPOOL
>message is coincidental. So, we will direct customers to follow the normal
>debugging techniques for finding coding problems that often cause process
>memory corruption (i.e. check for array subscripts out of bounds).
Yeah, I guess I would agree. It is true, however, that stepping on ALPHA is
complex and step emulation regions that get orphaned or improperly terminated
or not "recognized" usually lead to ACCVIOs, OPCDECs, or ROPRANDs. I think
most of these problems have been fixed by/in V7.0. There is one fix I know
of related to tracepoint stepping, e.g. SET TRACE/INST or SET TRACE/CALL, in
a thread or AST rich application that wasn't fixed until V7.1.
>If we do get more on this, you'll be the first to know! :^)
Good...look forward to it.
Lon
|