0

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のストリーム周辺を修正する方法について洞察を提供できますか?

4

1 に答える 1

1

ご参考までに、Solaris (RWTools 7) の標​​準 C++ ストリーム、fstream のデストラクタなどは、pubsetbuf で設定したバッファを削除するようです。

つまり、次のようなことを行います。

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

よくない。スタックで宣言されたメモリを実際に削除します。char* バッファーを通知し、setbuf/pubsetbuf を使用して互換モード (4) とバージョン (5) の標準 IO ストリーム ライブラリを使用してバッファーを設定する単純なアプリケーションをテストしました。

互換モードでは、char* が削除されないため、メモリ リークが発生します。標準の io ストリーム ライブラリの場合、メモリ リークはありません。

同様に、ポインターを削除すると、スタック上で宣言された char 配列がある場合は、dbx アクセス チェックと baf で duf が取得されます。

ほとんどの場合、変更するコードがたくさんあります:(

于 2013-10-09T10:51:13.813 に答える