From: SMTP%"system@lokidev.attmail.com" 16-AUG-1996 08:38:13.11 To: everhart@star.zko.dec.com CC: Subj: Interesting FORKing issue Hi, Two days ago, I was given a crash with Raxco's RTmon to look over. Of course, the customer didn't send a crash dump, just some output from some basic SDA commands: SHOW CRASH and SHOW STACK. Not too much to go on however, the crash was a forced bugcheck: REGCORDET, Register corruption detected after fork. I requested that the customer send a full backup copy of the dump file for my review. In the meantime, I was puzzled by the crash. I started looking through the Alpha machine code for EXE$FORKDSPTH to understand what the bugcheck was all about. I also noticed a unique "footprint" in the registers in the crash output sent by the customer. R6 was all sizes, R7 was all sevens, R8 was eights, R9 was all nines, R10 all As and so on. After lots of effort, I found that the customer had the sanity checking version of the dispatcher loaded (ie the _MON versions). From what I could gather is that DEC writes these registers prior to invoking the FORK thread and on return, checks them. If they're different -- bugcheck REGCORDET. Kudos to whomever devised that! A carefull observation of the registers quickly showed me the problem after understanding the sanity checking in that routine. General registers: R0 = FFFFFFFF 81D620A0 R1 = FFFFFFFF 81063680 R2 = 00000000 00000000 R3 = 00000000 00000000 R4 = 00000000 00900040 R5 = FFFFFFFF 81063680 R6 = 00000000 66666666 R7 = 00000000 77777777 R8 = FFFFFFFF 88888888 R9 = 99999999 99999999 R10 = AAAAAAAA AAAAAAAA R11 = BBBBBBBB BBBBBBBB R12 = CCCCCCCC CCCCCCCC R13 = DDDDDDDD DDDDDDDD R14 = EEEEEEEE EEEEEEEE R15 = EEEEEEEE EEEEEEEE R16 = 00000000 000009B4 R17 = 00000000 00000000 R18 = FFFFFFFF 946041A0 R19 = FFFFFFFF 81D05FA8 R20 = 00000000 00000000 R21 = 00000000 00900820 R22 = FFFFFFFF 81D62968 R23 = FFFFFFFF 81D25620 R24 = 00000000 00001099 AI = 00000000 0000AAB5 RA = FFFFFFFF FFFFFFFF PV = FFFFFFFF 81D26930 R28 = FFFFFFFF 80020104 FP = FFFFFFFF 93C15FD0 PC = FFFFFFFF 80020284 PS = 30000000 00000804 R6, R7 and R8 are not quite fully restored! The routine that was FORKed preserved the registers R6,R7 and R8 on entry and restored them on exit using RUSHR and POPR instructions. I looked at the Alpha machine code and sure enuf, these were being compiled into mere LDLs and STLs. Therein, the problem. The full 64 bits of the registers needs to be preserved. I have now created two new macros to compliment DECs $PUSH64 and $POP64 macros. I've called them: $PUSHR64 and $POPR64 -- what else? I incorporated them into the SSINT code in the OUTPUT and OUTHEX macros and will be sending you an update immediately folllowing this message. Use this version instead of the version sent yes- terday. All other code in SSINT is the same. With V7.0, I have to be more conscious of the 64 BITtedness of operations! I also have to stop reading all that ALpha machine code in SDA -- It's getting almost as easy as reading VAX code -- sometimes... VAXman- For without are dogs, and sorcerers, and whoremongers, and murderers, and idolaters, and whosoever loveth and maketh a lie. - Revelation - ================== RFC 822 Headers ================== Return-Path: system@lokidev.attmail.com Received: by galaxy.zko.dec.com (UCX V4.0-10B, OpenVMS V6.2 VAX); Fri, 16 Aug 1996 08:38:02 -0400 Received: from mdau.md.mt.np.els-gms.att.net by mail11.digital.com (8.7.5/UNX 1.2/1.0/WV) id IAA16121; Fri, 16 Aug 1996 08:25:06 -0400 (EDT) Date: Fri, 16 Aug 1996 08:05:00 -0500 From: system@lokidev.attmail.com ("Brian Schenkenberger, VAXman-") Received: from lokidev by attmail; Fri Aug 16 12:24 GMT 1996 Received: from alpha by oadec (OADEC V3.0); Fri Aug 16 08:05:00 EDT 1996 Subject: Interesting FORKing issue To: everhart@star.zko.dec.com X-VMS-Mail-To: OA%"attmail!internet!star.zko.dec.com!everhart" Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: