Partager via


Customer question: what does the crash call stack mean

A customer asks:

I read your article "Intentionally crash your program". I have some questions that I hope you can answer.

When a fatal exception happens, foxpro display the calling stacks. How to read the calling stacks? A calling stack seems to contain the following information:

1. either a function name or a method name

2. line # but sometimes the line # is 0

3. the exe or fxp but sometimes it seems to be just the directory where the exe is running.

For example, if the last calling stack shows something like this:

Called from: ON...line 20 {xxx.fxp}

What does it mean?

Let's that I'm getting a fatal exception error because of a corrupted VFP dll or a MS dll which VFP dll depends on. How can I find out which dll?

Thanks for any help.

When I run this factorial sample code, a MessageBox shows: “Cause an intentional crash for test purposes”

?fact(10)

PROCEDURE fact(n)

      IF n=1

            SYS(1079)

            RETURN 1

      ENDIF

      IF MOD(n,2)=0

            RETURN fact2(n-1)*n

      ELSE

            RETURN fact(n-1)*n

      ENDIF

PROCEDURE fact2(n)

      RETURN fact(n)

If I choose OK, then VFP crashes, Watson appears, and another MessageBox occurs showing the VFP call stack. The call stack can be very helpful to show what code VFP was running when the crash occurs. The call stack is also appended to the log file indicated.

Fatal error: Exception code=C0000005 @ 12/07/06 12:00:14 PM. Error log file: D:\fox90\VFP9err.log

      Called from - fact line 5 {d:\fox90\test\tt1.prg d:\fox90\test\tt1.fxp}

      Called from - fact2 line 15 {d:\fox90\test\tt1.prg d:\fox90\test\tt1.fxp}

      Called from - fact line 9 {d:\fox90\test\tt1.prg d:\fox90\test\tt1.fxp}

      Called from - fact line 11 {d:\fox90\test\tt1.prg d:\fox90\test\tt1.fxp}

      Called from - fact2 line 15 {d:\fox90\test\tt1.prg d:\fox90\test\tt1.fxp}

      Called from - fact line 9 {d:\fox90\test\tt1.prg d:\fox90\test\tt1.fxp}

      Called from - fact line 11 {d:\fox90\test\tt1.prg d:\fox90\test\tt1.fxp}

      Called from - fact2 line 15 {d:\fox90\test\tt1.prg d:\fox90\test\tt1.fxp}

      Called from - fact line 9 {d:\fox90\test\tt1.prg d:\fox90\test\tt1.fxp}

      Called from - fact line 11 {d:\fox90\test\tt1.prg d:\fox90\test\tt1.fxp}

      Called from - fact2 line 15 {d:\fox90\test\tt1.prg d:\fox90\test\tt1.fxp}

      Called from - fact line 9 {d:\fox90\test\tt1.prg d:\fox90\test\tt1.fxp}

      Called from - fact line 11 {d:\fox90\test\tt1.prg d:\fox90\test\tt1.fxp}

      Called from - fact2 line 15 {d:\fox90\test\tt1.prg d:\fox90\test\tt1.fxp}

      Called from - fact line 9 {d:\fox90\test\tt1.prg d:\fox90\test\tt1.fxp}

      Called from - tt1 line 1 {d:\fox90\test\tt1.prg d:\fox90\test\tt1.fxp}

VFP knows that the process is in a crash state, but it has no idea why. Perhaps an errant DLL caused the crash. Perhaps the call stack info has been corrupted before the crash.

If the line # shows 0, then perhaps the VFP code was built with no debug info, (Project->Project Info->Debug Info checkbox), the line # might show 0.

I took the program from this code: Put a web browser on your desktop and modified the txtURL.valid code: if the user tries to navigate to a site that starts with “C”, then it will ask the user if he wants to crash.

          PROCEDURE txtURL.valid

                   IF this.value="C"

                             SYS(1079)

                   ENDIF

This results in a call stack like this:

Fatal error: Exception code=C0000005 @ 12/07/06 12:14:39 PM. Error log file: D:\Fox90\VFP9err.log

            Called from - myformx.txturl.valid line 92 {d:\fox90\test\tt.prg d:\fox90\test\tt.fxp}

You can also see Dynamically attaching a debugger to figure out what is causing a crash. Just attach a debugger, and change the Debug->Exceptions->Win32 Exceptions checkbox to stop when Thrown. Then the debugger will show you a callstack showing the module in which the exception occurred. (This may not be the errant module: for example the error could have been caused by one module corrupting the process heap, which causes another module to fail.)

See also:

Dr. Watson: Please send in your error report

Intentionally crash your program

What is a C0000005 crash?

More Multithread capabilities: interthread synchronization, error checking

Comments

  • Anonymous
    December 11, 2006
    The comment has been removed