Как DIR * может получить ошибку EBADF? - PullRequest
Новая
       16

Как DIR * может получить ошибку EBADF?

1 голос
/ 09 сентября 2010

У меня есть некоторый унаследованный код, который является частью класса для итерации, доступа к содержимому каталога и использует boost :: filesystem :: path. Код читается частично: 

struct directory_iterator_impl
{
private:
  void skip_dots(const path& p, const char* who)
  {
    static const std::string d(".");
    static const std::string dd("..");
    ASSERT( m_current_entry != 0 );
    while ( m_current_entry != 0 &&
        (m_current_entry->d_name == d ||
         m_current_entry->d_name == dd) ) {
      read(p, who);
    }
  }

  void handle_read_error(const path& p, const char* who)
  {
    ASSERT( errno != EBADF );
    ASSERT( errno != ENOENT );
    switch ( errno ) {
    case EOVERFLOW:
    case ESTALE:
      throw_error(who,
        error_code_impl::expected_unix_error(errno), p);
      break;
    default:
      base::utilities::abort_with_unknown_error();
      throw_error(who,
          error_code_impl::unexpected_unix_error(errno), p);
    }
  }

  void read(const path& p, const char* who)
  {
    errno = 0;
    m_current_entry = readdir(m_directory_stream);
    if ( errno != 0 ) {
      handle_read_error(p, who);
    }
  }

  void sync_current()
  {
    ASSERT( m_current_entry != 0 );
    m_current_name = m_current_entry->d_name;
  }

  void handle_open_error(const path& p, const char* who)
  {
    ASSERT( errno != EFAULT );
    switch ( errno ) {
    case EACCES: 
    case ELOOP:
    case ENAMETOOLONG:
    case ENOENT:
    case ENOTDIR:
    case EMFILE:
    case ENFILE:
    case ENOMEM:
    case ESTALE:
      throw_error(who,
          error_code_impl::expected_unix_error(errno), p);
      break;
    default:
      base::utilities::abort_with_unknown_error();
      throw_error(who,
          error_code_impl::unexpected_unix_error(errno), p);
    }
  }

public:
  directory_iterator_impl(const path& p, const char* w)
  {
    m_directory_stream = opendir(p.as_string().c_str());
    if (m_directory_stream == 0) {
      handle_open_error(p, w);
    }
    unsafe_increment(p, w);
  }

  ~directory_iterator_impl()
  {
    do {
      // coverity[double_free]
      if ( (m_directory_stream != 0) && 
        (closedir(m_directory_stream)==0) ) {
        return;
      }
    } while (errno == EINTR);
    ASSERT( errno != EBADF );
    base::utilities::abort_with_unknown_error();
  }

  void unsafe_increment(const path& p, const char* who)
  {
    read(p, who);
    if ( !no_entries() ) {
      skip_dots(p, who);
    }
    if ( !no_entries() ) {
      sync_current();
    }
  }

  void increment(const char* w)
  {
    ASSERT( !no_entries() );
    unsafe_increment("", w);
  }

  const std::string& dereference() const
  {
    return m_current_name;
  }

  bool no_entries() const
  {
    return m_current_entry == 0;
  }

private:
  DIR* m_directory_stream;
  struct dirent* m_current_entry;
  std::string m_current_name;
};

Проблема, с которой я столкнулся, это невоспроизводимый ASSERT, где errno == EBADF в handle_read_error (). Теперь, осматривая код, мне кажется, что в конструкторе m_directory_stream установлен, и больше ничего его не касается. Это не NULL, иначе конструктор вызвал бы handle_open_error (), и этот случай не возник бы. Следовательно, в момент конструирования m_directory_stream был действительным, и при открытии не возникло ошибок. Однако через некоторое время вызывается unsafe_increment (), возможно, вызов будет выполнен позже в конструкторе, и в этот момент объект DIR теперь называется EBADF, и мы получаем ошибку подтверждения в стеке.

Вот информация о машине, на которой был обнаружен сбой (обратите внимание, что приложение является однопоточным): 

Linux 2.6.9-67.ELsmp x86_64
OS:        RedHat Enterprise Linux 4.0 U6
CPU: 8 x 3000 MHz, Intel(R)Xeon(R) (2 socket, quad core, No HT)
Memory: 16 GB RAM, 33 GB Swap

Как файловый дескриптор может испортиться, пока мы его держим? Это известная проблема с интерфейсом dirent.h?

Пожалуйста, предложите, как сделать этот код лучше и избежать этой невоспроизводимой проблемы.

...