boost directory_iterator接收SIGABRT

时间:2012-07-08 18:46:04

标签: boost sigabrt boost-iterators

我正在使用boost / filesystem来迭代目录并将它们添加到MacOSX + XCode3上的Zip文件中。

我的原始逻辑看起来像这样

path targetDir( "Volumes/data/some_directory" );
directory_iterator it( targetDir ), eod;

std::string filename;
std::string strPath;

// I tried both of two types of making loop
for( ; it != eod ; ++it )
{
    path const& p = *it;
    filename = p.filename();
    if( is_directory(p) )
    {
        strPath = strDirectory + filename + string("/");

        // Initially I wanted this logic to be recursive(these code block is a part of PackDirectory)
        PackDirectory( archive, strPath, lpszPackFile );
    }
    else if( is_regular_file(p) )
    {
        strPath = strDirectory + filename;
        // add this file to specified Zip file here
    }

}

then function returns here.

在返回此函数后出现问题,特别是在调用directory_iterator的析构函数时,我想。它似乎删除了无效指针,并接收SIGABRT。 程序有时会像下面那样崩溃,有时它在我跳过一步时会冻结,XCode说“踩到”但是没有任何进展随着调用堆栈的消失。 重点是,即使我在循环中没有做任何事情,问题仍然存在,这意味着只需创建变量并返回函数。

有关更多信息,当程序崩溃时,调用堆栈会如下所示。

#0  0x93f86c5a in __kill
#1  0x93f86c4c in kill$UNIX2003
#2  0x940195a5 in raise
#3  0x9402f6e4 in abort
#4  0x93f2c575 in free
#5  0x00134aea in dir_itr_close [inlined] at v2_operations.cpp:1300
#6  0x00134aea in ~dir_itr_imp [inlined] at operations.hpp:877
#7  0x00134aea in     checked_delete<boost::filesystem2::detail::dir_itr_imp<boost::filesystem2::basic_path<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, boost::filesystem2::path_traits> > > [inlined] at checked_delete.hpp:34
#8  0x00134aea in boost::detail::sp_counted_impl_p<boost::filesystem2::detail::dir_itr_imp<boost::filesystem2::basic_path<std::string, boost::filesystem2::path_traits> > >::dispose at v2_operations.cpp:78
#9  0x00136583 in boost::detail::sp_counted_base::weak_release at sp_counted_base_pt.hpp:97

它进入~dir_itr_imp,因此它在传递类型检查后似乎达到了正确的析构函数。

我是否对directory_iterator做错了什么? 如果有人遇到这个问题,请告诉我。

1 个答案:

答案 0 :(得分:0)

free中引发的信号不一定指向调用函数中的缺陷。对free的早期破坏调用可能已损坏malloc的空闲内存列表,从而导致错误。

尝试在valgrind中运行程序,该程序更强大,并且在使用损坏的内存分配/释放时会立即死亡。如果valgrind不是一个选项,您也可以尝试在单元测试中测试您的代码,而与程序的其余部分无关。