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

Conference noted::hackers_v1

Title:-={ H A C K E R S }=-
Notice:Write locked - see NOTED::HACKERS
Moderator:DIEHRD::MORRIS
Created:Thu Feb 20 1986
Last Modified:Mon Aug 03 1992
Last Successful Update:Fri Jun 06 1997
Number of topics:680
Total number of notes:5456

258.0. "Want an image dump from subprocess" by VIRTUE::RICO () Thu Jun 12 1986 22:09

    I have a program that creates a subprocess and kicks off an image
    in that subprocess.  When the subprocess image dies (accvio or
    whatever), I want to be able to debug the problem.
    
    Looking into the V4.4 documentation, I saw that the $CREPRC service
    now has a flag you can set to enable the image dump facility, so
    that if the subprocess image dies unexpectedly, you'll get a process
    dump.  Great, this is just what I'm looking for, except I tried
    setting the bit in the $CREPRC call, but I do not get a .DMP file
    when the subprocess image dies.
    
    Any ideas out there??
T.RTitleUserPersonal
Name		DateLines
258.1SQM::HALLYBFree the quarks!Fri Jun 13 1986 19:111
    Is the image linked /NOTRACE?
258.2still executing code after ACCVIO??LABRTE::RICOFri Jun 13 1986 20:2018
    RE: .1  No, it's not linked /NOTRACE.
    
    The $CREPRC does specify a termination mailbox for the subprocess.
    Currently this is the only data we get from the subprocess when
    it unexpectedly dies.  Unfortunately, you can get the final status
    code of the subprocess but not the parameters that go with it.
    Could the use of a termination mailbox block the process dump somehow?
    
    Another note, and this is weird:  it seems that the image continues
    to run AST code after the accvio happens.  When it gets to a certain
    point when I know the accvio has already happened, the subprocess
    is still doing stuff!!  Then finally (I assume when something else
    happens, sorta like a DBLE-ERR HLT on a 780) the subprocess finishes
    dying and issues the message to the termination mailbox.
    IS THIS POSSIBLE?  for AST code to still execute after an exception
    has occurred???
    
    	Rico
258.3RANI::LEICHTERJJerry LeichterSat Jun 14 1986 16:5120
Process dumps occur if an image terminates due to an unhandled exception; I'd
guess the last-chance condition handler causes the dump to take place, just
as it normally prints out the ACCVIO message and the register dump.  Or maybe
this is handled by an exception handler in a frame pushed on the user stack
before you begin executing; same effect.

If for any reason the image terminates in some other way, you won't get a dump.
I suspect - I'm about to try find out, as I'm about to embark on debugging a
problem in a similar situation - that if a program is run with the debugger
it will never dump, because the debugger will always pick up the exception.

As to AST's running after the ACCVIO:  An ACCVIO is just an exception.  If it
occurs during non-AST execution, the search for a handler, and the execution
of any handlers found, should be interruptable by AST's.  If you've got a
big stack, especially one where a lot of frames declare handlers, it could
take a long time to deal with the exception.  AST's can begin during that
period.  (In fact, if an AST during that period does a $EXIT, the program
would probably terminate without ever dealing with the ACCVIO - hence, no
dump.)
							-- Jerry