Q&A
offsetやsizeを計算している部分など、..で書いている部分を開示してもらえますか? 関数で落ちているのではなく、その直前の領域確保で失敗していたりするかもしれないので。あと環境も。
C++にて、他プログラムが書き込み中のプログラムを読み取り専用で開き、whileループで繰り返しデータを読み取っているのですが、
たまにseekgでsegmentation faultが発生しプログラムが落ちてしまいます。
ネットで調べても、readやopenでのsegfaultの問題などは見つかりますが、seekgでのsegfaultは見つかりません。
原因は何でしょうか？また、どうすれば解決できますか？やはり他プログラムで同時に同ファイルへの書き込みを行っているのが問題なのでしょうか？
ちなみに直前でclear()を実行するようにしてもsegfaultになり、その場合はclear()実行時にsegfaultが発生します。
seekg(0, std::ios_base::beg)でファイルの先頭に移動しようとしても同じようにsegfaultが起きてしまいます。
よろしくお願いします。
C++
1std::ifstream ifs("./a", std::ios::in|std::ios::binary); 2while(1) { 3 int64_t offset = ..; 4 size_t size = ..; 5 char buf[size]; 6 //ifs.clear(); //←これを追記してもここで落ちる（ifs.seekg(0, std::ios_base::beg)でも落ちる） 7 ifs.seekg(offset, std::ios_base::beg); //←ここでたまに落ちる 8 if (ifs.read(buf, size)) { 9 .. 10 } else { 11 .. 12 } 13}
offset、sizeの部分なのですが、ファイルへの書き込みを行っている別のプログラムAからプロセス間通信でオフセット、サイズ、ファイルパスをテキストデータで受け取っています。それを別スレッドが受信、キューにプッシュして、Aがsyncを実行したらすべてポップしてその情報を元にデータを読み取りに行っています。
環境はCentOS7 64bit、メモリ16GBのIntelCPUです。
その情報が間違っている可能性は? 例えばsizeで0とか-1とかが得られていると簡単に暴走しそうですが。
一応ログに吐いて確認してますが、そういったことにはなってません。また、seekgだけではなくclearを呼び出したり、ファイルの先頭にシークしようとしてもsegfaultになるので、そういったことが原因ではないと思われます。
解決いたしました。majiponiさんの仰るとおり直前での領域確保に失敗していました。軽い考えで否定してしまい大変失礼しました。
回答4件
0
こんにちは。
回答依頼を頂いたので、来てみました。
内容的には、majiponiさんの推測に１票入れます。
メモリ破壊が起こっていて、それがifsを壊しているのではないか？という推測です。
不正メモリ・アクセスは運が良い時は例外が発生しますが、例外も起きずにしらっとメモリが壊れて不正動作する場合があります。
投稿2019/09/04 12:33
編集2019/09/04 12:52
総合スコア23272
回答ありがとうございます、念の為お聞きしたいのですが、他プログラムがファイルを書き換えている時などにかち合って読み込み専用でファイルを読み込もうとしても、基本的には例外やsegfaultは起きない、という認識でいいのでしょうか？つまり、やろうとしている事自体はできるが、単純にコードに不備があってうまくいってないという認識でよろしいでしょうか。
ifsの設定によってはエラーを例外で通知してきますが、segfaultは起きないと認識しています。
segfaultはC++の仕様にありませんからC++言語仕様内の動作でないことは間違いないです。
異常動作の原因は分かりませんが、経験上その殆どは自分のコードが原因です。
今回の場合は、範囲外のメモリへ書き込みしてないことをプログラムでチェックし、発生したらログを出力して例外で停止する等の対処を入れて、原因を追求するべきかと思います。
わかりました、その線でコードを読み直してみようと思います、ありがとうございます。
見れば見るほど謎が深まっていく・・・
ulimitコマンドにてスタックサイズを増やしたところsegfaultにならなくなりました。
どうやらスタックオーバーフロー？しているようです。
確認したところ、segfaultになったタイミングでsizeの値を確認してみると、デフォルトのスタックサイズだった8192KBをオーバーしていました。
どうやら直前のchar buf[size]でオーバーフローしており、gdbでのバックトレースでは次の行で止まったことになっていました。そして色々とコードを追記して試したのですが、char buf[size]の次の行は運悪くすべてifstream関係のコードを追記して実験していたため、ifstream関係の不具合だと思いこんでしまったようです。
0
ifs がスタック上に置かれて壊れているのなら、次のように
static を付けて、静的領域に置いてみたらどうなりますか？
C++
1#include <fstream> 2 3int main() 4{ 5 static std::ifstream ifs; 6 ifs.open("./a", std::ios::in | std::ios::binary); 7 while (1) { 8 // ... 9 } 10 ifs.close(); 11}
でも、スタックの中身が壊されるのなら、他の変数も壊されて、
あるいは、リターンアドレスが壊されて、関数の呼び出し元に戻れなくて
segmentation fault になっているのかもしれないので解決しないかも。
投稿2019/09/05 16:08
総合スコア8224
0
対象ファイルを別プロセス側で消してるんじゃないかなーと予想
読み取り側で開いてる(こうとしている)ときに消すのは環境次第ですが変な事になりそうで怖いですね
投稿2019/08/31 15:23
総合スコア15147
ファイルハンドル持ってるのに消せるもんなんですか・・・知らんかった
0
ベストアンサー
毎回ファイルハンドルを取り直すべきです。
cpp
1std::string_stream buf_stream; 2{ 3 std::ifstream ifs("./a"); 4 buf_stream << ifs.rdbuf(); 5} 6//buf streamをなんかやる
投稿2019/08/31 07:05
総合スコア5850
回答ありがとうございます。
質問に記載しておらず後出しとなって申し訳ないのですが、このプログラムはかなりの高頻度で読み込みを行います。そのためファイルのオープンははじめのみにしたのですが、ファイルのオープンクローズのコストはあまり考えなくていいのでしょうか？
また、毎回自動変数を使ってファイルをオープンするようにしましたが、今度はopen()の段階で同じようにまれにsegfaultを起こすようになってしまいました。
セグフォルってのがわからないんですよね、streamのエラーフラグが立つ、ならわかるんですが。
やっぱりメモリー破壊でしたか。なぜ私の解答がBAになったのか謎ですがまあお疲れさまでした
あなたの回答
tips
プレビュー
