mao@eden.Berkeley.EDU (Mike Olson) (01/13/91)
i'm running ultrix 4.0 on a decstation 5000/200. dbx misbehaves in the
following way: when dbx tries to print a value that is declared to be
of type char *, but which has an illegal address, it complains and stops
whatever it was doing. this makes it impossible to get stack backtraces
or look at structure contents. here's an example:
(dbx) print *foo
struct {
type = 80
val = union {
name = 0x42f8 = "
[data address 0x42f8 too low (lb = 0x10000000)]
(dbx)
name is of type char *; since this is a union, name doesn't happen to
interest me very much. what i want to see is the rest of the structure
after name. dbx refuses to show me anything else. i know i could do
something like
foo/10X
but it seems a little stupid to use a source-level debugger to get hex
dumps.
this is new to 4.0; on all our other platforms, and under earlier releases
of ultrix, dbx doesn't barf like this. my forlorn question: does anyone
have a workaround? is there any way i can tell dbx to ignore this problem,
and just not print strings with bad addresses? this is a major pain.
mike olson
postgres research group
uc berkeley
mao@postgres.berkeley.edubrian@cimage.com (Brian Kelley) (01/14/91)
In article <10166@pasteur.Berkeley.EDU> mao@postgres.Berkeley.EDU (Mike Olson) writes: >this is new to 4.0; on all our other platforms, and under earlier releases >of ultrix, dbx doesn't barf like this. my forlorn question: does anyone >have a workaround? is there any way i can tell dbx to ignore this problem, >and just not print strings with bad addresses? this is a major pain. I agree. The new dbx is a pain. It also doesn't work with xdbx (that and the lousy DEC keryboard means that our programmers would rather use Suns. (are you listening DEC marketing/sales?)). I wish DEC had left the old version intact. Change a standard tool in several very incompatible ways (and break it in several ways) and not leave the old version around. Real Smart. We do not have any pre 4.0 hosts at our site. Has anyone tried using a version of dbx from a 3.X release under 4.0? What will OSF/1 be shipping as their debugger? > mao@postgres.berkeley.edu --- brian@cimage.com
cks@hawkwind.utcs.toronto.edu (Chris Siebenmann) (01/16/91)
brian@dgsi.UUCP (Brian Kelley) writes: ... | I agree. The new dbx is a pain. Hell, the old dbx was too. Hasn't DEC noticed yet that "help" in dbx fails silently (gee, what great help you have there), for example? I also remember finding some other commands or switches mentioned in the manpage that didn't work, but I've been avoiding dbx in favor of printf for the past while. One of these days I'll have to get the most recent gdb and see if it works; at least I'll have full help and an organization that listens to bug reports sent in via email. In general, DEC seems to grab the MIPS compiler tools, slap them around until they compile and seem to work on Ultrix, and ship the result. I find pixie a bad substitute for gproff, for example, not to mention the fact that it corrupts my programs every now and then, introducing bugs which cause the pixified version to crash when the unpixified one doesn't (a wonderfull boost to my confidence in the numbers it produces, let me tell you). Have I reported these as SPRs? Of course not; see the bit above about "bug reports sent via email". I can't type on a typewriter (I need a DEL key) and we have no secretary around here to type them for me, so my bug reports go forever unfiled. Especially since the form is sized JUST right so that one cannot duplicate it on a normal American laser printer. I suppose I could try to report them through my salescritter, but a) I can't get in touch with said salescritter and b) I trust the salescritter's ability to get important technical details of the bugs right even less than I trust a secretary's. -- "You don't *run* programs on Ultrix." - Mark Moraes "Right, you chase them." - Rayan Zachariassen cks@hawkwind.utcs.toronto.edu ...!{utgpu,utzoo,watmath}!utgpu!cks
frank@croton.enet.dec.com (Frank Wortner) (01/18/91)
> Hell, the old dbx was too. Hasn't DEC noticed yet that "help" in dbx > fails silently (gee, what great help you have there), for example? Works just fine for me. The script output below is from my DECstation 3100 running ULTRIX 4.0 software. Frank Script started on Thu Jan 17 16:03:51 1991 $ dbx enter object file name (default is `a.out'): dbx version 2.0 Type 'help' for help. reading symbolic information ... main: 8 setpwent(); (dbx) help MOST USED COMMANDS quit[!] - quit dbx run arg1 arg2 ... < f1 >& f2 - begin execution of the program stop at <line> - suspend execution at the line [n] cont <signal> - continue with signal return - continue until the current procedure returns print <exp> ... - print the value of the expressions printf "string", exp, ... - print expressions using format string(C) where [n] - print currently active procedures (stack trace) status - print trace/stop/record's in effect func <proc> - move to activation level of <proc> <exp>[/ | ?]<count><format> - display count number of formatted memory items file <file> - change current file to file list <exp>:<int> - list source lines at <exp> for <int> lines sh <shell command> - perform shell command HISTORY, ALIAS, and INPUT/OUTPUT REDIRECTION quit[!] - quit dbx --More--(8%)
cks@hawkwind.utcs.toronto.edu (Chris Siebenmann) (01/22/91)
frank@croton.enet.dec.com (Frank Wortner) writes: | > Hell, the old dbx was too. Hasn't DEC noticed yet that "help" in dbx | > fails silently (gee, what great help you have there), for example? | Works just fine for me. The script output below is from my DECstation | 3100 running | ULTRIX 4.0 software. Bolstered by Frank's evidence that it did work, I went looking for why it didn't work for me. It turns out I had $PAGER set to "less -d" something that seems to work for everything else that uses $PAGER, but fails for dbx (dbx may be doing an exec() call directly instead of using system()). Well, now I feel embarassed, at least somewhat; but I'm still annoyed dbx failed silently and didn't bother printing any sort of error message. -- "Anyone forging articles should be writing news software instead, if you get the headers right you're ahead of some implementations. Try writing a gateway, that'll test your skills." - Ed Vielmetti cks@hawkwind.utcs.toronto.edu ...!{utgpu,utzoo,watmath}!utgpu!cks
rainwatr@ucunix.san.uc.edu (Don Rainwater) (01/24/91)
dbx also has the ability to crash Ultrix 4.0 (maybe this has already been mentioned here). We had a user who was writing a program to open a socket and listen to it. When stepping thru this program with dbx, the socket_accept statement appears to block, so we interrupt it and quit from dbx - BOOM, down goes the system. This is apparently caused by Ultrix trying to deallocate some resource (I want to say file pointers, but I don't remember for sure) that has it doesn't really have (or something like that). This occurs on both VAX Ultrix 4.0 and RISC Ultrix 4.0. This problem appears to be fixed in Ultrix 4.1. -- Don Rainwater, Systems Manager, Univ. of Cincinnati Computer Center Don.Rainwater@UC.Edu rainwatr@ucunix.san.uc.edu rainwatr@ucbeh.bitnet ...!uccba!ucunix!rainwatr