Program Crash

[Steve Bouffe]

I have a very large application that crashes and simply closes without windows displaying a dialog stating that the application has caused an illegal opperation.

I've got TOOLS ON so all array bounds checking is on. I've added error traps also. I can get the program to crash with certain opperations but when I add atrace function and perform the same sequence, the program runs ok.

Any suggestions what to do next?

[Dave Biggs]

Have you tried running your program with

#DEBUG ERROR ON ?

That will cause error code 9 "Subscript/Pointer out of range" to be generated and the errant statement itself to be skipped, should you be getting 'out of bounds'.

[Michael Mattias]

I've had that happen a couple of times... I've had two different causes...

1. A stack corruption problem (caused by Array bounds violations)
2. Including the same procedure name in both the current module and DECLAREing it as EXTERNAL ( a compiler problem, now fixed I think), which I think led to ... stack corruption.

When the stack is corrupted all kinds of weird things can happen. "With luck" the GPF detail will report a stack fault, but you usually just get good ol' 0x00000005 ... attempt to access unowned memory.

MCM

[Bill Scharf]

switch OS's

Steve,

This is just a guess, but if might be worth running the program on different versions of Windows. I have seen such errors on Win 9x that were handled better by newer operating systems. The normal PB error handling would work on XP/Vista when it would not in 98/ME etc.

[Bob Zale]

PowerBASIC error processing works the same on all versions of Windows.

By far, the most likely cause is an array bounds error or a nul pointer. #TOOLS ON does not enable error checks. Error checks are enabled with #DEBUG ERROR ON.

Best regards,

Bob Zale
PowerBASIC Inc.

[Steve Bouffe]

I have enabled tools and debug. I presume that when trace is enabled then the compiled program is different when trace is not turned on?

This has been a problem for several years. As I'm developing the program and adding more features, the problem will go away. And then when I add further features, the problem comes back. So It must be some sort of corruption.

So all array bounds are being caught.

#COMPILE EXE
#DIM ALL
#DEBUG ERROR ON
#TOOLS ON

[Rodney Hicks]

In creating the latest problem, what features were added to the existing error free application, more specifically, what code was added and in there you are more likely to find the cause. When did you last have it running error free?
Bear in mind that the recent code that seems to be creating the error may just be activating the error condition which was coded earlier(This seems likely since the problem has come and gone for years).
So, since we have no code to analyze, remove the new features in the reverse order to which they were added until the error disappears.
Not likely to be fun, unless you enjoy learning from mistakes!
As an afterthought, have you had Windows Task Manager running to check memory usage, etc.(or other tool)

[Dave Biggs]

Does your program still crash with #DEBUG ERROR ON ?

