From:	AITGW::"rankin%EQL.CALTECH.EDU@VM1.NoDak.EDU" "Pat Rankin" 25-OCT-1991 09:50:12.38
To:	Multiple recipients of list ANU-NEWS <ANU-NEWS@NDSUVM1>
CC:	
Subj:	Re: VAXTPU fatal error

Received: by AITGW.DECnet (utk-mail11 v1.5) ; Fri, 25 Oct 91 09:49:19 EDT
Received: from vm1.NoDak.edu by aitgw.ge.com (5.65/GE Gateway 1.4)
	id AA03952; Fri, 25 Oct 91 07:43:09 -0400
Message-Id: <9110251143.AA03952@aitgw.ge.com>
Received: from NDSUVM1.BITNET by VM1.NoDak.EDU (IBM VM SMTP R1.2.1MX) with BSMTP id 1656; Fri, 25 Oct 91 06:41:01 CDT
Received: from NDSUVM1.BITNET by NDSUVM1.BITNET (Mailer R2.07) with BSMTP id
 2186; Fri, 25 Oct 91 06:41:00 CDT
Date:         Fri, 25 Oct 1991 00:38:00 GMT
Reply-To: Pat Rankin <rankin%EQL.CALTECH.EDU@VM1.NoDak.EDU>
Sender: ANU-NEWS Discussion <ANU-NEWS@VM1.NoDak.EDU>
Comments:     Warning -- original Sender: tag was news@CCO.CALTECH.EDU
From: Pat Rankin <rankin%EQL.CALTECH.EDU@VM1.NoDak.EDU>
Subject:      Re: VAXTPU fatal error
To: Multiple recipients of list ANU-NEWS <ANU-NEWS@NDSUVM1>
 
In article <1991Oct24.093449.679@iscsvax.uni.edu>, connelly@iscsvax.uni.edu (Ken
 Connelly) writes...
>In article <23OCT199122375261@eql.caltech.edu>, rankin@eql.caltech.edu (Pat Ran
kin) writes:
>>      I hope you'll submit that SPR so that DEC might teach TPU to bomb
>> off more gracefully...  ;-)  NEWS should probably be using LIB$SIG_TO_RET
>> as its condition handler in invoke_editor() instead of what it's got now.
>
>I did start off with DEC via DSNlink on this.  They wanted more information
>about how TPU was getting invoked from ANU than I was willing to dig
>through source code to find!  ;-)  If increasing the PGFLQUO makes the
>problem go away, I will forward that information to Colorado Springs.
>However, I wouldn't hold my breath on any changes just yet.  ;-)
 
     After thinking it over, I suspect that NEWS is at fault.  TPU is
probably behaving properly and signalling the fact that it ran out of
memory, but the bogus condition handler in newscalledit.c is forcing it
to try to keep going as if no signal had been issued.  TPU isn't--and
shouldn't need to be--prepared to deal with that.
 
     I haven't had the time and energy to verify this hypothesis, but all
that should be needed is a small stub to call invoke_editor() and either a
tiny pagefile quota or a very large file to edit.  The following patch is
untested...  (Even if it works, you still need to boost users' pgflquo in
order to edit successfully; the patch should just keep NEWS from bombing.)
Now an interesting question:  does TPU release all the memory it's consumed
prior to signalling failure?  If not, this patch won't help NEWS much...
(LIB$FIND_IMAGE_SYMBOL consumes some memory that will never be released;
while the current program is running, that is).
 
                Pat Rankin, rankin@eql.caltech.edu
 
*** newscalledit.c
--- newscalledit.c-new
**************
*** 129,135 ****
   * - Other routines
   */
  extern        void    LIB$signal(int);
!
  static        int     signal_handler(struct chf$signal_array*,struct chf$mech_
array*);
 
 
 
 
 
 
 
 
 
 
 
--- 129,135 ----
   * - Other routines
   */
  extern        void    LIB$signal(int);
! extern        int     LIB$sig_to_ret(struct chf$signal_array*,struct chf$mech_
array*);
  static        int     signal_handler(struct chf$signal_array*,struct chf$mech_
array*);
 
 
 
 
 
 
 
 
 
 
 
**************
*** 187,192 ****
--- 187,194 ----
          /* Make string descriptors for the input and output files */
        FILLIN(infileP,infile_desc);
        FILLIN(outfileP,outfile_desc);
+
+       (void)lib$establish(LIB$sig_to_ret);
 
          /* Invoke the editor */
        status = (*editorP)(&infile_desc,&outfile_desc);
