Tracing large program under dbx

[andrew simmons]

I'm having a problem with trying to debug someone else's large complex C
program (6000 lines in 14 files). I'm running on a Sun4 and have tried
using both 4.0.3 with a dbx/dbxtool patch and 4.1. The program crashes
because a local variable obtains a spurious value, probably as the result
of being overwritten by an assignment to another variable. I am attempting
to use trace to determine at which point the variable acquires this
spurious value. After several hours of chugging dbx/dbxtool reports the
variable change as occurring at a return from a function which makes no
sense to me. 

My friendly Sun Support person has tried to help, but all we've succeeded
in doing is to identify further (unrelated) bugs in dbx/dbxtool. He tells
me that Sun has a bug report of trace under 3.5 where changes of variable
values were reported up to 10 lines late. He thinks that this problem was
not more widely reported because it probably only happened to large
programs. I've tried looking ten lines or so back in the code, but the
control is very complex, and its almost impossible to stop the code 10
lines earlier. The size of the program means a few traces of other
variables means at least a six hour debugging session, which I have tried
but to no avail.

What I'd like to know is if anyone else has encountered this - or can
explain why a variable might *really* change on a return, or suggest any
other way of solving my problem that doesn't require 15 hours of terminal
time. I've looked at gdb, but it doesn't really have the facilities for
tracing variables.  Please reply by e-mail to me and I'll summarise to the
net if there is sufficient interest. 

Thanks for any help.

JANET    : andys at uk.ac.ucl.sm.mph
INTERNET : andys at .mph.sm.ucl.ac.uk
BITNET   : andys%uk.ac.ucl.sm.mph at ukacrl.bitnet