[futurebasic] Urgent Call DisposeGWorld() Problem

Message: < previous - next > : Reply : Subscribe : Cleanse
Home   : May 1999 : Group Archive : Group : All Groups

From: Peuapeu@...
Date: Thu, 27 May 1999 03:16:13 EDT

I'm in the process of upgrading the FB application that I market.  Somewhere 
during the process, I have introduced a serious bug that causes the program 
to crash in a manner that reminds me of a loose handle (yet, I can find NO 
loose handles).  The code involved is MUCH too long to repeat here but 
essentially there are two "paths" that execution can follow in the program.  
The bulk of the code is in "path1".  If I force only "path1" to be executed, 
over and over, no crash occurs.  If I let the code (as it should) repeat 
"path1" a couple times, then pass through "path2" ONCE before returning to 
repeating "path1", then a crash will eventually occur.  It may happen after 
only 1 cycle of "path1" following the "path2" detour, or it may take dozens 
of additional "path1" cycles before the crash occurs.

You would think that given the above one would be able to isolate what 
portion of the "path2" is causing the problem.  Believe me, I have tried but 
so far I have not succeeded.  I've examined the code countless times over 
several months and stepped through the "path2" code carefully using the FBII 
debugger.  I do not see any reason for this to occur.  All the handles appear 
to be correctly created and disposed of, there are no overflows of strings or 
arrays, locking and unlocking appears to be done correctly, etc.  I have also 
tried moving the section of the code where the crash actually occurs around 
in the hopes of locating the problem.  That has not worked primarily because, 
as I said, the crash happens after a varying number of (post "path2") "path1" 
cycles.  Thus, whatever the bug is, it doesn't happen every time the causing 
statement(s) is(are) called.

The crash always happens in a Call DisposeGWorld(handle&) statement.  Note 
that the code passes through this statement dozens of times, with an 
identical sequence of steps, before the crash occurs at this statement.  I 
print any handle& used in the DisposeGWorld call both when it is created and 
just before the DisposeGWorld call.  In all cases, the handle (a global 
variable) exists and is correct.  I know it has not been disposed of 
previously because I set my handles to zero immediately after all handle 
disposal calls.  I even ran the debugger with a breakpoint anytime a handle 
that will eventually be passed to the DisposeGWorld routine is used to verify 

To check whether the area of memory containing the DisposeGWorld routine 
itself is ok, I placed a separate pair of FN NewGWorld() and DisposeGWorld 
calls immediately before the problem DisposeGWorld statement.  The test 
always works correctly so I know the DisposeGWorld routine is working just 
prior to the crash.

I have also tried using Macsbug.  I've run the code on both a Powerbook 540c 
with OS 7.1 and a G3 with OS 8.1.  On the G3, after executing "path2", 
Macsbug breaks out (sometimes several times) with the following: 
"DisposeHandle on a handle with a resource bit set".  A "g" continues the 
execution with no apparent problem.  Eventually, however, Macsbug breaks out 
in a non-recoverable fashion with either the message "PowerPC access 
exception at ######## - HSetStateQ + 01810" or "Bus Error at ######### 
_DisposeGDevice while reading 3 bytes from ####### in User Data Space".  Both 
cases occur at the Call DisposeGWorld statement with what appears to be a 
valid handle.   On the Powerbook, Macsbug only breaks out in a fatal error 
with the message "Bus Error at ###### _NewGDevice + 000B4".   Can anyone give 
me an idea what these message might imply?

I've also examined the heap (using Macsbug) throughout the run and after the 
crash.  There is no sign that any part of the heap is growing (like it might 
if there were handles that weren't being disposed of properly) and Macsbug 
also says the heap is "ok".  The program runs the same when the heap is 
scrambled (i.e., no crash if only "path1" and a crash in about the same 
amount of cycles if once through "path2").  Increasing the RAM allocated to 
the program also doesn't make a difference.

I'm at a loss so I'm hoping someone can give me a clue as to how I might 
proceed.  Do the error messages or the statement where the crash occurs 
suggest anything? Is there a way to break out into the debugger if the 
contents of a location in memory referenced by a handle is changed, rather 
than only if the value of the handle itself changes?  If I could monitor 
changes to the contents of memory, perhaps I can find the line of code that 
changes (but shouldn't) the memory referenced by the handle. Finally, if all 
else fails, is there someone who is a lot more experienced in debugging who 
might be interested in actually looking at the code itself?


James Schumacher