home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / sys / hp / 14240 < prev    next >
Encoding:
Internet Message Format  |  1992-12-21  |  1.6 KB
  1. Path: sparky!uunet!zaphod.mps.ohio-state.edu!magnus.acs.ohio-state.edu!usenet.ins.cwru.edu!agate!stanford.edu!unix!hplabs!hp-cv!hp-pcd!news1.boi.hp.com!cupnews0.cup.hp.com!hpscit.sc.hp.com!hplextra!hpfcso!hstroyan
  2. From: hstroyan@hpfcso.FC.HP.COM (Howard Stroyan)
  3. Newsgroups: comp.sys.hp
  4. Subject: Re: bus error problems, how to solve?
  5. Message-ID: <7371500@hpfcso.FC.HP.COM>
  6. Date: 18 Dec 92 18:48:37 GMT
  7. References: <A0W9TOW@math.fu-berlin.de>
  8. Organization: Hewlett-Packard, Fort Collins, CO, USA
  9. Lines: 23
  10.  
  11. In comp.sys.hp, holger@spider.chemie.fu-berlin.de (Holger Busse) writes:
  12.  
  13. > Hello HPNetters,
  14. > does anybody have some information how to search for the origin of
  15. > bus errors, that occur when executing programs.
  16.  
  17. As pointed out in a previous response you are looking for a bad address
  18. usage, most likely due to an alignment issues.  If you happen to wander
  19. into an I/O mapped region of the memory map (like a framebuffer) you can
  20. also produce bus errors.
  21.  
  22. If your code can generate the bus error when compiled debuggable, then
  23. xdb can be used to locate the point of the offense (by executing in
  24. xdb it will break at the point of code which generated the bus error).
  25. If debuggable code does not produce the error, then this is a clue that
  26. an uninitialized variable/pointer is to blame (using debuggable code
  27. has a tendency to implicitly initialize these variables to "nice" values
  28. like zero).
  29.  
  30. --
  31. Howard Stroyan                                         
  32. Hewlett-Packard                                        hstroyan@fc.hp.com
  33. User Interface Technology Division                     
  34.