Announcement

Collapse
No announcement yet.

Setting a variable crashes the program

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

  • Setting a variable crashes the program

    I'm a bit baffled by this, hoping it's one of those esoteric compiler quirks that someone has come across before. I cannot post the program source code. It is a FireFly project with a couple dozen forms and modules. However, here are the relevant lines:

    Code:
    local TrafficDate   as string
    local Deferred      as string
    
    '
    '  Code to go get some data from the database
    '
    '
    DebugLog Using$("&: Order # part & TrafficDate '&' (#) deferred '&'", _
                          FuncName$, Salesorder, PartNum, TrafficDate, Len(TrafficDate), Deferred)
    '
    'Results from above:
    '  OPENORDERS_REFRESHORDERSLIST: Order 907298 part CR0531AD919SC00 TrafficDate '' (0) deferred 'Y'
    
    ' Bud change 11/5/19
        If Deferred = "Y" Then
          If Len(TrafficDate) = 0 Then
            TrafficDate = "Deferred"  '< problem line
          End If
        End If
    When program execution hits the problem line, the program immediately crashes. if I comment that line out, no crash. I'm using PB/Win 10.04. Just looking to see if anyone has seen similar behavior and what the solution was. Turning on the #Tools and #Debug Error yeilds no insight.
    Real programmers use a magnetized needle and a steady hand

  • #2
    HI Bud.

    What is the DebugLog line? did you mean to include it?

    With that gone, the remaining lines of code do not fail here.

    Are you able to extract code that fails as it does in your larger app?

    Comment


    • #3
      "I'm a bit baffled by this, hoping it's one of those esoteric compiler quirks"

      I'll bet you anything you like that it's a "programmer quirk", not a compiler quirk.

      Are you using #DIM ALL ?




      Comment


      • #4
        Try testing for error(s) before crash line, IF ERR THEN ... Sometimes a "hanging" error can cause crash later in a program. Can be very hard to find - hate when that happens. Also maybe try #DEBUG ERROR ON at top of code to check for array boundary errors or null-pointer errors anywhere in code.

        Comment


        • #5
          This sounds like a classic case of memory corruption. Somewhere your program is doing something naughty, and setting the stage for a crash later. I predict that if you add a few lines of code the problem will disappear, only to reappear later. Tough to find the cause, it usually has nothing to do with the line of code that appears to be crashing, like setting a variable.
          "Not my circus, not my monkeys."

          Comment


          • #6
            Originally posted by Gary Beene View Post
            What is the DebugLog line? did you mean to include it?
            DebugLog is my tool for writing stuff to a log file so I see what's going on. The Line below it is the Output that s written; there to show that the Problem variable is an empty string. When extracted to stand alone, it compiles and works just fine, which is makes it more baffling for me. That, and this is such a simple piece of code; just storing a string.

            Stuart McLachlan -- yes, using #DIM ALL, and as the sample code shows, the variables are declared local. As noted in the OP, there is no useful compilable example that causes the failure, as I can't post the program that fails in it's entirety, and on it's own this code does not fail. I've been using PB since it was TB, and always look for a 'developer quirk' first, then look again until I find it, but in this case I could not after an hour of looking. So I reached out, just in case it may be a known issue.

            Borje Hagsten -- I hadn't thought about using error trapping; it didn't cross my mind since the program is not throwing any run-time errors. I'll give it a shot.

            Eric Pearson -- That was kinda my thought, but I seemed to recall others reporting a similar type of mystery, related to use of MSGBOX, but I could be wrong. I did try moving the code block to a different location in the source, but the problem persisted.

            Needing to move on, I updated my SQL query so that when the variable is initially set with SQLTools' SQL_ResultColumnString() function, it has the value it needs. If I have time tomorrow, I'll try to duplicate and properly solve the problem.
            Real programmers use a magnetized needle and a steady hand

            Comment


            • #7
              #DEBUG DISPLAY ON
              #DEBUG ERROR ON

              Might be a DIM OR REDIM out of bounds.
              https://duckduckgo.com instead of google

              Comment


              • #8
                Well Bud, I gotta say you are a lot better programmer than I. I too started with Turbo Basic, 3.2 million years ago it seems. "after an hour of looking"...is so much better than my "weeks of looking" for a silly 'I'm sure it was a bug' that I created. On further thought, the ratio of 1 hour-~30 years may be the same as weeks-~3.2 m years.

                My favorite cure is Mike's suggestion #DEBUG DISPLAY ON, and the whole code peppered with labels.
                Rod
                "To every unsung hero in the universe
                To those who roam the skies and those who roam the earth
                To all good men of reason may they never thirst " - from "Heaven Help the Devil" by G. Lightfoot

                Comment


                • #9
                  Rodney, my old son

                  You are teasing us

                  But I think I agree. As soon as you stop saying 'the compiler has a bug' and start saying 'where have I stuffed up?' then the sooner you will find the bug. It is hard. It is demeaning. It is programming! I love being a programmer and this is one of the reasons why.
                  [I]I made a coding error once - but fortunately I fixed it before anyone noticed[/I]
                  Kerry Farmer

                  Comment


                  • #10
                    Yes Kerry, I jest a lot. Still as humiliating as proving myself to have erred is, there is oft times a feeling of euphoria at finding my errant magnetized needle in my haystack of code that kind of makes up for it. So far, I've always managed to stop short of running through the streets naked shouting "Eureka! Eureka!"
                    Rod
                    "To every unsung hero in the universe
                    To those who roam the skies and those who roam the earth
                    To all good men of reason may they never thirst " - from "Heaven Help the Devil" by G. Lightfoot

                    Comment


                    • #11
                      Try running it in the debugger. Use 'Compile and Debug current file' and then just 'run'. Watch the window at the bottom of the IDE. This usually pops up object or bounds errors when they first occur instead of when it becomes critical. It has saved me a few times.

                      Comment


                      • #12
                        Hi Bud,
                        Try following options:
                        1. Disable any optimizations.
                        2. Try following scenarios:

                        Code:
                        $DEFERRED_STATE = "Deferred"
                        '
                        '
                        IF LEN(TrafficDate)=0 THEN
                            DebugLog STRPTR(TrafficDate)   ' ' ' <--- check for string address
                            TrafficDate = CHR$(0)
                            TrafficDate = $DEFERRED_STATE
                        END IF
                        Check for threads state if any (I don't think that thread may affect this piece as these variables declared as local)

                        Good luck!

                        Comment


                        • #13
                          I agree with Eric on this one. Likely memory corruption. I had this myself once and I spent days tracking it down. Turns out I Dimensioned an array and then accessed it out of bounds later on. This corrupted memory but did not crash the app. Later in another part of the app, it finally crashed at code which was fine. When I would REM out lines of code where it did crash, then it would crash elsewhere. The problem code was actually far away from the code where it actually crashed.

                          Start by adding #DEBUG ERROR ON

                          I don't normally use this, but learned the hard way that it can find some problems. But not all memory corruption errors will be caught by this.
                          Chris Boss
                          Computer Workshop
                          Developer of "EZGUI"
                          http://cwsof.com
                          http://twitter.com/EZGUIProGuy

                          Comment


                          • #14
                            See this thread about random memory error, just in case...
                            http://www.jose.it-berater.org/smffo...21840#msg21840

                            in my case array scan was the culprit (since the introduction of powerarray)
                            Patrice Terrier
                            www.zapsolution.com
                            www.objreader.com
                            Addons: GDImage.DLL 32/64-bit (Graphic library), WinLIFT.DLL 32/64-bit (Skin Engine).

                            Comment


                            • #15
                              Originally posted by Eric Pearson View Post
                              This sounds like a classic case of memory corruption. Somewhere your program is doing something naughty, and setting the stage for a crash later. I predict that if you add a few lines of code the problem will disappear, only to reappear later. Tough to find the cause, it usually has nothing to do with the line of code that appears to be crashing, like setting a variable.
                              There is an approach which always works with this sort of problem, or suspected problem, and that is to bypass or comment out large then successively smaller blocks of code as the cause of the corruption is narrowed down, in the manner of a binary search. If you must have the results which a sub or function returns, but you want to test without running their code, you just have to spoof them, which is usually very easy.

                              Comment


                              • #16
                                Chris

                                You are absolutely right. Comment out the subroutine and provide a reasonable but made up result. Done it often
                                [I]I made a coding error once - but fortunately I fixed it before anyone noticed[/I]
                                Kerry Farmer

                                Comment


                                • #17
                                  Originally posted by Chris Boss View Post
                                  I had this myself once and I spent days tracking it down.

                                  Start by adding #DEBUG ERROR ON
                                  #DEBUG ERROR and #DIM ALL gave no joy, and I wish I had the kind of time to spend days tracking down a problem that has never shown up before, that I couldn't track down using methods you describe, looking for the usual suspects -- arrays and pointers. A problem that showed up this time after adding only the lines shown above (the stuff under 'bud change'). Removing the addition lines -- actually the 'problem line' -- removed the crash completely, it didn't just move it elsewhere. I tested as many of the other functions as I could to confirm that, and I'm certain if there was a chronic crash, one of my users would have spoken up. I am exceptionally careful to declare variables, never reference arrays out of bounds (crashed a mainframe 30 years ago with that, so..), use critical sections when referencing globals and so forth.

                                  I used a different set of statements later on in the code to get what I wanted, and got on with it. I will learn to live with the knowledge that I have an issue somewhere. As it is, the program is behaving correctly, not garbling data on reports or screens, and is well behaved. Someday, perhaps I will have time to try to duplicate this problem again. No doubt there is something somewhere that I'm doing wrong, or perhaps there's an issue with some setting I put on a control that causes the code generated by FireFly to do something it shouldn't. But, I've learned my lesson. Never, ever, ever again will I imply that the PB compiler is less than 100%

                                  Real programmers use a magnetized needle and a steady hand

                                  Comment


                                  • #18
                                    There is one way to speed up finding such a bug. The bug, if it is associated with a bad pointer variable for example, will only occur if that section of code is executed. One way to test for this is to run the app and document all the steps you take in running the app before it crashes. Then rerun the app again and avoid just a few of the steps and see if it crashes. If it does, then rerun the app and avoid a different step. At some point you may be able to run the app and if you always avoid a specific step, the app runs and does not crash. Now look at the code for that specific task or step in the app and go through it line by line looking for possible candidates for passing a bad pointer or an array out of bounds. Look for WIN32 calls in the code, the use of any WIN32 structures (many have pointers in them) and also for arrays. By finding which task makes the app unstable, even though it crashes elsewhere, you can often find the block of code where the problem lies. You can REM out blocks of code (or add compiler directive to keep code from compiling in) to keep out large blocks of code. Then compiel and run and see if the app still crashes.

                                    There is a "method to the madness". It may see, time consuming at first, but if done right it can be done quickly enough to make it worth the time.
                                    Chris Boss
                                    Computer Workshop
                                    Developer of "EZGUI"
                                    http://cwsof.com
                                    http://twitter.com/EZGUIProGuy

                                    Comment


                                    • #19
                                      Bud,
                                      Another noninvasive method I use is to admit the overwhelming error and go back to a previous version that ran smoothly. Then modify that version testing as you go. Not easy I know. But fruitful. In fact that is what I am doing right now.

                                      Comment


                                      • #20
                                        Originally posted by Bud Durland View Post
                                        I wish I had the kind of time to spend days tracking down a problem
                                        Hate to sound negative but then programming isn't the best line of work for you then :-)

                                        Troubleshooting, sometimes tedious and time consuming, is part and parcel to programming. Without seeing the entire code, or at minimum the smallest compileable version that still shows the error, there is not much we have to go on to help you.
                                        <b>George W. Bleck</b>
                                        <img src='http://www.blecktech.com/myemail.gif'>

                                        Comment

                                        Working...
                                        X