Strange issue with boost::date_time
I'm having a strange issue with the boost::date_time library - My program runs fine with both release and debug compilations, but will not run in standalone / the command line. I.e., the program works when I run it through the MS visual studio debugger, whether the program is built with debugging symbols or not. It also ran correctly when run through dependency walker. It does not run when run without either of those, i.e. on a command line. Through print statements I determined that it is running through the initialization and crashes(windows brings up the crashed executable dialog, "This.exe has encountered a problem and needs to close.") The exact code it crashes on is the allocation of a class that contains time_durations: class TempClass { public: list<time_duration> TDList; time_duration SomeOtherDuration; }; and then crashes when allocating this object: TempClass* pTempClass; pTempClass = new TempClass; // <--- Crashes when run without debugger. The program crashes on the new. I tried putting a try/catch block around it for any exception to see if any were being hit and none are. I had tried to reproduce this issue in a much simpler program, but have not had any luck thus far - the test program always runs correctly. Any ideas or things to try? This is not the first instantiation of a time_duration(pushed into a vector a few lines before this), but may be the first instantiation of a std::list. The pointer listed above is actually a member of another class that is contained in a vector, if that matters(shouldn't). Any help? If not I can try again at creating a simpler program that exhibits the problem and paste it. Thanks, Jared
Perhaps try to make it a release build and then switch on some symbols if possible ? On Mon, Apr 13, 2009 at 10:55 PM, Jared Lee Richardson <jaredr26@gmail.com>wrote:
I'm having a strange issue with the boost::date_time library - My program runs fine with both release and debug compilations, but will not run in standalone / the command line. I.e., the program works when I run it through the MS visual studio debugger, whether the program is built with debugging symbols or not. It also ran correctly when run through dependency walker.
It does not run when run without either of those, i.e. on a command line. Through print statements I determined that it is running through the initialization and crashes(windows brings up the crashed executable dialog, "This.exe has encountered a problem and needs to close.") The exact code it crashes on is the allocation of a class that contains time_durations:
class TempClass { public: list<time_duration> TDList; time_duration SomeOtherDuration; };
and then crashes when allocating this object:
TempClass* pTempClass; pTempClass = new TempClass; // <--- Crashes when run without debugger.
The program crashes on the new. I tried putting a try/catch block around it for any exception to see if any were being hit and none are. I had tried to reproduce this issue in a much simpler program, but have not had any luck thus far - the test program always runs correctly.
Any ideas or things to try? This is not the first instantiation of a time_duration(pushed into a vector a few lines before this), but may be the first instantiation of a std::list. The pointer listed above is actually a member of another class that is contained in a vector, if that matters(shouldn't).
Any help? If not I can try again at creating a simpler program that exhibits the problem and paste it.
Thanks, Jared _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
I'm having a strange issue with the boost::date_time library - My program runs fine with both release and debug compilations, but will not run in standalone / the command line. I.e., the program works when I run it through the MS visual studio debugger, whether the program is built with debugging symbols or not. It also ran correctly when run through dependency walker.
Ensure that all your libs are built with the same CRT/ STL options (threading, _SECURE_SCL etc.)
On Tue, Apr 14, 2009 at 1:56 AM, Igor R <boost.lists@gmail.com> wrote:
I'm having a strange issue with the boost::date_time library - My program runs fine with both release and debug compilations, but will not run in standalone / the command line. I.e., the program works when I run it through the MS visual studio debugger, whether the program is built with debugging symbols or not. It also ran correctly when run through dependency walker.
Ensure that all your libs are built with the same CRT/ STL options (threading, _SECURE_SCL etc.)
Hmm, I tried to find anything on that, but I couldn't. I'm not sure what the boost libraries I'm using were built with, but I don't have anything special in my builds. No multithreading(yet), none of those defines.
Perhaps try to make it a release build and then switch on some symbols if possible ?
Actually it runs fine without any symbols at all. It only crashes if no other program is hooked, like a debugger or dependencywalker. I discovered that the problem happens/can happen on one of several new calls, but only when linking to the date_time libraries. I removed everything from my project except the offending code, and the crash only went away when I stopped linking to date_time. I even changed the type of variable I am allocating to double instead of time_duration, and it only goes away if I stop linking to date_time. 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). Any other ideas? Thanks, Jared.
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 Marshall Clow Idio Software <mailto:marshall@idio.com> It is by caffeine alone I set my mind in motion. It is by the beans of Java that thoughts acquire speed, the hands acquire shaking, the shaking becomes a warning. It is by caffeine alone I set my mind in motion.
This seems like it has something to do with what is loaded by default withing an development environment. Also, since this is windows, rule out the standard suspects. Break out dependency walker, and check what dll's are being loaded. Debug and release dll's may be different, and this could possibly cause a problem. Also it might be possible, in the release build, some dll is not available or even some weird manifest issue that prevents the loading of the correct dll. This usually appears at start but who knows. Since DateTime is a library (not header only), confirm that both a debug and release build exist, or at least that the library that your executable is using exists and that the dll's that the datetime library is linked against are compatible with the ones that your executable are using. Carl Jared Lee Richardson wrote:
On Tue, Apr 14, 2009 at 1:56 AM, Igor R <boost.lists@gmail.com> wrote:
I'm having a strange issue with the boost::date_time library - My program runs fine with both release and debug compilations, but will not run in standalone / the command line. I.e., the program works when I run it through the MS visual studio debugger, whether the program is built with debugging symbols or not. It also ran correctly when run through dependency walker. Ensure that all your libs are built with the same CRT/ STL options (threading, _SECURE_SCL etc.)
Hmm, I tried to find anything on that, but I couldn't. I'm not sure what the boost libraries I'm using were built with, but I don't have anything special in my builds. No multithreading(yet), none of those defines.
Perhaps try to make it a release build and then switch on some symbols if possible ?
Actually it runs fine without any symbols at all. It only crashes if no other program is hooked, like a debugger or dependencywalker.
I discovered that the problem happens/can happen on one of several new calls, but only when linking to the date_time libraries. I removed everything from my project except the offending code, and the crash only went away when I stopped linking to date_time. I even changed the type of variable I am allocating to double instead of time_duration, and it only goes away if I stop linking to date_time.
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).
Any other ideas?
Thanks, Jared. _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
-- Carl Zmola czmola@woti.com
On Wed, Apr 15, 2009 at 7:57 AM, Carl Zmola <czmola@woti.com> wrote:
This seems like it has something to do with what is loaded by default withing an development environment.
Thats what I thought also when I saw it run with dependencywalker. Maybe it was trying to use a different DLL when loaded through another program?
Also, since this is windows, rule out the standard suspects.
Break out dependency walker, and check what dll's are being loaded. Debug and release dll's may be different, and this could possibly cause a problem. Also it might be possible, in the release build, some dll is not available or even some weird manifest issue that prevents the loading of the correct dll. This usually appears at start but who knows.
Ok, what do I look for in dependency walker? I run it and only see 4 errors: GetProcAddress(0x7C800000 [c:\windows\system32\KERNEL32.DLL], "FlsAlloc") called from "c:\windows\winsxs\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.1_x-ww_6f74963e\MSVCR90.DLL" at address 0x78543ACC and returned NULL. Error: The specified procedure could not be found (127). GetProcAddress(0x7C800000 [c:\windows\system32\KERNEL32.DLL], "FlsGetValue") called from "c:\windows\winsxs\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.1_x-ww_6f74963e\MSVCR90.DLL" at address 0x78543AD9 and returned NULL. Error: The specified procedure could not be found (127). GetProcAddress(0x7C800000 [c:\windows\system32\KERNEL32.DLL], "FlsSetValue") called from "c:\windows\winsxs\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.1_x-ww_6f74963e\MSVCR90.DLL" at address 0x78543AE6 and returned NULL. Error: The specified procedure could not be found (127). GetProcAddress(0x7C800000 [c:\windows\system32\KERNEL32.DLL], "FlsFree") called from "c:\windows\winsxs\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.1_x-ww_6f74963e\MSVCR90.DLL" at address 0x78543AF3 and returned NULL. Error: The specified procedure could not be found (127). Are those something that could cause this or that I should be worried about? The main DLL's I'm linking against according to dependency walker are KERNEL32.DLL, MSVCP90.DLL, MSVCR90.DLL. In addition, as I mentioned, the program runs fine with depends debugging it. Also, as I've found by printing debug text, the crash happens on a new/allocation call. However, it is not the first new call, and changing some things can cause the location of the crash to move. I.e., I changed from /MT to /MD compiles as per Neil's suggestion and the crash moved to a slightly later new call.
Since DateTime is a library (not header only), confirm that both a debug and release build exist, or at least that the library that your executable is using exists and that the dll's that the datetime library is linked against are compatible with the ones that your executable are using.
As far as I can tell, this is all functioning as it should. I'm using Boost 1.38.0 downloaded through BoostPro. I selected the options to download the static libraries first and tried /MT. Then I re-did it and downloaded the DLL's, and changed it to /MD. I have had some linker errors, but it was usually when I tried to link release-compiled code with debug libraries, or tried to use /MD without having the DLL version downloaded.
Carl
Thanks Carl... Any other things to try? Jared
Bad if the vector resizes and moves them elsewhere
std::vector guarantees that its elements are stored in a contiguous memory block, so it definitely moves the data on resize and invalidates iterators.
I changed from /MT to /MD compiles as per Neil's suggestion and the crash moved to a slightly later new call.
This strengthens the assumption that you've got a heap corruption.
On Wed, Apr 15, 2009 at 10:25 AM, Igor R <boost.lists@gmail.com> wrote:
Bad if the vector resizes and moves them elsewhere
std::vector guarantees that its elements are stored in a contiguous memory block, so it definitely moves the data on resize and invalidates iterators.
I changed from /MT to /MD compiles as per Neil's suggestion and the crash moved to a slightly later new call.
This strengthens the assumption that you've got a heap corruption.
Hmm, wow, ok I think you were right, but it was really subtle. :( //String is read in from file, delimited. char string[32]; File.getline(string, 32, '"'); int Length = strlen(string); // <-- Does not include Null character! char* Name = new char[Length]; // <-- One char too small strcpy(Name, string); // <-- Corrupted 1 byte after Name's end. And I guess the reason it didn't crash when an external app was hooking / starting my program was because it just randomly shifted the heap? Fixing the above(and using strcpy_s) fixed the crash in my smaller subset of the program, but it still crashes later. Probably because of how I was mis-using vectors. Thanks for the help everyone. My stupidity. Weird that it only happened when run standalone though. Jared
Hmm, wow, ok I think you were right, but it was really subtle. :(
//String is read in from file, delimited. char string[32]; File.getline(string, 32, '"');
int Length = strlen(string); // <-- Does not include Null character! char* Name = new char[Length]; // <-- One char too small strcpy(Name, string); // <-- Corrupted 1 byte after Name's end.
Well... it's just an additional proof to what was said in the parallel thread :) http://article.gmane.org/gmane.comp.lib.boost.user/46803
participants (1)
-
Carl Zmola -
Igor R -
Jared Lee Richardson -
Marshall Clow -
Rune Lund Olesen