How to debug _CrtIsValidHeapPointer in libvorbis

Started by
5 comments, last by Deliverance 14 years, 7 months ago
This is stressing me so much! It's a weird error that occurs very often but not all the time. Basically if i change the build mode from debug to release and viceversa and then clean & build it will eventually show up. This error show up at program initializaion at the very first time vorbis_synthesis_init is called. The code looks like this:

int main()
{	
   vorbis_info vi = {0};
   vorbis_info_init(&vi); 
   vorbis_info_clear (&vi);       // crash occurs here

   // other stuff
   .... 
}




And the stack looks like this:

 	ntdll.dll!7c901230() 	
 	[Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll]	
 	ntdll.dll!7c96c943() 	
 	ntdll.dll!7c96cd80() 	
 	ntdll.dll!7c960af8() 	
 	kernel32.dll!7c85e9cf() 	
 	Endeavour.exe!_CrtIsValidHeapPointer(const void * pUserData=0x003d5fb8)  Line 2103	C++
 	Endeavour.exe!_free_dbg_nolock(void * pUserData=0x003d5fb8, int nBlockUse=1)  Line 1317 + 0x9 bytes	C++
 	Endeavour.exe!_free_dbg(void * pUserData=0x003d5fb8, int nBlockUse=1)  Line 1258 + 0xd bytes	C++
 	Endeavour.exe!free(void * pUserData=0x003d5fb8)  Line 49 + 0xb bytes	C++
 	Endeavour.exe!_vorbis_info_clear()  + 0x14e bytes	
>	Endeavour.exe!main()  Line 149 + 0x9 bytes	C++
 	Endeavour.exe!__tmainCRTStartup()  Line 266 + 0x19 bytes	C
 	Endeavour.exe!mainCRTStartup()  Line 182	C
 	kernel32.dll!7c816fd7() 	





I'm wondering what debug options i have in this case. It seems i'm running out of ideas... Also, I am using the latest vorbis library. I am assuming this is my fault because if i compile only 1 .cpp(main) with the code posted above it does not crash(currently i am compiling more than one source file but the code that crashes is always called first).
Advertisement
The first thing you can do is go to "Tools->Options->Debugging->Symbols" in MSVC and add "http://msdl.microsoft.com/download/symbols" as a symbol file location (and also select a local folder like "C:\Symbols" as the cache). This will download symbols for all the system modules. At least you'll get a better idea what it's doing when it crashes in ntdll.

If it only happens when other source files are compiled, then it could be a static initialization bug. However these types of bugs are usually quite tricky to track down, so without having all your source to debug it's really not easy to tell what could be happening. But do get those symbols and report back :)
Quote:Original post by Zipster
The first thing you can do is go to "Tools->Options->Debugging->Symbols" in MSVC and add "http://msdl.microsoft.com/download/symbols" as a symbol file location (and also select a local folder like "C:\Symbols" as the cache). This will download symbols for all the system modules. At least you'll get a better idea what it's doing when it crashes in ntdll.

If it only happens when other source files are compiled, then it could be a static initialization bug. However these types of bugs are usually quite tricky to track down, so without having all your source to debug it's really not easy to tell what could be happening. But do get those symbols and report back :)


Okay here it is :D :

>	ntdll.dll!_DbgBreakPoint@0() 	 	ntdll.dll!_RtlpBreakPointHeap@4()  + 0x28 bytes	 	ntdll.dll!_RtlpValidateHeapEntry@12()  + 0x113 bytes	 	ntdll.dll!_RtlValidateHeap@12()  + 0xe0 bytes	 	kernel32.dll!_HeapValidate@12()  + 0x14 bytes	 	end2.exe!_CrtIsValidHeapPointer(const void * pUserData=0x00ee5fc8)  Line 2103	C++ 	end2.exe!_free_dbg_nolock(void * pUserData=0x00ee5fc8, int nBlockUse=1)  Line 1317 + 0x9 bytes	C++ 	end2.exe!_free_dbg(void * pUserData=0x00ee5fc8, int nBlockUse=1)  Line 1258 + 0xd bytes	C++ 	end2.exe!free(void * pUserData=0x00ee5fc8)  Line 49 + 0xb bytes	C++ 	end2.exe!_vorbis_info_clear()  + 0x14e bytes	 	end2.exe!main()  Line 144 + 0x9 bytes	C++ 	end2.exe!__tmainCRTStartup()  Line 266 + 0x19 bytes	C 	end2.exe!mainCRTStartup()  Line 182	C 	kernel32.dll!_BaseProcessStart@4()  + 0x23 bytes	
Check out this page and this page, which have some tips for finding heap corruption. You can either use Pageheap.exe or gflags.
Quote:Original post by Zipster
Check out this page and this page, which have some tips for finding heap corruption. You can either use Pageheap.exe or gflags.


Thanks a lot! I think it is solved now. After using bflags i noticed that it is recommended to link the application with release version of CRT library. So i did link like that, but i got some link errors. I added the following link flag: /NODEFAULTLIB:LIBCMT and now the problem seems to be gone, if i remove this flag and link again(EDIT: with debug crt for debug target) i get the crash, add it again and it runs fine. Shameful enough i was getting a warning saying that libcmt is conflicting with other libraries but ignored it... I'm wondering if such a thing seems logical or i just hid the defect more?

Also the same code ran fine on mac os x Leopard. I was joking and said: if it runs on windows it isn't necessary to run on a mac, but if the same code compiled on mac works and i compile it again on windows then it must work almost every time :D. I used only cross platform technologies and that's why i can use it both on mac and windows.


[Edited by - Deliverance on September 9, 2009 7:57:14 AM]
If you're getting link errors like LNK2005 with CRT functions, then it means you're trying to mix and match the CRT (i.e. static and dynamic, debug and release) across your libraries, which is bad and can introduce all sorts of weird behavior. Make sure all the libraries you link against use the runtime the same way. If you don't want to mess up any of your existing configurations then it's trivial to add a new one.
Quote:Original post by Zipster
If you're getting link errors like LNK2005 with CRT functions, then it means you're trying to mix and match the CRT (i.e. static and dynamic, debug and release) across your libraries, which is bad and can introduce all sorts of weird behavior. Make sure all the libraries you link against use the runtime the same way. If you don't want to mess up any of your existing configurations then it's trivial to add a new one.


Yes, i tried not to mix them, it seems i failed somewhere :D, because there a like 8 libraries.

EDIT: Solved! the warning that libcmt is conflicting with other libraries is serious and the correct way of dealing with it is not with /NODEFAULTLIB:LIBCMT. The way to go is to link all libraries with the same flags to the CRT libraries. Also, it is important not to mix and match debug & release versions of the CRT libraries. Or... so i've learned :D.

[Edited by - Deliverance on September 9, 2009 11:54:18 PM]

This topic is closed to new replies.

Advertisement