[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference turris::languages

Title:	Languages
Notice:	Speaking In Tongues
Moderator:	TLE::TOKLAS::FELDMAN

Created:	Sat Jan 25 1986
Last Modified:	Wed May 21 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	394
Total number of notes:	2683

226.0. "analyse/process with Ada?" by COMICS::DEMORGAN (Richard De Morgan, UK CSC/CS) Tue Mar 21 1989 05:45

    I have had this in the Ada notesfile, but so far no response. Does
    anybody here have any ideas - any input gratefully received.

    Groan!!! we have one of those customers who is writing a large program
    for the Ministry of Defence and cannot let us see the program. They
    say it gives an access violation.
    
    It was run under VMS V5.0-2 and we have a process dump 10,440 blocks
    long. When we attempt to analyse it, we get different output depending
    on which analyser we use and whether the /full switch is on. In
    no case do we get transferred to the debugger. Results are below:
    
    A5.0	without /full: prints out each line of output twice,
    		claims there was a reserved operand fault followed by
    		an access violation when trying to dispatch to an
    		exception handler.
    
    		with /full: gives each line once, does not indicate
    		any error, all register contents are different.
    
    		In both cases stack pointers are in P0 space.
    
    V5.1	without /full: exactly as A5.0.
    
    		with /full:  prints out two sets of registers with contents
    		as per the two A5.0 cases.
    
    Is there something about Ada programs that stops this working, or
    does analyse/process just not work? The /full output shows high
    AST count/limit (18/20) and enqueue count/limit (599/600).
    
    Any information appreciated.

T.R	Title	User	Personal Name	Date	Lines
226.1		ULTRA::WRAY	John Wray, Secure Systems Development	`Tue Mar 21 1989 14:43`	4
	Have you tried VMSNOTES - after all, ANALYZE/PROCESS is a VMS component... John
226.2	Reproducible	BMT::BOWERS	Count Zero Interrupt	`Wed Mar 29 1989 16:40`	1
	Can they reproduce the error in a non-classified environment?
226.3		GIDDAY::GILLINGS	His Bach is worse than his Bytes	`Wed May 17 1989 23:53`	13
	ANALYZE/PROCESS is a bit tricky if you try to analyze a dump on a machine other than the one which produced the crash. There are some SYSGEN parameters which must match (PIOPAGES and CTLPAGES for starters, probably several others as well). Another thing that may be wrong is which debugger you are using. If it is MP-DEBUG, I think you may have to "$ DEFINE DBG$PROCESS NONE" (this may be why you're seeing double output). I can't understand why they won't show you the program but are prepared to give you a process dump. The process dump itself is, in effect, an image file with all the DZRO pages expanded and all shareable images copied in. A hacker could derive a lot of information about the program from the dump. John Gillings, Sydney CSC
226.4	curiouser and curiouser	COMICS::DEMORGAN	Richard De Morgan, UK CSC/CS	`Fri May 19 1989 10:57`	12
	Re .3: Defining DBG$PROCESS NONE does not stop the double output. I wouldn't have guessed about the SYSGEN parameters. However, I did manage to read the dumps (from a V5.0-1 system) on a V4.7 analyser! 5 of them crashed on exactly the same instruction, but we're no wiser as to why this only happens when both processors are running. Somebody with security clearance for the site is going there on monday, so maybe we'll get to the bottom of it. The manifestation of the accvio is that it tries to do an INSQUE on a header with both longwords zero - then gets trapped by PCA$COLLECTOR's primary handler which resignals it - it then accvios on a REMQUE on the same faulty header. But - the user claims he hasn't got PCA Collector - but he's certainly got PCA$COLLECTOR_MAIN in the global symbol table.