...

I am still stuck with this issue of a directory_iterator causing a hang when it is declared. This is one of the most bizarre things I have ever encountered.

Some more clues have arisen since my last post:

- Upon hanging, I now get a message box: Unhandled exception at 0x77e73887 in PICtool-w32.exe: Microsoft C++ exception: boost::filesystem::filesystem_error @ 0x0012f170. I seem to be getting *somewhere* although the message seems very vague.

Have you tried adding a try/catch(filesystem_error const & e) block around the offending operations and printing e.what() to see what the error is?

Upon running the program, I now get a message: boost::filesystem::directory_iterator constructor:"": The operation completed successfully. Does that mean that the problem could be with the configuration of the library? Ryan Peter Dimov wrote:

...

I am still stuck with this issue of a directory_iterator causing a hang when it is declared. This is one of the most bizarre things I have ever encountered.

Some more clues have arisen since my last post:

- Upon hanging, I now get a message box: Unhandled exception at 0x77e73887 in PICtool-w32.exe: Microsoft C++ exception: boost::filesystem::filesystem_error @ 0x0012f170. I seem to be getting *somewhere* although the message seems very vague.

Have you tried adding a try/catch(filesystem_error const & e) block around the offending operations and printing e.what() to see what the error is? _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users --------------------------------- Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers!

Thanks. I have found that the debugger is usually an excellent resource for strange issues, but for this problem, the plot thickens... The stack trace indicates that the path object destructor ~path() is calling free(void * pBlock blah...) in free.c and that is when the break occurs due to the filesystem::error. What does that mean? It seems like there is nothing I can do if it is being caused by the destructor and/or Windows heap functions, but maybe I am not reading the output correctly. goochrules! wrote:

- Upon hanging, I now get a message box: Unhandled exception at 0x77e73887 in PICtool-w32.exe: Microsoft C++ exception: boost::filesystem::filesystem_error @ 0x0012f170.

You can really help your self by using the debugger on this one. In general, you want to break on when any exceptions of this type are not handled, and then use the stack trace to see all the various functions and bits of data that lead up to this problem. Specifically (for VS.Net 2003) you want to click "Exceptions..." in the Debug menu. Then for "C++ Exceptions" make sure in the group "If the exception is not handled:" that "Break into hte debugger" is selected. You may want to also select this option for "When the exception is thrown", but be aware that this may give you more hits than then one you're looking for. Then it is a matter of starting the debugger (F5 I believe, or Debug->Start) and using the watch and call stack windows to figure out what is causing the exception. Hope this helps. -- Matthew Peltzer -- goochrules@gmail.com _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users --------------------------------- Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers!

I ran the debugger and looked more closely at the stack trace, but I still don't know what I can do about the error. Could it be a bug that affects my type of system or something? It still points to the free function (possible corrupted memory block) which appears to be called by the boost::throw_exception function called by boost::filesystem::detail::dir_itr_init() + 0x27a. <-- What is that? That may be more the source of the problem. This appears to be called by the directory_iterator constructor. Below is the stack trace from the time a button is clicked (when the problem arises). kernel32.dll!77e73887() kernel32.dll!77e73887() ntdll.dll!77f59037()

PICtool-w32.exe!free(void * pBlock=0xe06d7363) Line 103 C

PICtool-w32.exe!_CxxThrowException(void * pExceptionObject=0x0012f1fc, const _s__ThrowInfo * pThrowInfo=0x00434a8c) + 0x34 C++ PICtool-w32.exe!boost::throw_exceptionboost::filesystem::filesystem_error() + 0x20 C++ PICtool-w32.exe!boost::filesystem::detail::dir_itr_init() + 0x27a C++ PICtool-w32.exe!PICtoolCompileWnd::OnBnClickedStart() Line 283 C++ Many Thanks Again, Ryan goochrules! wrote:

The stack trace indicates that the path object destructor ~path() is calling free(void * pBlock blah...) in free.c and that is when the break occurs due to the filesystem::error.

What does that mean? It seems like there is nothing I can do if it is being caused by the destructor and/or Windows heap functions, but maybe I am not reading the output correctly.

It sounds to me like there's some sort of memory corruption, possibly a block is being twice freed, or a non-block is being freed. Either way, I can't really tell what's going on w/o more information, such as a self-contained example demonstrating this problem. In the mean-time, using the stack trace, figure out which call in your code leads to the exception and comment it out. Then, see if the exception shows up elsewhere. -- Matthew Peltzer -- goochrules@gmail.com _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users --------------------------------- Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers!