I have been working for a couple of days on a problem with my application running on an embedded Arm Linux platform. Unfortunately the platform precludes me from using any of the usual useful tools for finding the exact issue. When the same code is run on the PC running Linux, I get no such error.
In the sample below, I can reliably reproduce the problem by uncommenting the string, list or vector lines. Leaving them commented results in the application running to completion. I expect that something is corrupting the heap, but I cannot see what? The program will run for a few seconds before giving a segmentation fault.
The code is compiled using a arm-linux cross compiler:
arm-linux-g++ -Wall -otest fault.cpp -ldl -lpthread
arm-linux-strip test
Any ideas greatly appreciated.
#include <stdio.h>
#include <vector>
#include <list>
#include <string>
using namespace std;
////////////////////////////////////开发者_C百科/////////////////////////////////////////
class TestSeg
{
static pthread_mutex_t _logLock;
public:
TestSeg()
{
}
~TestSeg()
{
}
static void* TestThread( void *arg )
{
int i = 0;
while ( i++ < 10000 )
{
printf( "%d\n", i );
WriteBad( "Function" );
}
pthread_exit( NULL );
}
static void WriteBad( const char* sFunction )
{
pthread_mutex_lock( &_logLock );
printf( "%s\n", sFunction );
//string sKiller; // <----------------------------------Bad
//list<char> killer; // <----------------------------------Bad
//vector<char> killer; // <----------------------------------Bad
pthread_mutex_unlock( &_logLock );
return;
}
void RunTest()
{
int threads = 100;
pthread_t _rx_thread[threads];
for ( int i = 0 ; i < threads ; i++ )
{
pthread_create( &_rx_thread[i], NULL, TestThread, NULL );
}
for ( int i = 0 ; i < threads ; i++ )
{
pthread_join( _rx_thread[i], NULL );
}
}
};
pthread_mutex_t TestSeg::_logLock = PTHREAD_MUTEX_INITIALIZER;
int main( int argc, char *argv[] )
{
TestSeg seg;
seg.RunTest();
pthread_exit( NULL );
}
Maybe you're using a single-threaded version of the standard library, including the new
and delete
operators?
Those objects are being constructed within the guards of your mutex, but are destructed outside those bounds, so the destructors might be stepping on each other. One quick test would be to put scoping brackets {}
around the declaration of killer
.
See the gcc documentation for more.
You don't say what PTHREAD_MUTEX_INITIALIZER is, but are you calling pthread_mutex_init on TestSeg::_logLock? It's possible if you're using an unintialized mutex that stack and/or heap operations from those constructors are interfering with your mutex.
Have you tried -Os and -O0 ? whats your arm-linux-g++ --version ?
When developing and debugging segmentation faults for an embedded Arm Linux platform, I often add code to print a stack backtrace from the SIGSEGV
signal handler. Perhaps the implementation I describe here can be of some use to you.
I build with the following gcc/g++ options (among others):
arm-linux-g++ -Wall -pipe -rdynamic -fno-omit-frame-pointer test.cpp -o test
精彩评论