Announcement

Collapse
No announcement yet.

Program Crash

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Program Crash

    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?

  • #2
    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'.
    Rgds, Dave

    Comment


    • #3
      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
      Michael Mattias
      Tal Systems (retired)
      Port Washington WI USA
      [email protected]
      http://www.talsystems.com

      Comment


      • #4
        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.
        Bill Scharf

        Comment


        • #5
          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.

          Comment


          • #6
            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.

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

            Comment


            • #7
              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)
              Last edited by Rodney Hicks; 23 Mar 2009, 05:55 AM.
              Rod
              In some future era, dark matter and dark energy will only be found in Astronomy's Dark Ages.

              Comment


              • #8
                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.
                Rgds, Dave

                Comment


                • #9
                  Yes program still crashes with #DEBUG ERROR ON

                  I have an error trap in every SUB and FUNCTION

                  Comment


                  • #10
                    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:

                    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-??)
                    ============================================================
                    Last edited by Gösta H. Lovgren-2; 23 Mar 2009, 08:44 AM.
                    It's a pretty day. I hope you enjoy it.

                    Gösta

                    JWAM: (Quit Smoking): http://www.SwedesDock.com/smoking
                    LDN - A Miracle Drug: http://www.SwedesDock.com/LDN/

                    Comment


                    • #11
                      >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
                      Michael Mattias
                      Tal Systems (retired)
                      Port Washington WI USA
                      [email protected]
                      http://www.talsystems.com

                      Comment


                      • #12
                        Originally posted by Steve Bouffe View Post
                        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.)
                        Furcadia, an interesting online MMORPG in which you can create and program your own content.

                        Comment


                        • #13
                          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....
                          Code:
                          #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
                          Tal Systems (retired)
                          Port Washington WI USA
                          [email protected]
                          http://www.talsystems.com

                          Comment


                          • #14
                            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).
                            Michael Mattias
                            Tal Systems (retired)
                            Port Washington WI USA
                            [email protected]
                            http://www.talsystems.com

                            Comment


                            • #15
                              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.

                              Comment


                              • #16
                                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
                                Last edited by colin glenn; 23 Mar 2009, 05:58 PM.
                                Furcadia, an interesting online MMORPG in which you can create and program your own content.

                                Comment


                                • #17
                                  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.
                                  Michael Mattias
                                  Tal Systems (retired)
                                  Port Washington WI USA
                                  [email protected]
                                  http://www.talsystems.com

                                  Comment


                                  • #18
                                    Originally posted by Steve Bouffe View Post
                                    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
                                    =============================================
                                    It's a pretty day. I hope you enjoy it.

                                    Gösta

                                    JWAM: (Quit Smoking): http://www.SwedesDock.com/smoking
                                    LDN - A Miracle Drug: http://www.SwedesDock.com/LDN/

                                    Comment


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

                                      Code not shown.
                                      Michael Mattias
                                      Tal Systems (retired)
                                      Port Washington WI USA
                                      [email protected]
                                      http://www.talsystems.com

                                      Comment


                                      • #20
                                        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
                                        Engineer's Motto: If it aint broke take it apart and fix it

                                        "If at 1st you don't succeed... call it version 1.0"

                                        "Half of Programming is coding"....."The other 90% is DEBUGGING"

                                        "Document my code????" .... "WHYYY??? do you think they call it CODE? "

                                        Comment

                                        Working...
                                        X