2013-10-09 61 views
0

我一直在使用STL和標準流庫將Solaris上的項目從compat模式(4)遷移到64位。SIGBUS當用std :: fstream對象破壞對象時

大多數情況下,我已經克服了很多問題。然而,我遇到了一些有關流和破壞的問題。

---- 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()和緩存的大小,認爲這是主要的問題,但這個問題似乎再度浮現。

有沒有其他人有過將C++代碼從compat遷移到std 64的類似經驗,並且可以提供關於如何修復SIGBUS周圍流的任何見解?

回答

1

如果有人想知道,Solaris上的標準C++流(RWTools 7),fstream等的析構函數會刪除您使用pubsetbuf設置的緩衝區。

這意味着做的東西,如:

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

不好。它實際上會刪除你在棧上聲明的內存。 我測試了一個簡單的應用程序,它使用標準IO Streams庫爲compat模式(4)和版本(5)使用setbuf/pubsetbuf設置緩衝區並設置緩衝區。

在compat模式下,存在內存泄漏,因爲char *未被刪除。在標準io流庫的情況下,沒有內存泄漏。

同樣,如果您刪除了指針,如果您在堆棧中聲明瞭char數組,則會得到一個帶有dbx訪問檢查和baf的duf。

非常意味着,我有很多代碼要更改:(