0

タイトルに記載されている状況について、どのような理由が考えられますか? これが私のbtの外観です：

#0 0x00a40089 in ?? ()
#1 0x09e3fac0 in ?? ()
#2 0x09e34f30 in ?? ()
#3 0xb7ef9074 in ?? ()
#4 0xb7ef9200 in ?? ()
#5 0xb7ef9028 in ?? ()
#6 LogFile::Flush の 0x081d45a0 ()
#7 LogFile::Flush の 0x081d45a0 ()
#8 LogFile::Close () の 0x081d46e0
#9 LogFile::OpenLogFile () の 0x081d4dbf
#10 LogFile::PerformPeriodicalFlush の 0x081d4eb9 ()
#11 LogFile::StoreRecord () の 0x081d4fca
#12 LogFile::StoreRecord () の 0x081d50c2

そしてそれは私に与えますProgram terminated with signal 11, Segmentation fault.

fflush() のラッパーは単純で、何もせず、呼び出しfflashてエラーをチェックするだけです (返されたコードが <0 の場合)。したがって、セグ フォールトの原因はfflash. または??、スタックの一番上にあるため、別の場所にいる可能性はありますか?

OS: RHEL5; gcc バージョン 3.4.6 20060404 (Red Hat 3.4.6-3); 最大デバッグ情報を含む元のexeを使用して、gdbでデバッグしました。

ディスクにスペースがない場合のセグフォルトについては知っていますが、これはそうではありません (アプリケーションのウォッチドッグがあり、プログラムを再起動すると、すべて正常に動作し続けます)。

どんなアイデアも役に立ちます。ありがとう。

編集 


void LogFile::PerformPeriodicalFlush( const utils::dt::TimeStamp& tsNow )
throw( LibCException )
{
 m_tsLastPeriodicalCheck = tsNow;

 struct stat LogFileStat;
 int nResult = stat( m_sCurrentFullFileName.c_str(), &LogFileStat );
 if ( 0 == nResult && S_ISREG( LogFileStat.st_mode ) )
 {
  //we successfuly stated the file, so it exists. We can safely perform 
  //a flush.
  try
  {
   Flush();
   return;
  }
  catch ( LibCException& )
  {
   OpenLogFile( tsNow );
   return;
  }
 }
 else
 {
  OpenLogFile( tsNow );
 }
}
void RotatingLogFile::Flush() throw( object::LibCException )
{
    if ( m_pFile != NULL )
    {
        if ( fflush( m_pFile ) (less_than) 0 )
        {
            throw object::LibCException();
        }
    }
}

**注** コード全体を貼り付けることはできません。1 万以上のコードの一部です。また、これはリアルタイムシステムのさまざまなアプリケーションで何年も機能しています。このようなクラッシュは非常にまれで、年に 2 回程度です。したがって、これはコードの問題ではないと思います。誰もこの種のことで私を助けることができないことを私は知っています。そのため、私はアイデアを求めているだけです.fflushがセグフォールトを引き起こす理由.

4

4 に答える 4

1

私の推測では、どこかでメモリが破損しており、LogFile の「this」はアクセスできないメモリ領域を指しています。

とにかく、コードなしで伝えるのは難しいです。

于 2010-11-23T11:34:42.907 に答える
1

何らかの理由で、アクセス許可に何か奇妙なことがあったように見えましたが (正確にはわかりません)、1 時間ごとに異なるファイルが書き込まれるため、これは 1 時間ごとに発生していました。それで、何らかの方法でファイルが作成されましたが、それに書き込む権限がありませんでした、またはこのようなものです。何が、なぜ、どのように起こったのか、実際には誰も理解していませんでした (クラッシュの後、アプリケーションが再起動され、すべてが完全に正常だったため)。flushそのため、それを行う権限がないため、クラッシュしました。

それはまだ謎です..しかし解決しました xD

于 2010-12-17T10:02:08.733 に答える
0

valgrindの下でプログラムを実行すると、アプリケーションのメモリが破損している原因を見つけるのに役立ちます。

于 2010-11-23T17:15:57.837 に答える
0

のコードを提供していませんがFlush()、2回呼び出されるのは奇妙に思えます。実際、それは自分自身を呼び出しているようです。の実装によっては、これによりリソース リークが発生する場合がありFlush()ます。

于 2010-11-23T12:44:08.967 に答える