[Info-vax] Home-grown application process dumps

[RGB]

On Tuesday, January 6, 2015 10:18:05 AM UTC-5, Stephen Hoffman wrote:
> On 2015-01-06 06:09:28 +0000, David Froble said:
> 
> > Stephen Hoffman wrote:
> > 
> >> If that's not it, I'd start looking for a memory heap corruption, as 
> >> those can blow out all over the place, and with all sorts of odd 
> >> errors.  With BASIC, that's usually some system service call or similar 
> >> that exceeds the size of the string that's been presented to the system 
> >> service call -- system services generally don't re-size or extend 
> >> dynamic string descriptors, the calls just keep writing however much 
> >> they've been asked to write.  Ten pounds of bytes into a five-pound 
> >> string buffer makes for a corrupt heap, after all.
> > 
> > I agree with what you wrote, until this paragraph.  Maybe I don't 
> > understand what you wrote, but, my impression is that when working with 
> > a descriptor, VMS will not write past the defined length of the data.
> 
> If the called API is also using descriptors, yes, you'll either get the 
> data, whether exact-fit, truncated or padded.   If the storage 
> allocated to the descriptors is being used as a buffer however, 
> overruns are possible.   System services that use descriptors assume 
> all descriptors are static, and don't try to re-size them.   System 
> services that expect buffers and that get passed the address of a 
> buffer based on the buffer allocated for a dynamic string can clobber 
> the heap.
> 
> Descriptors are a clunky and somewhat limited version of an object, in 
> a newer language.  Descriptors were a good idea when they were created, 
> but they're kind of annoying to deal with compared with how objects 
> have been integrated with other languages and programming environments. 
>  Folks have used and have greatly improved on the idea of descriptors.
> 
> 
> -- 
> Pure Personal Opinion | HoffmanLabs LLC

All,

The following output is from one of our Developers.  I've relayed to him much, if not all, of the comments from this post.  (I am not a developer but simply manage our VMS environment.)  Here's his output:

Normally the line number should be in the listing.  If you do something like
the example, divide by zero, and you don't use the mechanism within BASIC
that allows you to trap errors internally and act on them, the program would
abort as they show, and it might also include a line number.

But as you have seen from the dumps and the analysis, it's usually missing.
This is partially because the crash is happening in a VMS shared image, and
not actually in "our" code.  You may also have noticed that the traceback information
that is in some dumps that should give the name of the module is filled with
garbage characters.

The problem here is that we are not getting anything "normal", like divide by zero,
or issuing a system service call with a bad parameter, or something predictable.
The programs are blowing up at very odd locations, like inside system services.
And when the traceback is included, it says the program was doing something
that should be very innocuous, like loading a value into a register: something
that should not trigger an opcode fault.