If not, then you will need to include Error Traps in each of your Functions / Subs and figure out which statement is now being skipped (that'll be the one that's causing the "Subscript/Pointer out of range" Error 9.

[Steve Bouffe]

Yes program still crashes with #DEBUG ERROR ON

I have an error trap in every SUB and FUNCTION

[Gösta H. Lovgren-2]

Here's what I find easy for difficult error (or variable) tracking. Open a tracking file. Then insert a print statement (pf "At Here") at at strategic points in the program. Using a Macro makes it super easy. Run the program then look at the tracking file with a text editor to see the last place the program was before it crashed. Or what the variable value was. Or ... .

Here's example code:

'
Macro ptf = If g_Track_File Then Print #g_Track_File,   
'
Function PBMain () As Long
  'Rem next line unless needed to look for errors or variable tracking
Global g_Track_File As Long: g_Track_File = FreeFile 
'
  If g_Track_File Then ' 'Only opened if g_Track_File assigned
    Open CurDir$ & "\A_Trace.txt" For Output As #g_Track_File
  End If
'
  ptf "In PBMain" 'does nothing unless g_Track_File has been assigned
End Function

At strategic points in the program insert "ptf (appropriate msg)". Now you will know after which Appropriate Msg the program crash/error occurs. With subsequent runs you can narrow it down even further.

============================================================
"There are many people who are always anticipating trouble,
and in this way they manage to enjoy many sorrows
that never really happen to them."
Josh Billings (1818-??)
============================================================

[Michael Mattias]

>So all array bounds are being caught.

Well, just adding #DEBUG ERROR ON is not quite enough. All this does is change the behavior of any statement using an array subscript or pointer variable. You still have to add code to DETECT and REACT to the ERROR 9 which will be generated because #DEBUG ERROR ON is in effect. (code not shown).

However, your analysis that it "must be some kind of corruption" is quite likely spot-on.

MCM

[colin glenn]

Yes program still crashes with #DEBUG ERROR ON

I have an error trap in every SUB and FUNCTION

Ah, doesn't this only trap PB internal errors? If the program up and closes on you without generating any type of popup dialog, either from the program or from windows, then it's possible that some SDK call did not like the parameters and invoked a function in windows to abort what it was called to do, and windows will close the application. (I think.)

[Michael Mattias]

Ah, doesn't this only trap PB internal errors? If the program up and closes on you without generating any type of popup dialog, either from the program or from windows, then it's possible that some SDK call did not like the parameters and invoked a function in windows to abort what it was called to do, and windows will close the application. (I think.)

No.

Windows will not terminate a program 'abnormally' without reporting it.

In this case the program ended because your logic got to the end, or there was a stack fault when YOUR program was trying to do something (eg handle a trapped error)

try enabling TRACE in WinMain and run that way. Trapped errors should show up witout you having to do anything. If nothing else, it will show you the last procedure which was entered.

e.g....

#TOOLS ON 
FUNCTION PBMAIN () AS LONG 

  TRACE NEW 
  TRACE ON 

  DIALOG NEW 
   ...
  DIALOG SHOW 


  TRACE CLOSE (OFF? END? It's one of these)

END FUNCTION

MCM

[Michael Mattias]

One other thing can cause this... the use of the END statement somewhere.

(I never liked that there was an END statement in the Windows' product).

[Steve Bouffe]

Thats the poblem, the program closes everytime whn I execute the same functions and button clicks. When I enable the trace (it take a very long time to test) the program opperates perfectly without crashing/closing. As soon as I disable the trace, the crash is back.

[colin glenn]

Try this then, run trace, but instead, TRACE OFF as soon as you start the trace file. Then at the start of each function / sub:
TRACE ON
TRACE PRINT CALLSTK$(1)
TRACE OFF

According to the help:
CALLSTK$(1) returns the name of the current Sub, Function, Method, or Property, and the value of each of the parameters at the time it was called. CALLSTK$(2) returns the name of the procedure which called the current one, as well as its parameters. Likewise, CALLSTK$(3) returns the one above it, and so forth.

And if for some that won't work correctly, you might want to make a MACRO which does the whole:
MACRO TraceIt(fName)
TRACE NEW fname$
TRACE ON
TRACE PRINT fName
TRACE OFF
TRACE CLOSE
MACRO END

[Michael Mattias]

When I enable the trace (it take a very long time to test) the program opperates perfectly without crashing/closing. As soon as I disable the trace, the crash is back.

Is this program multi-threaded, multi-window (re-entrant) or otherwise doing something which is "time-dependent" or depends on some kind of synchronization?

This really sounds like you are doing something which depends on something else having been completed when you do it, but it isn't.

[Gösta H. Lovgren-2]

Thats the poblem, the program closes everytime whn I execute the same functions and button clicks. When I enable the trace (it take a very long time to test) the program opperates perfectly without crashing/closing. As soon as I disable the trace, the crash is back.

Steve, after all this time (and trouble) not finding the problem with TRACE, DEBUG (and all its associated overhead), why not give the Text file method (posted above) a shot? Simple to do. Might take several runs to narrow down to the problem line(s) simply by adding/deleting PTF "here" lines on each run.

Has always (almost anyway )worked for me (and I introduce A LOT of problems {sigh}). Worst can happen is it doesn't work for you in this case.

Unless it is something like an obscure Bounds error which corrupts another part of memory (but you've eliminated Bounds as a culprit. Haven't you?)

=============================================
If a man will begin in certainties
he shall end in doubts;
but if he will be content to begin in doubts
he shall end in certainties.
Sir Francis Bacon
=============================================

[Michael Mattias]

>(but you've eliminated Bounds as a culprit. Haven't you?)

Code not shown.

[Cliff Nichols]

Actually at this point I have to agree...unless you can replicate the problem in smaller parts, or post the whole thing.

Code NOT shown is the route to go...and no one can help without seeing either the exact model, or a model that replicates

Take it from one that often thinks (or thought) I could not break it down, but when I could find a simple example...either solved it on my own, or was able to demonstrate the problem

Do NOTTTTT be afraid of the CNDS.....it helps in the long run