stackoom
  简体   繁体   中英

Access Violation In C application

 原文  2013-10-24 12:03:18  1   2    c++/ c/ memory/ memory-management/ out-of-memory

Question

Folks

I am having crashes in my C / C++ application (VC 6.0) It appears random but all instances relate to either new / malloc. I have a minidump handler in my code that is output in and __except block that surronds the call to OLDMain.

When i look at this dump in WinDbg i get the following output: (modified to protect codebase) 

STACK_TEXT:  
WARNING: Stack unwind information not available. Following frames may be wrong.
001273f0 01730000 0000042b 060a8ea8 00127424 ntdll+0x122ba
00127400 7c911bdc 01730178 0000042b 01730000 0x1730000
00127424 7c91825d 0000042b 100a8ea8 0000042b ntdll+0x11bdc
00127458 7c911c76 02730000 00001038 00127c07 ntdll+0x1825d
00127688 0081bffc 01730000 00000000 00001030 ntdll+0x11c76
001276c4 0080cf52 00001030 00127c07 00b99f11 MyProgram!_heap_alloc_base+0x13c [malloc.c @ 200]
001276ec 0080cd39 00001000 00000002 00ac1fa8 MyProgram!_heap_alloc_dbg+0x1a2 [dbgheap.c @ 378]
0012772c 0080ccbf 00001000 00000000 00000002 MyProgram!_nh_malloc_dbg+0x49 [dbgheap.c @ 248]
0012774c 008202f9 00001000 00000002 00ac1fa8 MyProgram!_malloc_dbg+0x1f [dbgheap.c @ 165]
00127774 00817dfc 00b67668 00127c07 00b99f11 MyProgram!_getbuf+0x59 [_getbuf.c @ 59]
001277a0 00818d4f 00000032 00b67668 00127af1 MyProgram!_flsbuf+0x13c [_flsbuf.c @ 153]
001277b4 00818df7 00000032 00b67668 0012786c MyProgram!write_char+0x4f [output.c @ 1113]
001277cc 00818ba5 00127af1 00000009 00b67668 MyProgram!write_string+0x37 [output.c @ 1251]
00127a9c 00809785 00b67668 00b1653a 00127ae0 MyProgram!_output+0xc65 [output.c @ 1007]
00127acc 005ad453 00b67668 00b16538 00127af0 MyProgram!fprintf+0x95 [fprintf.c @ 64]
00127c08 005acfd9 00127c30 00b16398 00127d4c MyProgram!WriteStringToFile+0x150 [C:\PATH_TO_SOURCE\LIB_Methods.cpp @ 11562]
00127d2c 004c0507 00af445c 00127d4c 0012e3bc MyProgram!WriteLog+0x594 [C:\PATH_TO_SOURCE\LIB_Methods.cpp @ 11468]
00127e84 005fd45c 00b25a78 00b258f9 00b99f11 MyProgram!WriteTimingsText+0x7c [C:\PATH_TO_SOURCE\PROM_Methods.cpp @ 2711]
0012e55c 005fd210 0000008a fffff2de 0012e6c4 MyProgram!_C_S_Method+0x113 [C:\PATH_TO_SOURCE\SAL_Methods.cpp @ 8681]
0012e940 0045dd6c 0012e810 00b24d16 00000000 MyProgram!_ST_Method+0x407e [C:\PATH_TO_SOURCE\SAL_Methods.cpp @ 8581]
0012eaf4 005f7827 0012eccc 00b9b038 0012ed64 MyProgram!_K_ST_Method+0x246 [C:\PATH_TO_SOURCE\FX_Methods.cpp @ 3306]
0012edc4 005f18b1 0012f41c 0012f424 cccccccc MyProgram!_N_I_Method+0x3b6a [C:\PATH_TO_SOURCE\SAL_Methods.cpp @ 5946]
0012f418 007ba243 00b5b950 00320030 00300034 MyProgram!OLDMain+0x1dd6 [C:\PATH_TO_SOURCE\SAL_Methods.cpp @ 2489]
0012ff30 00815546 00400000 00000000 00142368 MyProgram!WinMain+0x70f [C:\PATH_TO_SOURCE\MyProgram.cpp @ 866]
0012ffc0 7c816d4f 00320030 00300034 7ffd5000 MyProgram!WinMainCRTStartup+0x126 [crt0.c @ 198]
0012fff0 00000000 00815420 00000000 00000000 kernel32+0x16d4f

