locked
Application verifier RRS feed

  • Question

  • Hi,

    The logs generated by application verifier shows errors as "Double free". But these logs do not show call stacks to provide information about what code allocated and freed the memory. Following is the log generated by App Verifier...

    # LOG_BEGIN 6/8/2009 17:56:01 '\Program Files\MyAppFolder\MyApp' '\AppVerifier_MyApp_1756.log'
    # SHIM_BEGIN _verifier_ 0
    # LOGENTRY shim_verifier.dll 0 'Started
    # DESCRIPTION BEGIN
    The application started running. This is an informational message; no action is required.
    # DESCRIPTION END
    # LOGENTRY shim_verifier.dll 1 'Stopped
    # DESCRIPTION BEGIN
    The application stopped running. This is an informational message; no action is required.
    # DESCRIPTION END
    # LOGENTRY shim_verifier.dll 2 'Unfreed library
    # DESCRIPTION BEGIN
    The application loaded a module without freeing it before process exit.
    # DESCRIPTION END
    | shim_verifier.dll 0 | 0 ole32.dll 234cf8c'MyApp.exe - 5:56:01 PM
    # LOGENTRY shim_heap.dll 0 'Generic warning
    # DESCRIPTION BEGIN
    Generic warning
    # DESCRIPTION END
    # LOGENTRY shim_heap.dll 1 'Generic error
    # DESCRIPTION BEGIN
    Generic error
    # DESCRIPTION END
    # LOGENTRY shim_heap.dll 2 'Invalid heap
    # DESCRIPTION BEGIN
    The application used an invalid heap handle. If allowed to be passed to the heap, it would probably lead to a fault.
    # DESCRIPTION END
    # LOGENTRY shim_heap.dll 3 'Invalid pointer
    # DESCRIPTION BEGIN
    The application passed an invalid pointer. If allowed to be passed to the heap, it would probably lead to a fault.
    # DESCRIPTION END
    # LOGENTRY shim_heap.dll 4 'Double free
    # DESCRIPTION BEGIN
    The application is attempting to free an allocation that has already been freed.
    # DESCRIPTION END
    # LOGENTRY shim_heap.dll 5 'Buffer overflow
    # DESCRIPTION BEGIN
    The application wrote past the end of the buffer.
    # DESCRIPTION END
    # LOGENTRY shim_heap.dll 6 'Buffer underflow
    # DESCRIPTION BEGIN
    The application wrote before the beginning of the buffer
    # DESCRIPTION END
    # LOGENTRY shim_heap.dll 7 'Serialization warning
    # DESCRIPTION BEGIN
    The application used the HEAP_NO_SERIALIZE flag. This flag is ignored by the heap.
    # DESCRIPTION END
    # LOGENTRY shim_heap.dll 8 'Allocation error
    # DESCRIPTION BEGIN
    A heap allocation failed unexpectedly.
    # DESCRIPTION END
    # LOGENTRY shim_heap.dll 9 'Use after free
    # DESCRIPTION BEGIN
    The application wrote to a heap allocation after it had been freed. This is very bad!!
    # DESCRIPTION END
    # LOGENTRY shim_heap.dll 10 'Max heap size requested
    # DESCRIPTION BEGIN
    The application requested a maximum size for a heap. This shim is padding allocations, so the size of the heap will be larger than the app expects.
    # DESCRIPTION END
    # LOGENTRY shim_heap.dll 11 'Max heap size request ignored
    # DESCRIPTION BEGIN
    The application requested a maximum size for a heap, and that request was ignored. The heap will be growable.
    # DESCRIPTION END
    # LOGENTRY shim_heap.dll 12 'Destroying a non-empty heap - possible memory leak
    # DESCRIPTION BEGIN
    The application is destroying a non-empty heap. This is only a warning; it could be valid. Please double-check, though.
    # DESCRIPTION END
    # LOGENTRY shim_heap.dll 13 'Non-destroyed heap
    # DESCRIPTION BEGIN
    The application created a heap, and did not destroy it.
    # DESCRIPTION END
    # LOGENTRY shim_heap.dll 14 'Can't destroy process heap
    # DESCRIPTION BEGIN
    The application attempted to destroy the process heap.
    # DESCRIPTION END
    # LOGENTRY shim_heap.dll 15 'Injected a heap fault
    # DESCRIPTION BEGIN
    The shim is injecting a heap fault into the application. The application should handle this fault gracefully.
    # DESCRIPTION END


    Regards.

    Monday, June 8, 2009 3:01 PM

Answers


  • 1) The scenario is more clear now. Actually it seems that the log file contains all error messages. That deos not mean that the application is having those errors. When opened in AppVerifier log veiwer, it will not report any errors for the logs I printed at start of this thread. So this answers my original question above.


    2) Further what I noticed was the AppVerifier log viewer that comes with Platform Builder does not properly map call stack addresses to function names when map file is provided.
    For solution to this problem, download the standalone AppVerifier from below and it will resolve the call stacks properly

    The standalone version of AppVerifier download link:

    Regards.
    • Marked as answer by Am_ac1 Wednesday, December 16, 2009 2:32 PM
    Wednesday, December 16, 2009 2:30 PM

All replies

  • Any inputs here please.....
    Thursday, June 11, 2009 7:48 AM
  • Could I get help on the above issue please....
    Friday, June 19, 2009 8:41 AM
  • Hello Am_ac1,

    create a Release directory in ur HS at its root (i.e where windows folder lies) copy yyy.map and yyy.pdb files in that directory then run app verifier. you will c stack trace.

    *yyy is suppose to be similar to ur application name.
    *pdb file is not necessary but you can try with that.

    It worked 70% of times for me not 100%.

    Thanks
    Arpit Pradhan
    WinCE CODER
    Friday, June 26, 2009 10:23 AM
  • Other stuff that you can try out is keeping .map file in the folder where u kept logs "generated by App verifier" (on ur Desktop).
    WinCE CODER
    Friday, June 26, 2009 4:57 PM
  • keep .map file in \Release folder will show help aap verifier to resolve call stack.

    WinCE CODER
    • Proposed as answer by NEO131 Thursday, July 2, 2009 10:20 AM
    • Unproposed as answer by Am_ac1 Wednesday, December 16, 2009 2:21 PM
    Thursday, July 2, 2009 10:20 AM

  • Can you please clarify what you refer to by saying \Release folder

    Regards.
    Thursday, October 8, 2009 12:26 PM
  • Create a Release Directory either at phone Root Directory or in the Directory where your application is deployed i.e Program Files/ur Application Name/Release/.map file

    Arpit Pradhan
    WinCE CODER (If you think my solution help you in some sense do mark my Reply as Answer)
    Wednesday, November 11, 2009 6:12 AM

  • 1) The scenario is more clear now. Actually it seems that the log file contains all error messages. That deos not mean that the application is having those errors. When opened in AppVerifier log veiwer, it will not report any errors for the logs I printed at start of this thread. So this answers my original question above.


    2) Further what I noticed was the AppVerifier log viewer that comes with Platform Builder does not properly map call stack addresses to function names when map file is provided.
    For solution to this problem, download the standalone AppVerifier from below and it will resolve the call stacks properly

    The standalone version of AppVerifier download link:

    Regards.
    • Marked as answer by Am_ac1 Wednesday, December 16, 2009 2:32 PM
    Wednesday, December 16, 2009 2:30 PM