закрыть текстовый файл, вызывающий ошибку сегментации и `glibc обнаружено` под linux в C ++ - PullRequest
3 голосов
/ 28 мая 2011

У меня есть класс журнала, этот класс содержит поток, определенный как: ofstream logfile и мьютекс, чтобы убедиться, что каждый раз только один поток записывает в файл (программа многопоточная). Класс определяется как:

#define LOG_NAME "log.txt"

using namespace std;

class Log
{
private:
    pthread_mutex_t mutex_write;
    ofstream logfile;

public:
    Log();
    ~Log();
    void Write (string txt);
};

Конструктор:

Log::Log()
{
    pthread_mutex_init (&mutex_write,NULL);
    pthread_mutex_lock (&mutex_write);
    logfile.open(LOG_NAME, ios::out | ios::trunc);
    logfile << "Created log file named " << LOG_NAME << endl;
    pthread_mutex_unlock (&mutex_write);
}

Деструктор:

Log::~Log()
{
    logfile << "Closing log file" << endl;
    pthread_mutex_lock (&mutex_write);
    logfile.close();
    pthread_mutex_unlock (&mutex_write);
    pthread_mutex_destroy (&mutex_write);
}

и

void Log::Write (string txt)
{
    pthread_mutex_lock (&mutex_write);
    logfile << txt << endl;
    pthread_mutex_unlock (&mutex_write);
}

В некоторых случаях, когда вызывается деструктор, он не может выполнить строку logfile.close();, потому что он говорит, что получил ошибку сегментации, или выводит сообщение:

*** glibc detected *** corrupted double-linked list: 0x0000000000513eb0 ***
Abort

Это не происходит постоянно, кажется, что это происходит случайно, примерно в 10% случаев. Программа многопоточная (под linux).

Edit: пример использования: (где log - указатель на объект класса Log)

stringstream str;
str.str("");
str << "Ant " << i << " was created at place: (" << x << "," << y << ")";
log->Write (str.str());

или, если строка содержит только известный текст

log->Write ("Created board entity");

Ответы [ 2 ]

3 голосов
/ 28 мая 2011

Не уверен на 100%, но это может быть связано с повреждением памяти в любом месте кода.Чтобы глубже разобраться в этой проблеме, попробуйте запустить вашу программу под Valgrind или исследуя дамп ядра (убедитесь, что он включен - AFAIR ulimit -c unlimited).

0 голосов
/ 29 мая 2011

Проблема заключалась в том, что у нас есть проблема с проверкой завершения всех потоков.Мы это починили, и теперь все работает нормально.Возможно, проблема возникла из-за того, что другие потоки пытались получить доступ к закрытому файлу, а иногда пытались получить доступ к уничтоженному объекту.

...