[Info-vax] Home-grown application process dumps

[Stephen Hoffman]

On 2015-01-07 21:22:43 +0000, mcleanjoh at gmail.com said:

> From your ANALYZE/PROCESS_DUMP (???)
> 
> %BAS-F-MEMMANVIO, Memory management violation-BAS-I-USEPC_PSL, at user 
> PC=84236620, PSL=0000001B-SYSTEM-F-ACCVIO, access violation, reason 
> mask=04, virtual address=00000000002D0002, PC=FFFFFFFF84236620, 
> PS=0000001B
> You're at PC 84236620 ?  That's way up high.  Is it in VMS code or 
> dynamic memory?  SDA might help tell you, assuming you have time to get 
> into it and do a SHOW PROCESS/IMAGE before the crash.

Ayup.   Hence my guess that that's a system service call that's getting 
passed some junk, or it's junk.

> Steve says that the 0002D0002 looks like a descriptor, so an attempted 
> pass by value rather than pass by reference (i.e. address) seems likely.

The first longword of a two-byte-long dynamic text string descriptor, yes.

That value could however be garbage, because once the heap or the stack 
is corrupt, all bets are off.

Some legitimate and correct code that encounters some underlying data 
from the heap or the stack that's become corrupted can get weird and 
unstable.

> Have you got some diagnostics in the code that help you identify how 
> far it got and hopefully help you pin down if not the line then at 
> least the region?  (I'm well aware that adding diagnostics can hide 
> problems, especially memory corruptions that now take place on memory 
> that you don't access again and therefore there's no problem, but it is 
> worth a try.)

If embedding logging moves the errors around, that usually means you're 
just chasing a stack or heap corruption or a synchronization error 
around.  Which usually then means figuring out exactly when the 
run-time environment goes from "normal" to "wonky".   I've also used 
binary searches when debugging some of these cases — stuff in the logs 
and in the debugger looks OK, then somewhat later along stuff looks 
wonky, then split the difference, restart the code and the debugger and 
the logs and check again.   But given this is appearing only in 
production, adding integrated logging, and maybe running with the 
debugger present but not enabled, and maybe a signal handler with a 
signal to SS$_DEBUG to generate some data are probably going to be the 
path forward.


-- 
Pure Personal Opinion | HoffmanLabs LLC