Re: [Boost-users] Strange issue with boost::date_time
On Tue, Apr 14, 2009 at 11:55 PM, Marshall Clow <marshall@idio.com> wrote:
At 3:20 PM -0700 4/14/09, Jared Lee Richardson wrote:
I'm going to try to remove even more code and narrow it down, and then I'll paste the offending code. Basically all I'm doing right now is initializing some time variables, then opening and reading from a file. It crashes on allocating 5 chars inside a function that reads from a file(or on allocating the class that contains a std::list<double> and a double).
Um - do you have a bad pointer somewhere, or a buffer overflow? When I see "Crashes while allocating", I think "heap corruption". -- -- Marshall
This is definitely my experience also. In fact if it is the only explanation for an access violation from a non-overloaded new operator that I am aware of. Hence I would be trying to find the perpetrator of the heap corruption. I suggest adding: #include <crtdbg.h> ... _CrtSetDbgFlag(_CRTDBG_CHECK_ALWAYS_DF); http://msdn.microsoft.com/en-us/library/5at7yxcs(VS.71).aspx This typically causes the offending code to be close to the region where the debugger stops. Often this finds the problem within minutes, however I have experienced problems with assertions attaching to the JIT debugger. Hence you may still be in trouble since you state that the debugger must be detached for the problem to occur. My hope is that the fault does occur with a debugger attached, but there are no obvious symptoms and that increasing the CRT checking will bring the problem to the fore. I hope this helps. Best wishes, Neil Groves
Hmm, ok then. I have a few more things I'll try tonight(go through the code by hand checking every pointer, etc.) I'm not able to use the crtdbg.h to solve this it looks like- crtdbg is only useful in debug, and the error does not seem to happen in debug(at least, not the same). I tried forcing it to run in debug by changing only the settings required for it - #undef _RELEASE, #define _DEBUG, changed runtime library from Multi-Threaded(/MT) to Multi-Threaded Debug(/MTd), however the program ran fine, no crash(or at least, not in that spot- my assertions triggered because I've removed so much code). I'll post again once I've tried some more things if nothing works. Thanks much Marshall and Neil. Jared On Tue, Apr 14, 2009 at 4:12 PM, Neil Groves <neil@grovescomputing.com> wrote:
On Tue, Apr 14, 2009 at 11:55 PM, Marshall Clow <marshall@idio.com> wrote:
At 3:20 PM -0700 4/14/09, Jared Lee Richardson wrote:
I'm going to try to remove even more code and narrow it down, and then I'll paste the offending code. Basically all I'm doing right now is initializing some time variables, then opening and reading from a file. It crashes on allocating 5 chars inside a function that reads from a file(or on allocating the class that contains a std::list<double> and a double).
Um - do you have a bad pointer somewhere, or a buffer overflow? When I see "Crashes while allocating", I think "heap corruption". -- -- Marshall
This is definitely my experience also. In fact if it is the only explanation for an access violation from a non-overloaded new operator that I am aware of. Hence I would be trying to find the perpetrator of the heap corruption. I suggest adding:
#include <crtdbg.h>
...
_CrtSetDbgFlag(_CRTDBG_CHECK_ALWAYS_DF);
http://msdn.microsoft.com/en-us/library/5at7yxcs(VS.71).aspx
This typically causes the offending code to be close to the region where the debugger stops. Often this finds the problem within minutes, however I have experienced problems with assertions attaching to the JIT debugger. Hence you may still be in trouble since you state that the debugger must be detached for the problem to occur. My hope is that the fault does occur with a debugger attached, but there are no obvious symptoms and that increasing the CRT checking will bring the problem to the fore.
I hope this helps.
Best wishes, Neil Groves
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Jared, On Wed, Apr 15, 2009 at 1:04 AM, Jared Lee Richardson <jaredr26@gmail.com>wrote:
Hmm, ok then. I have a few more things I'll try tonight(go through the code by hand checking every pointer, etc.)
Even though the Debug build appears to be symptom free you might want to try the _CrtSetDbgFlag(_CRTDBG_CHECK_ALWAYS_DF); approach. If your code is single threaded it should find any heap corruption within your code. If this is truly a Release build only issue then you might want to check the myriad of debug iterator preprocessor defines to ensure they are consistent between your project and the Boost.DateTime version you are using. Have you ensured that _SECURE_SCL=1 in your project for the Release configuration? If your project is fairly small and you are allowed, I would be happy for you to send the Visual Studio solution to my personal email address so that I can take a quick look at it. This might be the fastest way to proceed.
I'm not able to use the crtdbg.h to solve this it looks like- crtdbg is only useful in debug, and the error does not seem to happen in debug(at least, not the same). I tried forcing it to run in debug by changing only the settings required for it - #undef _RELEASE, #define _DEBUG, changed runtime library from Multi-Threaded(/MT) to Multi-Threaded Debug(/MTd), however the program ran fine, no crash(or at least, not in that spot- my assertions triggered because I've removed so much code).
Did you mean Multi-Threaded DLL (/MD) and Multi-Threaded Debug DLL (/MDd)? IIRC the Boost shared libraries build against the shared C runtime by default and these should not be mixed.
I'll post again once I've tried some more things if nothing works.
Thanks much Marshall and Neil.
Jared
I hope this helps, Neil Groves
On Wed, Apr 15, 2009 at 1:29 AM, Neil Groves <neil@grovescomputing.com> wrote:
Jared,
On Wed, Apr 15, 2009 at 1:04 AM, Jared Lee Richardson <jaredr26@gmail.com> wrote:
Hmm, ok then. I have a few more things I'll try tonight(go through the code by hand checking every pointer, etc.)
Even though the Debug build appears to be symptom free you might want to try the _CrtSetDbgFlag(_CRTDBG_CHECK_ ALWAYS_DF); approach. If your code is single threaded it should find any heap corruption within your code.
I tried this, and unfortunately no errors came up in debug. While thinking through how my code works, I did realize that I am probably using a bad pointer somewhere- This is my first project with a very heavy use of the STL, and I was maintaining pointers to objects inside vectors. Bad if the vector resizes and moves them elsewhere. However, none of that code is being hit or touched before this crash happens.
If this is truly a Release build only issue then you might want to check the myriad of debug iterator preprocessor defines to ensure they are consistent between your project and the Boost.DateTime version you are using. Have you ensured that _SECURE_SCL=1 in your project for the Release configuration?
As far as I know, I'm not using any iterators at all before this is hit. I added _SECURE_SCL 1 to my global defines, but no help.
If your project is fairly small and you are allowed, I would be happy for you to send the Visual Studio solution to my personal email address so that I can take a quick look at it. This might be the fastest way to proceed.
Sure- I tried everything I knew how this morning, and nothing fixed it. Sending you a separate email with that. Thanks for that Neil, much appreciated. :)
I'm not able to use the crtdbg.h to solve this it looks like- crtdbg is only useful in debug, and the error does not seem to happen in debug(at least, not the same). I tried forcing it to run in debug by changing only the settings required for it - #undef _RELEASE, #define _DEBUG, changed runtime library from Multi-Threaded(/MT) to Multi-Threaded Debug(/MTd), however the program ran fine, no crash(or at least, not in that spot- my assertions triggered because I've removed so much code).
Did you mean Multi-Threaded DLL (/MD) and Multi-Threaded Debug DLL (/MDd)? IIRC the Boost shared libraries build against the shared C runtime by default and these should not be mixed.
I had used the BoostPro downloader to specifically download the static link libraries. However, on the chance it would help, I re-downloaded the DLL's and changed it to /MD and /MDd. The crash simply jumped to a later spot in code. Thanks, Jared
participants (2)
-
Jared Lee Richardson -
Neil Groves