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