[Boost-users] Directory_Iterator -> hangs app

[RYAN ROSARIO]

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.

- Upon executing the app in the explorer (not MSVC), I get a Runtime Error: The app has requested runtime to terminate in an unusual way.

- I ran Spy++ and see to get quite a few WM_GETDLGCODE messages. I have read that this can signify a problem.

 

Has anybody else had a problem like this with the directory_iterator? Any help or suggestion is greatly appreciated as I have been stuck for quite a while. :-(

 

FYI: MSVC .NET 2003, running as Multi-Threaded Debug DLL using the multi-threaded version of the Boost::Filesystem library.

 

Thanks Again,

Ryan

---

Do you Yahoo!?
Win 1 of 4,000 free domain names from Yahoo! Enter now.

[Jeff Garland]

On Wed, 8 Sep 2004 00:37:22 -0700 (PDT), RYAN ROSARIO 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. -
> Upon executing the app in the explorer (not MSVC), I get a Runtime
> Error: The app has requested runtime to terminate in an unusual way.
> - I ran Spy++ and see to get quite a few WM_GETDLGCODE messages. I
> have read that this can signify a problem.
>
> Has anybody else had a problem like this with the
> directory_iterator? Any help or suggestion is greatly appreciated as
> I have been stuck for quite a while. :-(

Given the lack of response it seems like the answer is no. But maybe no one
has tried to do what you are doing. Have you tried tracing the app in the
debugger? Perhaps building and running the filesystem regression tests on
this machine -- just to be sure there isn't odd configuration issue with your
platorm? Just throwing out some ideas...

HTH,

Jeff

_______________________________________________
Boost-users mailing list
Boost...@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users

[Peter Dimov]

>> 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?

[goochrules!]

> - 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
-- gooch...@gmail.com

[goochrules!]

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

[goochrules!]

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

[RYAN ROSARIO]

That sounds like a good idea. I will post how it goes.

 

Thanks,

Ryan


Peter Dimov <pdi...@mmltd.net> wrote:

[RYAN ROSARIO]

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 <pdi...@mmltd.net> wrote:

---

Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!

[RYAN ROSARIO]

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! <gooch...@gmail.com> 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 st! arting 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
-- gooch...@gmail.com
_______________________________________________
Boost-users mailing list
Boost...@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users

[RYAN ROSARIO]

(slaps forehead) SOLVED...

 

The directory_iterator was causing the hang because I attempted to create an object of type path with a parameter that is causing problems. My path object scanPath displays "" as the path when that is not what was intended.

 

Thus I will start a new thread that addresses that issue. That should be much easier to solve I hope. :-)

 

Thank you all for your help with this aggravating problem. I really appreciate it.

 

Thanks,

Ryan

RYAN ROSARIO <uclam...@yahoo.com> wrote:

---

Do you Yahoo!?
Win 1 of 4,000 free domain names from Yahoo! Enter now._______________________________________________

Boost-users mailing list
Boost...@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users

---

Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!

[RYAN ROSARIO]

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_exception<boost::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! <gooch...@gmail.com> 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.


-- Matt! hew Peltzer
-- gooch...@gmail.com

_______________________________________________
Boost-users mailing list
Boost...@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users

---

Do you Yahoo!?