I have looked at other stacks from crashes that related to new, in those case the clss that was being created did not need to be as it was not configured to do so, i added a check for the configuratipon and reran.

The issue seems to be pushed further along.

At this point i am unsure how to figure out why Malloc / new are failing? Any suggestions for what i can do next?

Full Windbg output 

*******************************************************************************
*                                                                             *
*                        Exception Analysis                                   *
*                                                                             *
*******************************************************************************

*** WARNING: Unable to verify checksum for MyProgram.exe
*** WARNING: Unable to verify timestamp for kernel32.dll
*** ERROR: Module load completed but symbols could not be loaded for kernel32.dll
***** OS symbols are WRONG. Please fix symbols to do analysis.

Unable to load image C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\mscorwks.dll, Win32 error 0n2
*** WARNING: Unable to verify timestamp for mscorwks.dll
*** ERROR: Module load completed but symbols could not be loaded for mscorwks.dll
Unable to load image C:\WINDOWS\system32\ole32.dll, Win32 error 0n2
*** WARNING: Unable to verify timestamp for ole32.dll
*** ERROR: Module load completed but symbols could not be loaded for ole32.dll
Unable to load image C:\WINDOWS\system32\user32.dll, Win32 error 0n2
*** WARNING: Unable to verify timestamp for user32.dll
*** ERROR: Module load completed but symbols could not be loaded for user32.dll
*** WARNING: Unable to verify timestamp for wdmaud.drv
*** ERROR: Module load completed but symbols could not be loaded for wdmaud.drv
*** WARNING: Unable to verify timestamp for dsound.dll
*** ERROR: Module load completed but symbols could not be loaded for dsound.dll
*** WARNING: Unable to verify timestamp for dmime.dll
*** ERROR: Module load completed but symbols could not be loaded for dmime.dll
*** WARNING: Unable to verify timestamp for dmsynth.dll
*** ERROR: Module load completed but symbols could not be loaded for dmsynth.dll
*** WARNING: Unable to verify checksum for SOBase11.dll
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for SOBase11.dll - 
*** WARNING: Unable to verify checksum for PortMg10.dll
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for PortMg10.dll - 
*** WARNING: Unable to verify checksum for Porthcom.dll
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for Porthcom.dll - 
*** WARNING: Unable to verify timestamp for mfc42.dll
*** ERROR: Module load completed but symbols could not be loaded for mfc42.dll
*** WARNING: Unable to verify checksum for PtrIO15.dll
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for PtrIO15.dll - 
*** WARNING: Unable to verify timestamp for SoDspL13.dll
*** ERROR: Module load completed but symbols could not be loaded for SoDspL13.dll
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for GdiPlus.dll - 
Unable to load image C:\WINDOWS\system32\rpcrt4.dll, Win32 error 0n2
*** WARNING: Unable to verify timestamp for rpcrt4.dll
*** ERROR: Module load completed but symbols could not be loaded for rpcrt4.dll
*** WARNING: Unable to verify timestamp for KbwMSRDrv.dll
*** ERROR: Module load completed but symbols could not be loaded for KbwMSRDrv.dll
Failed to load data access DLL, 0x80004005
Verify that 1) you have a recent build of the debugger (6.2.14 or newer)
            2) the file mscordacwks.dll that matches your version of mscorwks.dll is 
                in the version directory
            3) or, if you are debugging a dump file, verify that the file 
                mscordacwks_<arch>_<arch>_<version>.dll is on your symbol path.
            4) you are debugging on the same architecture as the dump file.
                For example, an IA64 dump file must be debugged on an IA64
                machine.

You can also run the debugger command .cordll to control the debugger's
load of mscordacwks.dll.  .cordll -ve -u -l will do a verbose reload.
If that succeeds, the SOS command should work on retry.

If you are debugging a minidump, you need to make sure that your executable
path is pointing to mscorwks.dll as well.
Failed to load data access DLL, 0x80004005
Verify that 1) you have a recent build of the debugger (6.2.14 or newer)
            2) the file mscordacwks.dll that matches your version of mscorwks.dll is 
                in the version directory
            3) or, if you are debugging a dump file, verify that the file 
                mscordacwks_<arch>_<arch>_<version>.dll is on your symbol path.
            4) you are debugging on the same architecture as the dump file.
                For example, an IA64 dump file must be debugged on an IA64
                machine.

