elliott@veronica.cs.wisc.edu (James Elliott) (11/28/90)
Ultrix 4.0 on a DECstation seems to have a nice feature of fixing up unaligned accesses in executing programs. Rather than sending a SIGBUS, it prints Fixed up unaligned data access for pid 5285 (adacs) at pc 0x41bc0c on stderr (I'd guess), and continues execution. Now, my problem is that I want to get >rid< of these unaligned accesses, because I consider them bugs. So, I'd prefer to get the signal, so I can trap into the debugger (and get lost trying to figure out the code that Twig generated for me, but that's a different problem). How can I do this? I tried providing a different handler for SIGBUS, but it didn't get called; apparently the signal never gets delivered even to that level? Anyone have any ideas? -- Jim Elliott "Like a bridge he'll come between us, not a wall" elliott@veronica.cs.wisc.edu
mjr@hussar.dco.dec.com (Marcus J. Ranum) (11/28/90)
elliott@veronica.cs.wisc.edu (James Elliott) writes: >Now, my problem is that I want to get >rid< of these unaligned >accesses, because I consider them bugs. Amen! The way I used to catch them (this is GROSS) was by doing what amounted to a binary search with the debugger. I'd set breakpoints and slowly home in on it until I isolated it. Once I made the mistake of setting a breakpoint: stop when pc=0xblahblahblah and, of course, it sat and thought about it all night. There *HAS* to be a better way. Once I caught a similar bug by porting it to a SPARCStation and running it under the debugger, since the SS gives you an interrupt. mjr.
jtkohl@MIT.EDU (John T Kohl) (11/28/90)
In article <11824@spool.cs.wisc.edu> elliott@veronica.cs.wisc.edu (James Elliott) writes:
< Rather than sending a SIGBUS, it prints
< Fixed up unaligned data access for pid 5285 (adacs) at pc 0x41bc0c
< Now, my problem is that I want to get >rid< of these unaligned
< accesses, because I consider them bugs.
Since it apparently won't generate SIGBUS (unless the kernel addressing
fixup fails, in 3.1) , have you considered setting a breakpoint at the
particular PC value(s) which generate these errors?
--
John Kohl <jtkohl@ATHENA.MIT.EDU> or <jtkohl@MIT.EDU>
Digital Equipment Corporation/Project Athena
(The above opinions are MINE. Don't put my words in somebody else's mouth!)riley@batcomputer.tn.cornell.edu (Daniel S. Riley) (11/29/90)
In article <1990Nov28.140934.17734@decuac.dec.com> mjr@hussar.dco.dec.com (Marcus J. Ranum) writes: >elliott@veronica.cs.wisc.edu (James Elliott) writes: > >>Now, my problem is that I want to get >rid< of these unaligned >>accesses, because I consider them bugs. > > Amen! The way I used to catch them (this is GROSS) was by doing >what amounted to a binary search with the debugger. I'd set breakpoints >and slowly home in on it until I isolated it. From a posting by Jeff Michaud (michaud@decwrl.dec.com) from a little over a year ago: Finding them is pretty easy. dbx the offending program, then dbx> 0xNNNNNN/10i will tell you the routine-name:linenumber of the offending source line. -Dan Riley (riley@theory.tn.cornell.edu, cornell!batcomputer!riley) -Wilson Lab, Cornell University
meissner@osf.org (Michael Meissner) (11/30/90)
In article <1990Nov28.221219.15331@batcomputer.tn.cornell.edu> riley@batcomputer.tn.cornell.edu (Daniel S. Riley) writes: | From a posting by Jeff Michaud (michaud@decwrl.dec.com) from a little | over a year ago: | | Finding them is pretty easy. dbx the offending program, then | | dbx> 0xNNNNNN/10i | | will tell you the routine-name:linenumber of the offending source line. But this tells you didley squat if the routine happens to be passed a pointer from somewhere else, and it only fails on the 10,000th time the routine is called. -- Michael Meissner email: meissner@osf.org phone: 617-621-8861 Open Software Foundation, 11 Cambridge Center, Cambridge, MA, 02142 Considering the flames and intolerance, shouldn't USENET be spelled ABUSENET?