User forums > Help

stop at ntdll!DbgUiConnectToDbg () on debug start

(1/4) > >>

Hitnrun:
I have a project, that everytime I start in debug mode, I get:


--- Code: ---Program received signal SIGTRAP, Trace/breakpoint trap.
In ntdll!DbgUiConnectToDbg () (ntdll.dll)

--- End code ---

If I press Ctrl-F7 about 50 (!) times, it runs, but at various points on the application I get it again.

There are no breapoints set on CodeBlocks, why is it stopping at a breakpoint trap?

Hitnrun:
Running in console mode gdb, I get a more detailed message:



--- Code: ---Invalid Address specified to RtlFreeHeap

--- End code ---

All the times, looks like it is when including an external DLL (FreeImage).

thomas:
Though it's impossible to tell the real reasons, I see two possibilities.
1. variables not being initialised properly are the most common reason for "only crashes in debugger" kind of error.
2. "Invalid Address specified to RtlFreeHeap" is sometimes encountered in otherwise correct code, if there is an executable and a DLL, one of which was built in debug mode and the other one in release mode. That will create two different heaps managed by two heap managers, which will cause heap corruption whenever pointers are handed from one to the other (so basically, all the time in most programs). This may generate an error which the debugger catches, or may go silently otherwise, or may crash at a random later time.

Hitnrun:

--- Quote from: thomas on May 19, 2008, 09:12:34 am ---2. "Invalid Address specified to RtlFreeHeap" is sometimes encountered in otherwise correct code, if there is an executable and a DLL, one of which was built in debug mode and the other one in release mode. That will create two different heaps managed by two heap managers, which will cause heap corruption whenever pointers are handed from one to the other (so basically, all the time in most programs). This may generate an error which the debugger catches, or may go silently otherwise, or may crash at a random later time.

--- End quote ---

Hmm the DLL was built by VC2005, but the program is using mingw, does this apply in this case too? Would building the DLL as debug in VC overcome heap corruption problems in mingw applications?

thomas:
Good question, I don't know what MinGW uses for memory allocation/deallocation.
But building the DLL in debug mode would be my first try, since debug+release is known to cause problems in any case.

Navigation

[0] Message Index

[#] Next page