abababab() - what to do?

dennisV

Hello all, I need help here - there's a pointer corruption somewhere (I guess), and the debugger throws me out with the following call stack: ntdll.dll! 77f75a58() abababab() That's it! Could someone tell me how to debug this and see what's happening and where? Oh, it also says this in the output window: HEAP[my.exe]: Heap block at 0181FC40 modified at 0182051C past requested size of 8d4 TIA

Prakash Nadar

There may be cases where due to wrong programming logic may coz errors in the system dlls... you need to check out ur programm properly first. The World is getting smaller and so are the people.

dennisV

Mr.Prakash wrote: There may be cases where due to wrong programming logic may coz errors in the system dlls... you need to check out ur programm properly first. Well, I did spend a lot of time checking it out otherwise I wouldn't be asking for help ;) It's narrowed down to one function, but I need to trace through it to see where exactly things go wrong and I can't do that without a callstack. And if I put a breakpoint in that function just before it is supposed to return an error, if overwrites the memory and I never hit my breakpoint, things just assert.

Prakash Nadar

Are u using MFC or not, If you are using MFC then make sure that you have not accidently included any cpp file in ur workspace that belonges to the core MFC. other than this i cant help you, I had similar prob (not exact) my program logic was correct but due to inclution of a core mfc cpp file in my project ( which i did accidently) my software used to fail terribaly. regards, The World is getting smaller and so are the people.

dennisV

Yes, I am using MFC and I'll check if there are any core MFC files included in the project, there are included in my stdafx.h of course, but I guess you mean if it's actually included and shows up in the Solution tab? I've narrowed the problem to one function that does in-memory array manipulation, but I have no idea why it fails, it looks innocent enough. Thanks.

Prakash Nadar

Yeah is any mfc core file included in ur solution, (workspace) Like i said i had similar prob, when any core file is included, even the most inocent looking code will through exceptions. The World is getting smaller and so are the people.

dennisV

Nope, just checked and there're no core files directly included in my workspace :confused: It's a really strange problem.

Mike Dimmick

You need the debugging symbols for your platform. NTDLL and many other system DLLs are compiled with an option called Frame Pointer Omission turned on. When compiling a function, the compiler normally uses the EBP register to point to the beginning of the function's local registers on the stack (the frame), storing the old value of EBP at the top of the stack first. However, if this optimisation is turned on, the compiler can decide to omit the set-up and tear-down of EBP - this also allows it to use EBP for other purposes. When it does this, it notes the fact in the debugging information, if any is generated. The debugger takes one of two approaches in walking a stack. If it has debugging information, it consults to see if FPO data is available for the function - this tells it where to find the beginning of the frame and therefore where the return address is stored (and what the return address is). Otherwise, if there is no FPO data or no debugging information, it looks for the return address in a memory location near the value of EBP. In this case, EBP is pointing somewhere other than at the stack. To fix this, get the OS debug symbols. You have two options: you can either download a full symbol pack[^], or you can use Microsoft's symbol server[^] to download only the required symbols. If you have Visual C++ .NET (2002 or 2003), you can use the symbol server; see Using a Symbol Server[^] in the VS.NET documentation. If you're using VC6, you'll have to use the full symbol package or download the Debugging Tools for Windows[^], and use WinDBG to debug instead. Symbol packages have the unfortunate disadvantage that they're only updated for each O

n 0

That °%$$! happened to me too once. this problem can happen if you use a pointer ( or a pointer to a pointer ....a.s.o. ) incorrectly, like so: char* lpstr = (char*)malloc(5 * sizeof(char)), *p; // ... while( /* sth */ ) *p++ = *lpstr++; // ... strcpy(lpstr, "12345"); // or free((void*)lpstr); so check out step-by-step if your variable remains at it's original position. don't no if this could help you out... Phil

dennisV

Thank you - I'm using VC++ 2002, and I'll check out your suggestions on heap debugging. In Debug mode the program reports this error, in Release is just silently throws me out back to Windows (which is understandable).

dennisV

Thank you for the reply - there's actually a similar code that modifies the variable in question... And that's what's causing the problem, I guess. I have been staring at it for a day now, I guess I'll do so some more ;) Perhaps it sometimes adds one extra pointer and moves it beyond the boundary...