Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!apple!rutgers!ucla-cs!casey
From: casey@CS.UCLA.EDU
Newsgroups: comp.sys.apollo
Subject: Don't understand how objects are loaded into memory ...
Keywords: xmh, X.V11R2, dbx, object loading, memory mapping, map corruption?
Message-ID: <15689@shemp.CS.UCLA.EDU>
Date: 1 Sep 88 12:58:35 GMT
Sender: news@CS.UCLA.EDU
Reply-To: casey@CS.UCLA.EDU (Casey Leedom)
Organization: UCLA
Lines: 27


  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