Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!ucbvax!UM.CC.UMICH.EDU!Pat_McGregor
From: Pat_McGregor@UM.CC.UMICH.EDU
Newsgroups: comp.sys.apollo
Subject: mailer daemon mail
Message-ID: <3437214@um.cc.umich.edu>
Date: 20 Sep 88 20:06:04 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 94

Due to a hardware error, this message got stuck here at U-M and
forwarded to the postmasters. I'm not certain it made it out to
the rest of the mailing group: I apologize if you are seeing a
duplicate.
 
Pat McGregor for the U-M postmasters
---(Forwarded from: mtv@mailgw.cc.umich.edu, Dated: Mon, 19 Sep 88 12:48:06 EDT)---
Return-path: 
Received: from umix.cc.umich.edu by um.cc.umich.edu via UMnet; Mon, 19 Sep 88 14:49:56 EDT
Received: by umix.cc.umich.edu       id AA02256; Mon, 19 Sep 88 12:48:24 EDT
Received: by mailgw.cc.umich.edu       id AA23336; Mon, 19 Sep 88 12:48:06 EDT
Date: Mon, 19 Sep 88 12:48:06 EDT
From: mtv@mailgw.cc.umich.edu
Message-Id: <8809191648.AA23336@mailgw.cc.umich.edu>
To: postmaster@um.cc.umich.edu
 
Return-Path: Mailer-Daemon@umix.cc.umich.edu
Received: from umix.cc.umich.edu by mailgw.cc.umich.edu (5.59/1.0)
      id AA29246; Thu, 1 Sep 88 15:55:01 EDT
Received: by umix.cc.umich.edu (5.54/umix-2.0)
      id AA02869; Thu, 1 Sep 88 16:14:27 EDT
Date: Thu, 1 Sep 88 16:14:27 EDT
>From: Mailer-Daemon@umix.cc.umich.edu (Mail Delivery Subsystem)
Subject: Returned mail: Unable to deliver mail
Message-Id: <8809012014.AA02869@umix.cc.umich.edu>
To: 
 
   ----- Transcript of session follows -----
554 putbody: write error
 
   ----- Unsent message follows -----
Received: by umix.cc.umich.edu (5.54/umix-2.0)
      id AA02181; Thu, 1 Sep 88 15:31:42 EDT
Received: by mailgw.cc.umich.edu (5.59/1.0)
      id AB28750; Thu, 1 Sep 88 15:06:16 EDT
Date: Thu, 1 Sep 88 15:06:16 EDT
>From: Mailer-Daemon@mailgw.cc.umich.edu (Mail Delivery Subsystem)
Subject: Returned mail: Deferred: Connection timed out during user open with imax.eng.uiowa.edu
Message-Id: <8809011906.AB28750@mailgw.cc.umich.edu>
To: 
To: 
 
   ----- Transcript of session follows -----
>>> RCPT To:
<<< 550 Addressee unknown
550 ... User unknown
421 imax.eng.uiowa.edu.internet... Deferred: Connection timed out during user open with imax.eng.uiowa.edu
 
   ----- Unsent message follows -----
Received: from umix.cc.umich.edu by mailgw.cc.umich.edu (5.59/1.0)
      id AA27595; Thu, 1 Sep 88 11:52:07 EDT
Received: by umix.cc.umich.edu (5.54/umix-2.0)
      id AA26795; Thu, 1 Sep 88 10:39:14 EDT
Received: by umix.cc.umich.edu (5.54/umix-2.0)
      id AA26789; Thu, 1 Sep 88 10:39:01 EDT
Received: by ucbvax.Berkeley.EDU (5.59/1.31)
      id AA20404; Thu, 1 Sep 88 07:07:06 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews
      for apollo-arpa@umix.cc.umich.edu (apollo@umix.cc.umich.edu)
      (contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 1 Sep 88 12:58:35 GMT
>From: casey@CS.UCLA.EDU
Organization: UCLA
Subject: Don't understand how objects are loaded into memory ...
Message-Id: <15689@shemp.CS.UCLA.EDU>
Sender: apollo-request@umix.cc.umich.edu
To: apollo@umix.cc.umich.edu
 
 
  Ok, I just don't understand what's going on here.  If I do an nm(1)
against an object, it tells me that the variable XXXfoo has been assigned
location 0.  When I start up dbx against the object (and run it telling
it to stop in main so I can look at things), dbx says that the address of
XXXfoo (&XXXfoo) is now 0xac5e0.  I can deal with that.  Things just get
mapping into memory when an object is loaded.  And when I use /com/debug
-smap, it tells me about this mapping.
 
  So that's cool.  Now I continue executing up to the fault in xmh that
I'm trying to track down.  Now when I ask it to print out the addresses
of variables, it gives me random values.  It's almost as if the debugger
itself has become corrupted.  The values aren't consistent in any way.
Two variables which used to be adjacent to each other are now indicated as
being 16Kb apart.
 
  The question that comes to my mind here is as follows: when I look at
the contents of the address first given for variable when I stopped it in
main, it has the right value at the fault, even though dbx is now telling
me that the variable has a different address.  I had thought that the
variable was getting trashed, but now it appears not.  Could it be that
the processes mapping is being corrupted?
 
  I guess my next attempt will be to try to cross process debug this so
that the debugger itself doesn't get clobbered.
 
Casey