Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!tut.cis.ohio-state.edu!osupyr!vkr From: vkr@osupyr.mps.ohio-state.edu (Vidhyanath K. Rao) Newsgroups: comp.sys.amiga.tech Subject: Re: Manx SDB bug (second try) Message-ID: <1425@osupyr.mps.ohio-state.edu> Date: 6 Mar 90 20:30:41 GMT References: <16480@well.sf.ca.us> <2090.AA2090@noel> Reply-To: Vidhyanath K. Rao Organization: None Lines: 28 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). In article <2090.AA2090@noel> greg@noel.CTS.COM (J. Gregory Noel) writes: ->...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 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.-- It is the man, not the method, that Nath solves the problem. vkr@osupyr.mps.ohio-state.edu -Poincare. (614)-366-9341