我一直在使用 STL 和标准流库将 Solaris 上的一个项目从兼容模式 (4) 迁移到 64 位。
在大多数情况下，我已经设法克服了很多问题。然而，我遇到了一些关于流和破坏的问题。
---- 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
我在使用 setbuf() 的 std 流和缓冲区大小方面遇到了一些奇怪的问题，并认为这是主要问题，但问题似乎重新浮出水面。
有没有其他人有将 C++ 代码从 compat 迁移到 std 64 的类似经验，并且可以提供有关如何修复 SIGBUS 周围流的任何见解？
最佳答案
如果有人想知道，似乎 Solaris (RWTools 7) 上的标准 C++ 流、fstream 等的析构函数将删除您使用 pubsetbuf 设置的缓冲区。
这意味着做这样的事情:
char buf[1024];
ofstream out;
out.rdbuf()->pubsetbuf(buf, 1024);
不好。它实际上会删除你在堆栈上声明的内存。 我已经测试了一个简单的应用程序，它使用 setbuf/pubsetbuf 为 compat 模式 (4) 和版本 (5) 使用标准 IO Streams 库通知 char* 缓冲区并设置缓冲区。
在兼容模式下，存在内存泄漏，因为 char* 没有被删除。在标准 io 流库的情况下，没有内存泄漏。
同样，如果您删除指针，您将获得一个带有 dbx 访问检查的 duf 和 baf(如果您在堆栈上声明了一个 char 数组)。
差不多意味着，我有很多代码要更改:(
关于c++ - 使用 std::fstream 对象销毁对象时出现 SIGBUS，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/19263041/