Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10 beta 3/9/83; site nbs-amrf.UUCP Path: utzoo!watmath!clyde!cbosgd!ihnp4!zehntel!hplabs!hao!seismo!umcp-cs!nbs-amrf!libes From: libes@nbs-amrf.UUCP (Don Libes) Newsgroups: net.micro.68k Subject: bus error, but why? Message-ID: <363@nbs-amrf.UUCP> Date: Mon, 14-Jan-85 15:11:12 EST Article-I.D.: nbs-amrf.363 Posted: Mon Jan 14 15:11:12 1985 Date-Received: Sun, 20-Jan-85 06:26:24 EST Organization: National Bureau of Standards Lines: 29 I've wrote some C code that generates a bus error in the same spot, consistently. I don't think the C code (at least at the location the bus error is reported) is very important, because the location moves when I add or delete enough statements. Also, its executed several times before it faults. I've tried all the "classical" C debugging techniques (adding printfs, deleting code and watching for the error to go away, etc...) but I'm down to looking at the 68010 assembler (on a Sun). Using stepi (in dbx), I can single-step through the instruction. It always a movl. Here's an example: movl a0(18),d0 When I execute this instruction I get a bus error. What's mystifying is that I can look at the memory pointed to by both operands with the debugger. Additionally, the stack and everything else looks just fine. What else might a movl depend on? The 68010 reference manual says a bus error will leave condition codes set indicating the address in question, but how does one look at the condition codes with dbx? If it helps, the pc ends up two bytes into the movl, after the bus error. I can reset it to the movl instruction and get the bus error an arbitrary number of times. I ran the same piece of code on our VAX (running Eunice) just to see what its debugger (sdb) would say, but it doesn't generate a fault at all! Help! Don Libes {seismo,umcp-cs}!nbs-amrf!libes