vasudev@DECVAX.DEC.COM (02/29/88)
Our experience has shown that dbx itself is not a perfect example of robust code either. Dbx barfs on very large object modules with a large number of symbols with and ->Internal Table Overflow<- or by just plain lying about what its doing. We have had the good luck of being supported by an outstanding engineer who has fixed many bugs in dbx. To get back to Server Debugging, we have also found it very useful to identify specific modules within the server that you guess to be bogus and then compile those with the -debug option. dbx works wonderfully in such cases. When all else fails, there ain't nuttin' like good ole printf. -Vasudev
tower@bu-cs.BU.EDU (Leonard H. Tower Jr.) (03/03/88)
X-UUCP-Path: ..!harvard!bu-cs!tower In article <8802291359.AA01925@flume.dec.com> vasudev@DECVAX.DEC.COM writes: |Our experience has shown that dbx itself is not a perfect example |of robust code either. Dbx barfs on very large object modules with |a large number of symbols with and ->Internal Table Overflow<- |or by just plain lying about what its doing. We have had the good |luck of being supported by an outstanding engineer who has fixed |many bugs in dbx. | |-Vasudev I suggest you try gdb, the GNU DeBugger, if you are unhappy with dbx's faults, or just want a better debugger. The latest version 2.5 (released with version 18.50 of GNU Emacs) runs on: m-isi-ov.h m-sun3.h m-vax.h m-merlin.h m-sun2.h m-news800.h m-umax.h Information on obtaining gdb via ftp or tape can be gotten from: gnu@prep.ai.mit.edu enjoy -len