SIGBUS при уничтожении объекта с помощью std :: fstream объектов

Я переносил проект в Solaris из режима Compat (4) в 64-битный режим с STL и стандартной библиотекой потоков.

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

---- called from signal handler with signal 10 (SIGBUS) ------
[7] realfree(0x108be78e8, 0x5554d45f54d7d4d7, 0x1da530, 0x5554d45f54d7d4d4, 0xffffffff7ae3e000, 0x108be78d8), at 0xffffffff7ac63b2c
[8] cleanfree(0x0, 0x1d9bc4, 0xffffffff7ae4ead8, 0xffffffff7accfcec, 0xffffffff7ae3e000, 0xffffffff7ae4ebd8), at 0xffffffff7ac64498
[9] _malloc_unlocked(0x20, 0x0, 0x0, 0xffffffff7ae3e000, 0x0, 0x0), at 0xffffffff7ac634f4
[10] malloc(0x20, 0x23e0, 0x1dac88, 0xffffffff7ac633d8, 0xffffffff7ae3e000, 0x2000), at 0xffffffff7ac633c8
[11] operator new(0x20, 0x0, 0x1, 0x1068d4, 0x105584e70, 0xffffffff7b20f028), at 0xffffffff7b108770
[12] std::basic_filebuf<char,std::char_traits<char> >::close(0x108bf7a60, 0x108bfbd30, 0xffffffffffffffff, 0xffffffff7ae4c060, 0xffffffffffffffe0, 0x108bf7a60), at 0xffffffff7b37657c
[13] std::basic_filebuf<char,std::char_traits<char> >::~basic_filebuf(0x108bf7a60, 0x108bfbe38, 0x0, 0x0, 0x0, 0x0), at 0xffffffff7b3764c4
[14] std::basic_ifstream<char,std::char_traits<char> >::~basic_ifstream(0x108bf7a48, 0x1c8, 0x24, 0x1021a66d0, 0x1af984, 0x0), at 0xffffffff7b3f30d4

Я натолкнулся на некоторые странные проблемы, связанные с использованием потоков std с помощью setbuf () и размера буфера, и подумал, что это главная проблема, но проблема, похоже, вновь возникла.

Кто-нибудь еще имел подобный опыт по переносу кода C ++ с compat на std 64 и мог бы предложить какое-либо понимание того, как исправить SIGBUS вокруг потоков?

0

Решение

Если кому-то интересно, кажется, что стандартные потоки C ++ в Solaris (RWTools 7), деструктор для fstream и т. Д., Удалят буфер, который вы установили с помощью pubsetbuf.

Что означает делать такие вещи, как:

char buf[1024];
ofstream out;
out.rdbuf()->pubsetbuf(buf, 1024);

не хорошо. Это фактически удалит вашу память, объявленную в стеке.
Я протестировал простое приложение, которое сообщает о буфере char * и устанавливает буфер, используя setbuf / pubsetbuf для режимов Compat (4) и Version (5) со стандартной библиотекой IO Streams.

В режиме Compat происходят утечки памяти, так как символ * не удаляется. В случае стандартной библиотеки io stream утечки памяти отсутствуют.

Точно так же, если вы удалите указатель, вы получите duf с проверкой доступа dbx и baf, если у вас есть массив char, объявленный в стеке.

Значит, у меня много кода для изменения 🙁

1

Другие решения

Других решений пока нет …

По вопросам рекламы [email protected]