Announcement

Collapse
No announcement yet.

Sudden memory problem with one of my progs

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

  • #21
    You’re right.

    1. Lots of people are getting this problem
    2. They get it with previously working programs of all sorts
    3. It happens most often on program closure
    4. No one knows what is causing it
    5. Some people know what is not causing it

    Comment


    • #22
      >I TRACE from the point of receiving a %WM_CLOSE in the main window procedure.

      Corruption could have occurred prior to that.

      It often happens that the 'actual' memory access error/corruption occurs in one part of the program but does not have any noticeable effects until 'sometime later.'

      You need to trace an entire program run, one which ends with the error.

      And if I can make a suggestion here... try compiling with #DEBUG ERROR OFF for this run. This will generate Error 9 or GPF IMMEDIATELY since the compiler will make the attempt at that time. (ADDED: Duh, no it won't generate Error 9.. but it will generate immediate GPF on a page fault)

      With #DEBUG ERROR ON, offending PB statements are not even attempted... which can result in some variable of yours not being assigned any value at all, meaing it is "undefined." What happens in your program when some variable is "undefined" is, .. is... well, I guess it's "undefined". At at very least it must be Not Good.

      MCM
      Last edited by Michael Mattias; 24 Oct 2007, 01:55 PM. Reason: fixed comment re error 9 with #DEBUG ERROR OFF
      Michael Mattias
      Tal Systems Inc. (retired)
      Racine WI USA
      [email protected]
      http://www.talsystems.com

      Comment


      • #23
        I’ve just tried #DEBUG ERROR OFF and it makes no difference.

        Corruption could have occurred prior to that.
        It often happens that the 'actual' memory access error/corruption occurs in one part of the program but does not have any noticeable effects until 'sometime later.'
        Yes, I am familiar with this. Forgive me for displaying a bit of conceit but my gut feeling is there is nothing wrong in the program. As I said before, it’s marketed and in use. All right, maybe few have actually used it (that’s possible) or there is a fault that’s been lurking there all the time (as you suggest). I will have a go at a more extensive TRACE tomorrow.

        I appreciate your help
        Keith

        Comment


        • #24
          You need to trace an entire program run, one which ends with the error.
          I tried tracing an entire program run but it only gets as far as showing its main window and then just sits there without displaying any child windows. I killed it and then looked at the partial trace file.

          With #DEBUG ERROR ON, there are a quite a few occurrences of Error 9. They are all associated with calling CreateWindow, for example,

          Code:
          CREATEWINDOW(COMBOBOX,,1344274754,54,2,209,200,4195430,31,4194304,0)
          Error 9 was generated in this thread
          the offending code being,

          Code:
          m_TbCombo.hWnd = CreateWindow ("COMBOBOX",_
                                       BYVAL %NULL,_
                                       %WS_VSCROLL   OR _
                                       %WS_CHILD     OR _
                                       %WS_VISIBLE   OR _
                                       %CBS_DROPDOWN OR _
                                       %CBS_SORT     OR _
                                       %CBS_AUTOHSCROLL, _      'For edit field
                                       rWnd.nLeft, rWnd.nTop,_
                                       rWnd.nRight  - rWnd.nLeft,_
                                       rWnd.nBottom - rWnd.nTop,_
                                       hwndP,_
                                       idCombo,_
                                       hInst,_
                                       0)
          CreateWindow is defined in the WIN32API.INC as a wrapper function for CreateWindowEx. I tried calling CreateWindowEx directly as shown here and the error no longer occurs.

          Code:
          m_TbCombo.hWnd = CreateWindowEx (0, "COMBOBOX",_
                                       BYVAL %NULL,_
                                       %WS_VSCROLL   OR _
                                       %WS_CHILD     OR _
                                       %WS_VISIBLE   OR _
                                       %CBS_DROPDOWN OR _
                                       %CBS_SORT     OR _
                                       %CBS_AUTOHSCROLL, _      'For edit field
                                       rWnd.nLeft, rWnd.nTop,_
                                       rWnd.nRight  - rWnd.nLeft,_
                                       rWnd.nBottom - rWnd.nTop,_
                                       hwndP,_
                                       idCombo,_
                                       hInst,_
                                       BYVAL 0)
          I did this for all occurrences of CreateWindow and then ran the program again and waited for some time before killing it. The trace file (approaching 700 Kbyte) contained no errors. Then I ran the program with trace off and exited in the normal way. There is no difference – I’m still getting the same “The instruction at ##### referenced memory…” message box popping up.

          So, I still haven’t found the remedy to this problem.

          As an aside, this begs a question; is it good to have CreateWindow and CreateWindowEx defined/declared differently in WIN32API.INC so that they behave differently when passed a %NULL for the lpWindowName argument?

          Comment


          • #25
            I can't believe I did not ask this before, but for your debugger, do you have the "Break on Error" checked? (I found mine unchecked in the Window-->Options menu then the Compiler tab.)

            With it checked you can debug and run until an error occurs and then check to see why you got an error.
            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


            • #26
              Debugger? I never use debuggers. I’m one of these old fashioned people that believe in msgbox, or ConPrint (printing to a console) or other such crude methods such as TRACE, or going for a walk and thinking.

              Tonight I set the program running with TRACE ON from the top of the WinMain function (no TRACE OFF anywhere), and just left it for approximately half an hour. By this time program had shown its full face. I clicked the top-right X to exit. Result – exactly as before; message box with “The instruction at ##### referenced memory…”.

              I examined the trace file (about 1.5 Mbyte) and there are no errors except a couple of Error 62 (Input past end), which are trapped in proper fashion in the PB code. So where does the debugger fit in to this – there are no un-trapped errors in the program.

              Comment


              • #27
                Try it in a diffirent machine and OS.
                Roy Cline

                Comment


                • #28
                  Intent to. I believe it’s this machine specific. But that still begs the question, what on earth has happened to cause it.

                  Comment


                  • #29
                    Keith, I hate to say it but I have learned to use debugger for the sake of something I may have missed or could not catch in real time. That said, I am a proponent of Messageboxes in a well placed point where I think the problem may lay. Although once in a blue moon under the right conditions, I have found a messagebox (for whatever reason) would stop a crash in a routine that I was trying to find the cause.

                    Sounds weird, but put the messagebox in, no crash....take it out...crash

                    So running debugger with Break-on-Error could not hurt.

                    There is also another way to track it down, but the clue to me was on CodeProject which is mainly C code, that I saw a while back and 1st thought was..."Hmmm this could be a VERY useful tool if I could understand and port it to PB"...but time and other projects have prevented me from trying. (Maybe someone has or is willing to before I do?)

                    I can not think of it at the moment, but maybe a search on CodeProject for something along the lines of "Find that Error" (if memory serves) will reveal something?

                    Till then, I would suggest the debugger just to rule something else out.
                    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


                    • #30
                      Yes – I too have had the strange error suppression effect of msgbox, although it was ages ago.

                      I managed to compile and debug the program in the IDE (never used it before). I did the following.

                      Checked “Break on Error”
                      Load main source file
                      Select “Compile and Debug” from the Run menu
                      Success and program was paused at entry to WinMain
                      Hit F5 to run past each break point– program appears
                      Click program top right X to exit

                      This is what the IDE/Debugger output window contains.



                      ==============================
                      Compile succeeded at 13:28:10 on 26/10/2007

                      Begin Debug at 13:28:10 on 26/10/2007
                      Break on error 53:
                      File not found
                      Exception: Memory Access Violation
                      Program tried to read or write an invalid memory address
                      End Debug at 13:29:22 on 26/10/2007


                      As an additional check, I placed a msgbox "Exit" at the very end of WinMain and tried again. The message box appears before the Memory Access Violation.

                      I don’t really see what the debugger can do for me in this circumstance. The access violation occurs after all my PB source code has been executed (as demonstrated by the msgbox “Exit”). The one error 53 above is correctly trapped in the source code so prior corruption causing a delayed-action effect seems unlikely.

                      I don’t know where to go with this problem.

                      By the way, I did notice that if once the program had run to completion I again selected “Compile and Debug”, the PB IDE crashed. Unloading the source file and reloading did not prevent this.

                      Comment


                      • #31
                        I examined the trace file (about 1.5 Mbyte) and there are no errors except a couple of Error 62 (Input past end
                        ...
                        The one error 53 above is correctly trapped..
                        Are you sure your program is correctly handling 'flow' on these errors? I have seen weird things happen when read/write to an invalid handle (file not found) and input past end (which should never be allowed to happen, btw) leaves the specified input variable in an 'undefined' state.

                        Use that handle or variable subsequently ===> "mystery error"

                        MCM
                        Michael Mattias
                        Tal Systems Inc. (retired)
                        Racine WI USA
                        [email protected]
                        http://www.talsystems.com

                        Comment


                        • #32
                          In this latest session, I arranged for my program to load a simpler file on start-up, which means we get no error 62. The single error 53 occurs here.

                          Code:
                          SUB KillFile (BYVAL aFile$)
                            ON ERROR GOTO KillFileError
                            KILL aFile$
                          KillFileExit:
                            ON ERROR GOTO 0
                            EXIT SUB
                          
                          KillFileError:
                            RESUME KillFileExit
                          END SUB

                          Comment


                          • #33
                            Code shown:

                            If KILL fails because file in use (or any reason other than non-existence), how does the calling procedure know the file is still present? And what does it do about that?

                            Methinks you need to change that to a function, returning zero if file is now gone, but TRUE if it was present but not deleted and the rest of your program needs to react to that accordingly.

                            I mean why even bother with error testing if you don't do anything with the error?

                            Not that it helps in this case because your only noted error is "not found" but ya never knows....

                            MCM
                            Michael Mattias
                            Tal Systems Inc. (retired)
                            Racine WI USA
                            [email protected]
                            http://www.talsystems.com

                            Comment


                            • #34
                              I sort of expected you to pick me up on that and you’re absolutely correct, of course.

                              I did check every use of that sub and satisfied myself that it’s used safely. That is, it’s used in circumstances where failure to delete an existing file will not be disastrous.

                              For what its worth (because it probably tells us nothing), I commented out the statements inside KillFile, effectively turning into a do-nothing sub, and reran the program. No difference. Also, I ran it with just KILL aFile$ - again no difference.

                              Comment


                              • #35
                                I think I’ve found it, he says with fingers crossed.

                                I started systematically disabling sections of the program and narrowed the problem down to a QHTM control ( http://www.gipsysoft.com/qhtm/ ) that is used to display some html. Just after creating the QHTM child window I do,

                                CALL QHTM_EnableCooltips(hInst)

                                Commenting out this call seems to cure the problem. The call enables html tooltips ( http://www.gipsysoft.com/qhtm/doc/qh...cooltips.shtml ) – I will have to check in the application whether I’m actually making use of this – if not then all is well. So, it looks like the problem was with a third-party dll.

                                But it is still a mystery why this suddenly started giving trouble when it had never before. I bet when I test the program on another machine/OS this weekend I will find that it gives no trouble.

                                Thanks for your help
                                Keith

                                Comment


                                • #36
                                  "hinst", huh?

                                  You know what this almost sounds like?

                                  Since you can't get a module name on GPF, it almost sounds like some library (DLL) was freed but then some other procedure tried to access a function in that library.

                                  That passed "hinst'" parameter --- is that a handle to some code library you load, and might have freed prior to making that call to that library? Or didn't load before calling it?

                                  Or, it could be that someone (author of QHTM control?) actually got caught doing something on the DLL_PROCESS_ATTACH notification which should not be done there - you should only call stuff residing in KERNEL32.DLL on this notification. While this 'rule' has existed essentially 'forever', I'm not sure we've ever seen anyone actually get caught!

                                  The doc does say...
                                  Calling imported functions other than those located in Kernel32.dll may result in problems that are difficult to diagnose.
                                  .. and this certainly fits that bill to a Tee.

                                  MCM
                                  Michael Mattias
                                  Tal Systems Inc. (retired)
                                  Racine WI USA
                                  [email protected]
                                  http://www.talsystems.com

                                  Comment


                                  • #37
                                    The hInst is the hInstance of the calling process, that is

                                    hInst = GetWindowLong(hWndP, %GWL_HINSTANCE)

                                    I have more data, and an admission.

                                    There is a function, QHTM_Uninitialize that appears to be undocumented on the QHTM site. The include file simple says, “Call this to shutdown QHTM”. Clearly it is intended to be paired with QHTM_Initialize, which is documented on the site. Guess what – I had not called QHTM_Uninitialize in my exit code.

                                    Now I’ve rectified that, QHTM_EnableCooltips no longer needs to be commented out. I’m amazed and ashamed I didn’t spot that before. That fault has been in the program for some years.

                                    Comment


                                    • #38
                                      >I’m amazed and ashamed ...

                                      You forgot 'lucky' . That you weren't paying some consultant for debugging assistance, that is.
                                      Michael Mattias
                                      Tal Systems Inc. (retired)
                                      Racine WI USA
                                      [email protected]
                                      http://www.talsystems.com

                                      Comment


                                      • #39
                                        I’ve just tried the program on an old Win98 machine and as expected, it runs with no shutdown error irrespective of whether QHTM_Uninitialize is called.

                                        Amazed, ashamed and lucky
                                        Keith

                                        Comment


                                        • #40
                                          >I’ve just tried the program on an old Win98 machine and as expected, it runs with no >shutdown error irrespective of whether QHTM_Uninitialize is called

                                          You know, I've found it very true that each subsequent version of Windows is much more 'finicky' about "following the written rules."

                                          I remember on two occasions when I created stuff on Win/98 and "it worked here" but failed on Win/2000 or Win/XP. I know at least one of those was a "mystery end of job GPF" and I'm almost sure the other one was, too.

                                          Sure enough, it was some 'close' or 'release' or 'unitialize' step I had not coded that caused the problem.

                                          Plus one other time... a couple of buttons totally failed to appear on a screen on Win/XP; they not only appeared but they worked 'as designed' on my Win/98 machine. (The tip here: when you create a superclass from a standard class, never never never, never reset the cbWndExtra member of WNDCLASS structure to zero. Bad things will happen... except on Windows/98!)

                                          MCM
                                          Last edited by Michael Mattias; 27 Oct 2007, 11:34 AM.
                                          Michael Mattias
                                          Tal Systems Inc. (retired)
                                          Racine WI USA
                                          [email protected]
                                          http://www.talsystems.com

                                          Comment

                                          Working...
                                          X