Member Avatar for KJLakshmi

I have build a dynamic library in both debug and release mode. In the Source code of this libray relloc() function is used. I am linking this libray to my executable application. When i execute the application in debug mode, the application is crashing with the following message

"Unhandled exception at 0x7c90120e in MyApplication.exe: User breakpoint."

When I debug, the application is crashing as realloc() function call.

But when I run in release mode the application is working fine.

Can any body know the reason why the crash is occurring in debug mode and how to fix this problem??

Thank in advance.

  • 3 Contributors
  • 4 Replies
  • 185 Views
  • 17 Hours Discussion Span
  • Latest Post Latest Post by Ancient Dragon

Dani AI

Generated

Short diagnosis and next steps (follow and but dig deeper)

If allocation/free/realloc are truly all done inside the same DLL but you only crash in Debug, two things are by far the most common causes: (A) the debug C runtime is detecting heap corruption that the release build doesn’t catch, or (B) the executable and the DLL are using different C runtime heaps (different CRT linkage/versions). Microsoft documents both problems and why they look like a sudden crash at realloc. (learn.microsoft.com)

Quick checklist to run now

  • Verify the runtime-library setting for every project (EXE and all DLLs). For Visual C++ you should use the same CRT choice for matching configurations (Debug => /MDd, Release => /MD), otherwise each module has its own heap. (learn.microsoft.com)
  • Reproduce under the debugger, break on the assertion, inspect the pointer/size passed to realloc (as suggested). Use the safe realloc pattern so you don’t lose the old pointer on failure:
    void *tmp = realloc(ptr, newSize);
if (tmp) ptr = tmp;   // success: use tmp
else /* handle OOM; ptr still valid */;
  • Turn on CRT debug checks (_CrtCheckMemory, _CrtSetDbgFlag, _CrtSetBreakAlloc) to get allocation numbers and stack traces when the debug heap asserts. See the CRT debug routine docs. (learn.microsoft.com)

If you need a robust fix for cross-module buffers

  • Export allocation/free (or realloc) functions from the DLL so the same CRT code performs both operations, for example:
    extern "C" __declspec(dllexport) void* MyLib_Realloc(void* p, size_t n){ return realloc(p,n); }
extern "C" __declspec(dllexport) void  MyLib_Free(void* p){ free(p); }
  • Or allocate from the process heap (HeapAlloc/GetProcessHeap) which is safe across modules:
    void* p = HeapAlloc(GetProcessHeap(),0,bytes); // free with HeapFree(...)

    (Win32 Heap API doc). (learn.microsoft.com)

If after these checks the crash persists, run Application Verifier or page-heap to catch overruns/underruns—they catch errors that only appear in debug-time checks. (learn.microsoft.com)

Summary: confirm CRT linkage settings, enable CRT debug checks and safe realloc handling, then either keep allocation+free inside the same module or switch to a shared allocator (DLL export or HeapAlloc). That sequence will usually reveal or eliminate the bug.

Recommended Answers

All 4 Replies

Member Avatar for Ancient Dragon

Memory allocated in a dll must be free'ed in the same dll. Likewise, memory allocated in the application program must be realloc'ed or free'ed in that same application program. You can't allocate in one and realloc or free in the other. The reason is that they use different allocation pools (heaps).

>>and how to fix this problem
There is none, other than to do it correctly.

Additioonal information here

from one of the Microsoft developers (I think it is) He makes the suggestion how to resolve the problem.

Edited by Ancient Dragon because: n/a
Member Avatar for KJLakshmi

Allocation, reallocation and free is done in the some libray module.

Same code is working fine in release mode.

Member Avatar for sree_ec

Allocation, reallocation and free is done in the some libray module.

Same code is working fine in release mode.

Have you made sure that your memory is not released somewhere else before realloc() call?
Have you done proper return checks of re alloc?
Are you able to see the values of pointer and size are proper before you pass it to realloc using a debugger?

Member Avatar for Ancient Dragon

It could, of course, be some other problem in the code which just shows up during realloc. Strange things happen after buffer overruns or other problems.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.