1

I've been trying to identify the root cause for this access violation issue for a month. But I ended up here asking help.

On a high level the problem is heap corruption. If I dig into further i'm getting these exceptions either during allocating memory on heap(using new) or deallocating memory (using delete). These problems were occuring only on production environments. I found these details by analysing the core dump files. I'm not able to simulate these issues in local. In one of those core dump files i found the following line of code triggering the access violation issue. this->token = new Byte[obj.tokenLength]; here tokenLength is 972.

What would be the reason for throwing the access violation while requesting some amount of memory for my execution. As far as I know when i call malloc with some n bytes, either the kernel has to provide the requested n bytes or has to reject and throw BAD_ALLOC exception. What is the point here to throw the access violation exception.

This is the call stack found in the core dump files. The last line is what calling the this->token = new Byte[obj.tokenLength];.

ntdll.dll!@RtlpAllocateHeap@24()   Unknown
ntdll.dll!_RtlAllocateHeap@12()    Unknown
ntdll.dll!@RtlpAllocateUserBlock@12()  Unknown
ntdll.dll!@RtlpLowFragHeapAllocFromContext@8() Unknown
ntdll.dll!_RtlAllocateHeap@12()    Unknown
caconnector.dll!malloc(unsigned int size=972) Line 163  C
caconnector.dll!operator new(unsigned int size=972) Line 59 C++
caconnector.dll!GLSPlatformSessionInfo::GLSPlatformSessionInfo(const GLSPlatformSessionInfo & obj={...}) Line 282

Please help me with the proper direction of analysis where i can focus on now to identify the root cause of this issue.

Thanks in advance.

Dhaya
  • 61
  • 1
  • 1
  • 8
  • It's impossible to say where you are writing beyond bounds without knowing anything about your code (i.e. seeing the relevant source). However, if your program is large the problem could be *anywhere*. My advice is that you try to refactor the code to avoid pointers and dynamic memory allocations as much as possible, `std::vector` and `std::string` are good ways to start replacing those dynamic allocations with. you *still* need to add boundary checks, or use the bounds-checked `at` functions of `std::vector` and `std::string`. – Some programmer dude Oct 01 '15 at 09:37
  • The real problem might have occurred long before the place where the access violation happens. I suggest you use `valgrind` or a similar tool (or address sanitation of modern compilers) to check your program. – Petr Oct 01 '15 at 09:38
  • Operations that may cause heap corruption are all undefined, so you've lost all guarantees from the language's point of view. The cause of the corruption is likely far away from the allocation/deallocation in question. The most common cause is the use of uninitialised or dangling pointers. – molbdnilo Oct 01 '15 at 09:49
  • *'I've been trying to identify the root cause for this access violation issue for a month* In that time, you could have rewritten the code using `std::vector` and thus finally gottten some sleep. – PaulMcKenzie Oct 01 '15 at 09:55
  • If the data structures that keep track of the heap are corrupted, that might account for an access violation when calling new. The runtime won't necessarily return the requested memory or an exception if the runtime's memory has been corrupted. It's quite likely an invalid memory write somewhere else in your program. Valgrind may help pinpoint the real problem location. – Daniel Stevens Oct 01 '15 at 09:55
  • Thanks for the immediate response..! @molbdnilo How could there be a dangling pointer while allocating new memory? – Dhaya Oct 01 '15 at 09:57
  • @user1730832 `this->token = new Byte[obj.tokenLength]` This implies that you have a pointer to dynamically allocated memory as a member, and because of that, you have a class that needs to adhere to the rule of 3 if object copying is done. If not adhere to it, copying needs to be disabled. Thus there could be many reasons why you may have corrupted memory in some way, one being violation of the rule of 3. http://stackoverflow.com/questions/4172722/what-is-the-rule-of-three – PaulMcKenzie Oct 01 '15 at 10:00
  • An uninitialized pointer can cause overwriting the location in memory where heap information is stored, therefore making it impossible to correctly know where available memory is located, or pointing at incorrect memory locations. – SirDarius Oct 01 '15 at 10:00
  • @user1730832 As to my comment on using `std::vector`, I'm not being flippant. Many times you may identify where the problem is, but try to fix it with more logic that uses pointers and spaghetti-like logic to keep track of them. That is all eliminated if `std::vector` instead of `new[ ] / delete [ ]` is used. Also I wouldn't be surprised if using vector sped up your code, since you wouldn't be calling the allocator every time. Instead just a `std::vector::resize()` would be done. – PaulMcKenzie Oct 01 '15 at 10:04
  • @PaulMcKenzie. LoL!! This is a valid point though my top mgmt would never think in that direction when they are earning something out of it. Anyways this would be the ultimate solution(refactoring the code) for this problem..BTW this was my secondary priority for a month.. – Dhaya Oct 01 '15 at 10:08
  • @DanielStevens.. This is the kind of answer i was expecting.. But can u please elaborate your answer with some example.. Thanks..! – Dhaya Oct 01 '15 at 10:08
  • As soon as you have memory corruption anywhere in your code (writing past end of array, or to a dangling pointer of reference) anything can happen elsewhere. Example: `int i=0; int *j=&i; ...code not using i or j but doing memory corruption... int k = *j;` could SIGSEGV if memory corruption caused j to point to an unaccessible address. – Serge Ballesta Oct 01 '15 at 10:09
  • 1
    You said you understand the problem is "heap corruption" but then you immediately said things that imply you don't understand. You are focusing too much and asking too much about the point in the program where the symptom appears. The bug is unlikely to be anywhere near the symptom. You need an automated tool to check the whole program for bounds violations. – JSF Oct 01 '15 at 10:17
  • The Valgrind suggestion and one of the other suggestions seem to be Linux specific but the question was Windows specific. You need a tool on Windows that does what Valgrind does on Linux, such as "Rational Purify" or BoundsChecker. There might be something built into Visual Studio (I don't keep up on such details). – JSF Oct 01 '15 at 10:22
  • @JSF Thanks for the tool suggestions..! – Dhaya Oct 01 '15 at 10:27

0 Answers0