Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!ucsd!ucsdhub!hp-sdd!ncr-sd!noel.cts.com!greg
From: greg@noel.CTS.COM (J. Gregory Noel)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Manx SDB bug (second try)
Message-ID: <2090.AA2090@noel>
Date: 5 Mar 90 00:46:50 GMT
References: <16480@well.sf.ca.us>
Lines: 49

Keith Doyle (keithd@well.sf.ca.us) writes:
>Example program seems to run ok, BUT,
>When using SDB's single-step command "t" on this program, it works ok
>until you get to the "strcpy".  The next "t" command causes the display
>to go black (and I mean black.  Don't think there is even a vert/horiz
>sync).

Sigh.  I, too, would like to know more about this problem.  The example
posted by Keith works just fine on my machine (thin Angus), but I have
seen the symptoms he described too many times and I'd like to know how
to fix it.  I have a program that will run under SDB just fine for several
times, but if I load it under SDB one time too many, the screen goes
completely black as described above.  The only cure is a reboot.

For what it's worth, it's my feeling that the problem is not with SDB per
se, but that SDB does something that tickles the problem area.  It's my
guess that my program has an errant pointer somewhere that is smashing some
DOS structure and that when SDB tries to set up its windows, something ends
up wandering off into never-never land.  Why it would only be SDB that
tickles the problem (the program seems to run just fine as long as I never
use SDB, which is kind of difficult if I'm doing any debugging) I don't
know.

I've also observed that there is an interaction between SDB and improper
argument lists -- I had a case where I could use SDB to single-step through
a particular line of code just fine, but every time I ran it at full speed,
the program would crash.  It took a long time to narrow it down to the line
that failed, at which point the problem was obvious -- the sscanf call had
too many format items for the number of arguments.(*)  I suspect that running
a program under SDB uses the stack beyond the end of the current frame; it
would only be a program like mine with errant arguments that would cause
the problem to occur.

In any event, if anybody has any suggestions as to what or where might be
getting smashed to cause these problems, I'd appreciate knowing.  If needs
be, I can put in something that checks for damage after every line, but only
if I can figure what's going wrong....

Thanks!
-- J. Gregory Noel, UNIX Guru       greg@noel.cts.com  or  greg@noel.uucp

____________________
(*)  Does anybody have a tool that will check formats against the argument
list and vet that the values are OK?  I realize that it cannot be done for
the general case, but even something that handled the simple cases (fixed
format string, no calculations in arguments) would be useful.  In fact, I'd
like to see this as something that the Manx compiler offered; it would
already have the modes of the arguments and it wouldn't be too hard to scan
the format to see if the items matched....  What'd you think, Mike?