You can also run the debugger command .cordll to control the debugger's
load of mscordacwks.dll.  .cordll -ve -u -l will do a verbose reload.
If that succeeds, the SOS command should work on retry.

If you are debugging a minidump, you need to make sure that your executable
path is pointing to mscorwks.dll as well.
GetPageUrlData failed, server returned HTTP status 404
URL requested: http://watson.microsoft.com/StageOne/MyProgram_exe/0_0_0_0/ntdll_dll/5_1_2600_2180/000122ba.htm?Retriage=1

FAULTING_IP: 
ntdll+122ba
7c9122ba ??              ???

EXCEPTION_RECORD:  ffffffff -- (.exr 0xffffffffffffffff)
ExceptionAddress: 7c9122ba (ntdll+0x000122ba)
   ExceptionCode: c0000005 (Access violation)
  ExceptionFlags: 00000000
NumberParameters: 2
   Parameter[0]: 00000000
   Parameter[1]: 00000000
Attempt to read from address 00000000

PROCESS_NAME:  MyProgram.exe

ADDITIONAL_DEBUG_TEXT:  
Use '!findthebuild' command to search for the target build information.
If the build information is available, run '!findthebuild -s ; .reload' to set symbol path and load symbols.

FAULTING_MODULE: 7c900000 ntdll

DEBUG_FLR_IMAGE_TIMESTAMP:  5268f887

ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at "0x%08lx" referenced memory at "0x%08lx". The memory could not be "%s".

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at "0x%08lx" referenced memory at "0x%08lx". The memory could not be "%s".

EXCEPTION_PARAMETER1:  00000000

EXCEPTION_PARAMETER2:  00000000

READ_ADDRESS:  00000000 

FOLLOWUP_IP: 
MyProgram!_heap_alloc_base+13c [malloc.c @ 200]
0081bffc 8b4df0          mov     ecx,dword ptr [ebp-10h]

MOD_LIST: <ANALYSIS/>

MANAGED_STACK: !dumpstack -EE
Failed to load data access DLL, 0x80004005
Verify that 1) you have a recent build of the debugger (6.2.14 or newer)
            2) the file mscordacwks.dll that matches your version of mscorwks.dll is 
                in the version directory
            3) or, if you are debugging a dump file, verify that the file 
                mscordacwks_<arch>_<arch>_<version>.dll is on your symbol path.
            4) you are debugging on the same architecture as the dump file.
                For example, an IA64 dump file must be debugged on an IA64
                machine.

You can also run the debugger command .cordll to control the debugger's
load of mscordacwks.dll.  .cordll -ve -u -l will do a verbose reload.
If that succeeds, the SOS command should work on retry.

If you are debugging a minidump, you need to make sure that your executable
path is pointing to mscorwks.dll as well.

FAULTING_THREAD:  000007fc

BUGCHECK_STR:  APPLICATION_FAULT_NULL_POINTER_READ_WRONG_SYMBOLS

PRIMARY_PROBLEM_CLASS:  NULL_POINTER_READ

DEFAULT_BUCKET_ID:  NULL_POINTER_READ

IP_ON_HEAP:  01730000

FRAME_ONE_INVALID: 1

LAST_CONTROL_TRANSFER:  from 01730000 to 7c9122ba

