🚀 go-pugleaf

Keith Doyle (keithd@well.sf.ca.us) writes:
->[describes a problem]... causes the display
->to go black (and I mean black.  Don't think there is even a vert/horiz
->sync).

I write:
->...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.

Vidhyanath K. Rao (vkr@cis.ohio-state.edu) writes:
>I had problems when trying to debug the optimised code: With all the possible
>optimisations turned on, SDB would crash, but the program ran fine if run
>directly. SDB would work fine with no optimisations. But when the "-so"
>option was used, SDB would either crash before doing anything, or at the
>first "t" or "s" command.-- 

This isn't it.  I've also had problems debuging optimized code, but at least
the manual documents it as a potential problem area, so when I had problems
with optimized code, I'd try it unoptimized.  But in the case I'm describing,
I didn't even recompile the code, just ran SDB on the same binary I had been
debugging before.

In fact, the way I discovered the problem was by noticing that every time I
ran a particular program before running SDB, SDB would crash even before
displaying the initial screen.  When I would test that program under SDB
(with optimization on or off, it didn't seem to matter) I could test it some
random number of times and then the screen would go dark as SDB loaded.  The
program that causes the problem doesn't do anything exciting, only uses
stdio.h for I/O, malloc()s only a small amount of storage, checks the return
from all resource allocations, returns all resources exactly once, and doesn't
have any stray pointers I can find, so I'm stumped.
-- 
-- J. Gregory Noel, UNIX Guru       greg@noel.cts.com  or  greg@noel.uucp