Re: [Boost-users] Strange issue with boost::date_time

Subject: Re: [Boost-users] Strange issue with boost::date_time
From: Jared Lee Richardson (jaredr26_at_[hidden])
Date: 2009-04-14 20:04:28

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_at_[hidden]> wrote:
>
> On Tue, Apr 14, 2009 at 11:55 PM, Marshall Clow <marshall_at_[hidden]> 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_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users
>