Sign in to follow this  
Deliverance

How to debug _CrtIsValidHeapPointer in libvorbis

Recommended Posts

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).

Share this post


Link to post
Share on other sites
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 :)

Share this post


Link to post
Share on other sites
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


Share this post


Link to post
Share on other sites
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]

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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]

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this