STACK_TEXT:  
WARNING: Stack unwind information not available. Following frames may be wrong.
001273f0 01730000 0000042b 060a8ea8 00127424 ntdll+0x122ba
00127400 7c911bdc 01730178 0000042b 01730000 0x1730000
00127424 7c91825d 0000042b 100a8ea8 0000042b ntdll+0x11bdc
00127458 7c911c76 02730000 00001038 00127c07 ntdll+0x1825d
00127688 0081bffc 01730000 00000000 00001030 ntdll+0x11c76
001276c4 0080cf52 00001030 00127c07 00b99f11 MyProgram!_heap_alloc_base+0x13c [malloc.c @ 200]
001276ec 0080cd39 00001000 00000002 00ac1fa8 MyProgram!_heap_alloc_dbg+0x1a2 [dbgheap.c @ 378]
0012772c 0080ccbf 00001000 00000000 00000002 MyProgram!_nh_malloc_dbg+0x49 [dbgheap.c @ 248]
0012774c 008202f9 00001000 00000002 00ac1fa8 MyProgram!_malloc_dbg+0x1f [dbgheap.c @ 165]
00127774 00817dfc 00b67668 00127c07 00b99f11 MyProgram!_getbuf+0x59 [_getbuf.c @ 59]
001277a0 00818d4f 00000032 00b67668 00127af1 MyProgram!_flsbuf+0x13c [_flsbuf.c @ 153]
001277b4 00818df7 00000032 00b67668 0012786c MyProgram!write_char+0x4f [output.c @ 1113]
001277cc 00818ba5 00127af1 00000009 00b67668 MyProgram!write_string+0x37 [output.c @ 1251]
00127a9c 00809785 00b67668 00b1653a 00127ae0 MyProgram!_output+0xc65 [output.c @ 1007]
00127acc 005ad453 00b67668 00b16538 00127af0 MyProgram!fprintf+0x95 [fprintf.c @ 64]
00127c08 005acfd9 00127c30 00b16398 00127d4c MyProgram!WriteStringToFile+0x150 [C:\PATH_TO_SOURCE\LIB_Methods.cpp @ 11562]
00127d2c 004c0507 00af445c 00127d4c 0012e3bc MyProgram!WriteLog+0x594 [C:\PATH_TO_SOURCE\LIB_Methods.cpp @ 11468]
00127e84 005fd45c 00b25a78 00b258f9 00b99f11 MyProgram!WriteTimingsText+0x7c [C:\PATH_TO_SOURCE\PROM_Methods.cpp @ 2711]
0012e55c 005fd210 0000008a fffff2de 0012e6c4 MyProgram!_C_S_Method+0x113 [C:\PATH_TO_SOURCE\SAL_Methods.cpp @ 8681]
0012e940 0045dd6c 0012e810 00b24d16 00000000 MyProgram!_ST_Method+0x407e [C:\PATH_TO_SOURCE\SAL_Methods.cpp @ 8581]
0012eaf4 005f7827 0012eccc 00b9b038 0012ed64 MyProgram!_K_ST_Method+0x246 [C:\PATH_TO_SOURCE\FX_Methods.cpp @ 3306]
0012edc4 005f18b1 0012f41c 0012f424 cccccccc MyProgram!_N_I_Method+0x3b6a [C:\PATH_TO_SOURCE\SAL_Methods.cpp @ 5946]
0012f418 007ba243 00b5b950 00320030 00300034 MyProgram!OLDMain+0x1dd6 [C:\PATH_TO_SOURCE\SAL_Methods.cpp @ 2489]
0012ff30 00815546 00400000 00000000 00142368 MyProgram!WinMain+0x70f [C:\PATH_TO_SOURCE\MyProgram.cpp @ 866]
0012ffc0 7c816d4f 00320030 00300034 7ffd5000 MyProgram!WinMainCRTStartup+0x126 [crt0.c @ 198]
0012fff0 00000000 00815420 00000000 00000000 kernel32+0x16d4f


STACK_COMMAND:  ~0s; .ecxr ; kb

FAULTING_SOURCE_CODE:  
No source found for 'malloc.c'


SYMBOL_STACK_INDEX:  5

SYMBOL_NAME:  MyProgram!_heap_alloc_base+13c

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: MyProgram

IMAGE_NAME:  MyProgram.exe

BUCKET_ID:  WRONG_SYMBOLS

FAILURE_BUCKET_ID:  NULL_POINTER_READ_c0000005_MyProgram.exe!_heap_alloc_base

WATSON_STAGEONE_URL:  http://watson.microsoft.com/StageOne/MyProgram_exe/0_0_0_0/5268f887/ntdll_dll/5_1_2600_2180/411096b4/c0000005/000122ba.htm?Retriage=1

Followup: MachineOwner
---------

EDIT:

I have commented out WriteStringToFile, just to show that it will crash again, here is another call stack: The only thing in common in the heap_alloc, now one thing i can see that is the same between both call stacks for a NULL pointer is on the line below: IS it in _N_I_Method where the Null pointer starts or is this valid here? 

