Application crashes only in release mode (possible heap/stack corruption)
-
Hi all, I am writing an app using C++, Visual Studio 2008 and Qt. I have been working on a certain section of code, and i have it working now without any problems. That is in debug mode. When i compiled it in release mode the other day, the app crashed (access violation) when i performed a certain action (selecting an item from a combo box). This did not happen in debug mode, and it happens consistently whenever i switch back to compiling in release. My app is similar to Spy++ or Winspector and it uses a hook to monitor other window's messages. It does this by injecting a DLL in other processes. When i first tried to debug the crash in VS, the stack trace included the hook procedure and it even showed me the code (which is strangle because the DLL should have been built without symbols too). It was indicating that the crash was around the call to CallNextHookEx. But i don't think it has anything to do with that because when i commented out the hook code, the crash still happened. I suspect it is due to memory corruption, but i don't know how to be sure. Basically, i am asking for any tips on how to debug such a situation. I cannot step through the code as there are no symbols in release mode, and the DLLs in other processes only makes debugging harder. Since i have no idea what could be causing the crash, i will not post any code. However, i will upload the entire source (to my SourceForge site) and post a link to it so that you can browse though it if you like. If it helps, the assembly where the crash happened is:
004320EE mov edx,dword ptr [eax+ecx*4+14h][Window Detective] - Windows UI spy utility
modified on Thursday, December 9, 2010 5:50 PM
-
Hi all, I am writing an app using C++, Visual Studio 2008 and Qt. I have been working on a certain section of code, and i have it working now without any problems. That is in debug mode. When i compiled it in release mode the other day, the app crashed (access violation) when i performed a certain action (selecting an item from a combo box). This did not happen in debug mode, and it happens consistently whenever i switch back to compiling in release. My app is similar to Spy++ or Winspector and it uses a hook to monitor other window's messages. It does this by injecting a DLL in other processes. When i first tried to debug the crash in VS, the stack trace included the hook procedure and it even showed me the code (which is strangle because the DLL should have been built without symbols too). It was indicating that the crash was around the call to CallNextHookEx. But i don't think it has anything to do with that because when i commented out the hook code, the crash still happened. I suspect it is due to memory corruption, but i don't know how to be sure. Basically, i am asking for any tips on how to debug such a situation. I cannot step through the code as there are no symbols in release mode, and the DLLs in other processes only makes debugging harder. Since i have no idea what could be causing the crash, i will not post any code. However, i will upload the entire source (to my SourceForge site) and post a link to it so that you can browse though it if you like. If it helps, the assembly where the crash happened is:
004320EE mov edx,dword ptr [eax+ecx*4+14h][Window Detective] - Windows UI spy utility
modified on Thursday, December 9, 2010 5:50 PM
1.) you can compile a release with the option 'generate debug info' too. 2.) insert beeps or log-infos to localize the buggy code position. 3.) initialize all memory allocated by zero also static and local member. 4.) enshure you don't write beyond allocated memory. 5.) the debug version: checks memory (allocating more than neccessary and fill them with special values). also debug: checks the stack integrity. 6.) use the same compiler/linker options for release same as debug. 7.) turn on multithreading option.
-
Hi all, I am writing an app using C++, Visual Studio 2008 and Qt. I have been working on a certain section of code, and i have it working now without any problems. That is in debug mode. When i compiled it in release mode the other day, the app crashed (access violation) when i performed a certain action (selecting an item from a combo box). This did not happen in debug mode, and it happens consistently whenever i switch back to compiling in release. My app is similar to Spy++ or Winspector and it uses a hook to monitor other window's messages. It does this by injecting a DLL in other processes. When i first tried to debug the crash in VS, the stack trace included the hook procedure and it even showed me the code (which is strangle because the DLL should have been built without symbols too). It was indicating that the crash was around the call to CallNextHookEx. But i don't think it has anything to do with that because when i commented out the hook code, the crash still happened. I suspect it is due to memory corruption, but i don't know how to be sure. Basically, i am asking for any tips on how to debug such a situation. I cannot step through the code as there are no symbols in release mode, and the DLLs in other processes only makes debugging harder. Since i have no idea what could be causing the crash, i will not post any code. However, i will upload the entire source (to my SourceForge site) and post a link to it so that you can browse though it if you like. If it helps, the assembly where the crash happened is:
004320EE mov edx,dword ptr [eax+ecx*4+14h][Window Detective] - Windows UI spy utility
modified on Thursday, December 9, 2010 5:50 PM
you could tell the linker to produce a link map, then use that to identify which function contains
004320EE mov edx,dword ptr [eax+ecx*4+14h]:)Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, and update CP Vanity to V2.0 if you haven't already.
-
you could tell the linker to produce a link map, then use that to identify which function contains
004320EE mov edx,dword ptr [eax+ecx*4+14h]:)Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, and update CP Vanity to V2.0 if you haven't already.
How would i do that :) By the way, it is ecx that contains a rather large number, which is causing the expression to access invalid memory. So i imagine that ecx should normally contain a valid value.
[Window Detective] - Windows UI spy utility
-
How would i do that :) By the way, it is ecx that contains a rather large number, which is causing the expression to access invalid memory. So i imagine that ecx should normally contain a valid value.
[Window Detective] - Windows UI spy utility
based on the virtual address. :)
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, and update CP Vanity to V2.0 if you haven't already.
-
Hi all, I am writing an app using C++, Visual Studio 2008 and Qt. I have been working on a certain section of code, and i have it working now without any problems. That is in debug mode. When i compiled it in release mode the other day, the app crashed (access violation) when i performed a certain action (selecting an item from a combo box). This did not happen in debug mode, and it happens consistently whenever i switch back to compiling in release. My app is similar to Spy++ or Winspector and it uses a hook to monitor other window's messages. It does this by injecting a DLL in other processes. When i first tried to debug the crash in VS, the stack trace included the hook procedure and it even showed me the code (which is strangle because the DLL should have been built without symbols too). It was indicating that the crash was around the call to CallNextHookEx. But i don't think it has anything to do with that because when i commented out the hook code, the crash still happened. I suspect it is due to memory corruption, but i don't know how to be sure. Basically, i am asking for any tips on how to debug such a situation. I cannot step through the code as there are no symbols in release mode, and the DLLs in other processes only makes debugging harder. Since i have no idea what could be causing the crash, i will not post any code. However, i will upload the entire source (to my SourceForge site) and post a link to it so that you can browse though it if you like. If it helps, the assembly where the crash happened is:
004320EE mov edx,dword ptr [eax+ecx*4+14h][Window Detective] - Windows UI spy utility
modified on Thursday, December 9, 2010 5:50 PM
Please read this: Surviving the release version[^]
It was ever thus, the Neophiles will always rush out and get 'The Latest Thing' at a high price and with all the inherent faults - Dalek Dave.
-
based on the virtual address. :)
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, and update CP Vanity to V2.0 if you haven't already.
Sorry, i still don't know what you are talking about. You seem to be saying that there is a way to find the function which that line of code is in. While i understand that it may technically be possible, i have no idea how to do it. btw, thanks to everyone else who replied.
[Window Detective] - Windows UI spy utility
-
Sorry, i still don't know what you are talking about. You seem to be saying that there is a way to find the function which that line of code is in. While i understand that it may technically be possible, i have no idea how to do it. btw, thanks to everyone else who replied.
[Window Detective] - Windows UI spy utility
XTAL256 wrote:
thanks to everyone else
No thanks then. :)
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, and update CP Vanity to V2.0 if you haven't already.
-
XTAL256 wrote:
thanks to everyone else
No thanks then. :)
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, and update CP Vanity to V2.0 if you haven't already.
Well, i was going to thank you once you clarified your previous post. But since you gave me the lmgtfy response, i don't think i will :). Just kidding.
[Window Detective] - Windows UI spy utility
-
Hi all, I am writing an app using C++, Visual Studio 2008 and Qt. I have been working on a certain section of code, and i have it working now without any problems. That is in debug mode. When i compiled it in release mode the other day, the app crashed (access violation) when i performed a certain action (selecting an item from a combo box). This did not happen in debug mode, and it happens consistently whenever i switch back to compiling in release. My app is similar to Spy++ or Winspector and it uses a hook to monitor other window's messages. It does this by injecting a DLL in other processes. When i first tried to debug the crash in VS, the stack trace included the hook procedure and it even showed me the code (which is strangle because the DLL should have been built without symbols too). It was indicating that the crash was around the call to CallNextHookEx. But i don't think it has anything to do with that because when i commented out the hook code, the crash still happened. I suspect it is due to memory corruption, but i don't know how to be sure. Basically, i am asking for any tips on how to debug such a situation. I cannot step through the code as there are no symbols in release mode, and the DLLs in other processes only makes debugging harder. Since i have no idea what could be causing the crash, i will not post any code. However, i will upload the entire source (to my SourceForge site) and post a link to it so that you can browse though it if you like. If it helps, the assembly where the crash happened is:
004320EE mov edx,dword ptr [eax+ecx*4+14h][Window Detective] - Windows UI spy utility
modified on Thursday, December 9, 2010 5:50 PM
fyi, i found the problem. I stupidly forgot to return a value from a function. I only just picked it up then when the compiler told me that "not all control paths return a value". I guess i missed that warning previously.
[Window Detective] - Windows UI spy utility