Hi, I'm getting a list of the file in a directory like that: fs::directory_iterator end ; for( fs::directory_iterator iter(myfilepath) ; iter != end ; ++iter ) {...} And at some point in this for loop, the ++operator never return, see callstack (single-thread build). I found a related thread here: http://marc.info/?l=boost-users&m=118835374908173&w=2 I compiled boost in threaded and non-threaded mode and still have the same pb in both mode... This bug reproduce with iphone os21 and os3.0, boost 1.38.0 (multi/single thread). Anybody? Thanks, Frank #0 0x31d41270 in swtch_pri #1 0x31dd19cc in sched_yield #2 0x000ac1d4 in boost::detail::yield at yield_k.hpp:110 #3 0x000adb54 in scoped_lock [inlined] at detail:45 #4 0x000adb54 in boost::detail::spinlock::lock at detail:32 #5 0x000adb54 in atomic_exchange_and_add [inlined] at detail:61 #6 0x000adb54 in boost::detail::sp_counted_base::release at detail:100 #7 0x000adb54 in boost::shared_ptr<boost::filesystem::detail::dir_itr_imp<boost::filesystem::basic_path<std::string, boost::filesystem::path_traits> > >::reset at detail:216 #8 0x000adb54 in boost::filesystem::basic_directory_iterator<boost::filesystem::basic_path<std::string, boost::filesystem::path_traits> >::increment #9 0x0009cc44 in boost::iterator_core_access::increment<boost::filesystem::basic_directory_iterator<boost::filesystem::basic_path<std::string, boost::filesystem::path_traits> > > at iterator_facade.hpp:522 #10 0x0009cc64 in boost::iterator_facade<boost::filesystem::basic_directory_iterator<boost::filesystem::basic_path<std::string, boost::filesystem::path_traits> >, boost::filesystem::basic_directory_entry<boost::filesystem::basic_path<std::string, boost::filesystem::path_traits> >, boost::single_pass_traversal_tag, boost::filesystem::basic_directory_entry<boost::filesystem::basic_path<std::string, boost::filesystem::path_traits> >&, int>::operator++ at iterator_facade.hpp:664
"gtsml owevwr" (Frank):
Hi,
I'm getting a list of the file in a directory like that:
fs::directory_iterator end ; for( fs::directory_iterator iter(myfilepath) ; iter != end ; ++iter ) {...}
And at some point in this for loop, the ++operator never return, see callstack (single-thread build).
...
#0 0x31d41270 in swtch_pri #1 0x31dd19cc in sched_yield #2 0x000ac1d4 in boost::detail::yield at yield_k.hpp:110 #3 0x000adb54 in scoped_lock [inlined] at detail:45 #4 0x000adb54 in boost::detail::spinlock::lock at detail:32 #5 0x000adb54 in atomic_exchange_and_add [inlined] at detail:61 #6 0x000adb54 in boost::detail::sp_counted_base::release at detail:100
Things to try: - does it still hang if you remove the ... from the loop and just use the directory iterator to walk through the directory without doing anything? - does a simple use of shared_ptr hang? int main() { shared_ptr<int> p( new int ); p.reset(); // here } - #define BOOST_SP_USE_PTHREADS; - #define BOOST_SP_DISABLE_THREADS.
Yes, you can call me Frank :-)
- does it still hang if you remove the ... from the loop and just use the directory iterator to walk through the directory without doing anything?
yes it does till hang.
- does a simple use of shared_ptr hang?
I'm using shared_ptr elsewhere and had no pb with them so far Thanks, Frank
- does it still hang if you remove the ... from the loop and just use the directory iterator to walk through the directory without doing anything?
yes it does till hang.
- does a simple use of shared_ptr hang?
I'm using shared_ptr elsewhere and had no pb with them so far
Hmm. Does it still hang if you don't link to libboost_filesystem, but manually add the sources from libs/filesystem/src to your program?
Frank:
Hmm. Does it still hang if you don't link to libboost_filesystem, but manually add the sources from libs/filesystem/src to your program?
No it doesn't hang anymore... I'm now curious now about what you have in mind. Some difference in compiler options?
Most likely, although I have no idea what's causing it.
Well, that's still far better than not knowing anything at all, so thanks a lot for your help! Maybe something related with threading... I saw somewhere BOOST_SP_DISABLE_THREADS Do you think it might help? If yes, is that something to bet set both for boost build AND project build Frank
Well, that's still far better than not knowing anything at all, so thanks a lot for your help!
Maybe something related with threading...
It is possible that BOOST_HAS_THREADS is being set for the library build and not for the project build, or vice versa. The thread autodetection logic is pretty complicated for gcc; maybe the fact that you're cross-compiling is confusing it.
I saw somewhere BOOST_SP_DISABLE_THREADS
Do you think it might help? If yes, is that something to bet set both for boost build AND project build
Yes, it should be set for both. This should take care of the shared_ptr-related issues. In principle, it might be better if you can solve the BOOST_HAS_THREADS mismatch since it has the potential to cause you more trouble in other libraries. If you don't need threads, you may try rebuilding (both Boost and the project) with BOOST_DISABLE_THREADS defined.
participants (2)
-
gtsml owevwr -
Peter Dimov