0012edc4 005f18b1 0012f41c 0012f424 **cccccccc** MyProgram!_N_I_Method+0x3b6a [C:\PATH_TO_SOURCE\SAL_Methods.cpp @ 5946]

New Stack 

STACK_TEXT:  
WARNING: Stack unwind information not available. Following frames may be wrong.
00127b54 0012e3bc 00b99f11 00000000 00000000 ntdll+0x3426d
00127d78 0081bffc 01730000 00000000 00000040 0x12e3bc
00127db4 0080cf52 00000040 0012e3bc 00b99f11 MyProgram!_heap_alloc_base+0x13c [malloc.c @ 200]
00127ddc 0080cd39 00000014 00000001 00000000 MyProgram!_heap_alloc_dbg+0x1a2 [dbgheap.c @ 378]
00127e1c 0080cce6 00000014 00000001 00000001 MyProgram!_nh_malloc_dbg+0x49 [dbgheap.c @ 248]
00127e38 008089bf 00000014 00000001 00b86f20 MyProgram!_nh_malloc+0x16 [dbgheap.c @ 197]
00127e4c 0052966a 00000014 00b99f11 cccccccc MyProgram!operator new+0xf [new.cpp @ 24]
00127e88 005ff32c 00b258f9 00b99f11 00000000 MyProgram!CMessaging::SendMsg_Finished+0x43 [C:\PATH_TO_SOURCE\CMessaging.cpp @ 1703]
0012e55c 005fd210 0000008a fffff2de 0012e6c4 MyProgram!_C_S_Method+0x1fe3 [C:\PATH_TO_SOURCE\SAL_Methods.cpp @ 9824]
0012e940 0045dd6c 0012e810 00b24d16 00000000 MyProgram!_ST_Method+0x407e [C:\PATH_TO_SOURCE\SAL_Methods.cpp @ 8581]
0012eaf4 005f7827 0012eccc 00b9b038 0012ed64 MyProgram!_K_ST_Method+0x246 [C:\PATH_TO_SOURCE\FX_Methods.cpp @ 3306]
0012edc4 005f18b1 0012f41c 0012f424 cccccccc MyProgram!_N_I_Method+0x3b6a [C:\PATH_TO_SOURCE\SAL_Methods.cpp @ 5946]
0012f418 007ba243 00b5b950 80000001 01b5d678 MyProgram!Oldmain+0x1dd6 [C:\PATH_TO_SOURCE\SAL_Methods.cpp @ 2489]
0012ff30 00815546 00400000 00000000 00142368 MyProgram!WinMain+0x70f [C:\PATH_TO_SOURCE\MyProgram.cpp @ 866]
0012ffc0 7c816d4f 80000001 01b5d678 7ffdf000 MyProgram!WinMainCRTStartup+0x126 [crt0.c @ 198]
0012fff0 00000000 00815420 00000000 00000000 kernel32+0x16d4f

2 answers

solution1
 3  2013-10-24 13:01:06

Malloc/new are failing, it is usually because that the heap is already corrupted. For your case, two possible reasons:

  1. The heap is messed up by you own code.
  2. Mismatch runtime libraries. You're still using VC 6++ for coding, but other DLLs, I think most of them are compiled with higher version of VC, so there should be multiple windows runtime libraries(msvcrt.dll) in your process. If one memory is malloced by one runtime library, and freed by another runtime library, which might cause heap corruption because different runtime library may have different implementation of malloc and free.

solution2
 2  2013-10-24 12:21:53

At this point i am unsure how to figure out why Malloc / new are failing? Any suggestions for what i can do next?

If you get stack frame exceptions then you most probably have buffer overruns in your code.

If you don't have a suitable tool to help you I suggest you use a combination of code review (with focus on pointers and buffer overruns) and classic debugging.

With classic debugging I mean pinpointing the problem by first running the code one section at a time until you either get a crash or you see an overwritten variable. Then re-run the last section line by line until you find where it fails. Fix the bug. Repeat until all your test cases work.

暂无
暂无

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

Related Question Access violation in a multithreaded application, C++ C++: Access violation Access Violation c++? C++ Access violation? Access Violation C++ Access violation in c++ C++, Access violation Access violation with C++ C++ Access Violation In regards to access violation in C++?
Related Tags
 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM