My program crashes on fflush because of seg fault, ... but not always?

What possible reasons do you know for the situation, described in the title? Here's what my bt looks like:

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

and it gives me Program terminated with signal 11, Segmentation fault.

The wrapper around fflush() is simple, does nothing, just calls fflash and check for errors (开发者_如何学Goif the returned code is <0 ). So, I guess the seg fault is caused by fflash. Or it's possible to be somewhere else, because of the ?? at the top of the stack?

OS: RHEL5; gcc version 3.4.6 20060404 (Red Hat 3.4.6-3); debugged with gdb, with the original exe with max debug information in it.

I know about seg fault on no space on the disk, but this is not this case (as I have a watch-dog for the application, that restarts the program again and everything keeps working just fine).

Any ideas would be helpful. Thanks.

EDIT

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();
        }
    }
}

**NOTE** can't paste the whole code, it's a part of 10+ thousands of code. Also this is working for years on different applications, on real-time systems. Such crashes are very, very rare - kinda twice a year. So, I don't think this is problem in the code. I know that noone can help me with this kind of stuff, that's why I'm just asking for any ideas, why fflush may cause seg fault.

My guess: you have memory corruption somewhere and LogFile's "this" points to a memory area that you can't access.

Anyway, it's difficult to tell without code.

It appeared, that for some reasons, there was something strange with the permissions (not sure what exactly), but this had happened on a hour change, as different files are written for each hour. So, In some way, the file was created, but there were no permissions to write in it, or something like this. No one actually understood what, why and how that happened(because after the crash, the application was restarted and everything was just perfectly fine). So, flush crashed, because of no permissions to do that.

It's still mystery .. but solved xD

You don't provide the code for Flush(), but sounds strange to me that it is called twice. In fact it seems that it calls itself. This may cause some resource leak, depending on the implementation of Flush().

Run your program under valgrind, it will help you find the source of where your application's memory is corrupted.