Suggestions on compiling STLPort?

Question

About two weeks ago, I posted a problem using the STLPort4 library where a segmentation fault happens down in STLPatomic_exchange. I am still encountering the problem intermittently.
I would like to compile the latest stable release from www.stlport.com so that I better track down the problem.
Are there any special compile commands needed to get the STLPort to compile under C++ 5.4?
The compiler command for including stlport "-library=stlport4" appears to be special for the library, why is that?

Answer 1

The following code has been shown to reproduce my SEGV issue in stlport's STLPatomic_exchange. Before compiling and running:
1. This problem could take one to many minutes to occur
2. Make sure that your platform has nobody else using it because the app will drive your CPU to 100%
3. Please don't make fun of my Makefile
Good luck and I hope you have the same "success" that I had.
### Makefile Start
PLATFORM :sh= uname -p | sed s/i386/x86/
OSVARIANT=$(PLATFORM)-SunOS
#### Compiler and tool definitions shared by all build targets #####
CCC=CC
BASICOPTS=
CCFLAGS= -g -mt -library=stlport4 -staticlib=stlport4 -misalign
CCADMIN=CCadmin
## Target: GCNServer
CPPFLAGS = -I/usr/include -I/usr/include/sys
OBJS =  stlproblem.o
SYSLIBS = -lpthread -lm -lsocket -lnsl -lposix4
LDLIBS =  $(SYSLIBS)
# Link or archive
stlproblem:  $(OBJS)
     $(LINK.cc) -o stlproblem $(OBJS) $(LDLIBS)
# Compile source files into .o filess
stlproblem.o: stlproblem.cpp
     $(COMPILE.cc) -o $@ stlproblem.cpp
#### Clean target deletes all generated files ####
clean::
     $(RM) ./stlproblem ./stlproblem.o
     $(CCADMIN) -clean
# Create the target directory (if needed)
obj:
# Enable dependency checking
.KEEP_STATE:
### Makefile end
// stlproblem.cpp code start
This source file contains a system of n threaded objects that use a common object
table in order to access the other threaded objects.  As the system runs, x
number of messages are passed randomly between these threaded objects.  In order
to access the object pointer for a message recipient, the common
ObjectTable::GetObjectPointer method is used.  In this call, STL will SEGV in
the _STLP_atomic_exchange.  This problem occurs on our SUN 280R servers (1 CPU)
in Solaris 9.  Our compiler version is CC: Forte Developer 7 C++ 5.4 2002/03/09.
#include "stdlib.h"
#include "stdio.h"
#include "math.h"
#include "pthread.h"
#include "semaphore.h"
#include <iostream>
#include <list>
#include <string>
#include <map>
#define THREAD_COUNT   100
#define MESSAGE_COUNT  1000
using namespace std;
// shared table to hold the objects
class ObjectTable
public:
    ObjectTable();
    ~ObjectTable();   
    void* GetObjectPointer(std::string Name);   
    std::map<std::string, void*> m_table;
ObjectTable::ObjectTable(void)
ObjectTable::~ObjectTable(void)
void* ObjectTable::GetObjectPointer(std::string Name)
    std::string object_name;
    std::string instance;
    std::map<std::string, void*>::iterator iter;
    void *rtnval = NULL;
    // this is where STLPort is expected to crash, so play with std::string operations
    // iterate to slow this method down and get more than one thread in here
    iter = m_table.begin();
    for(int i=0; i<m_table.size(); i++)
        object_name = (*iter).first;
        // the following line appears to be the main culprit even though it does nothing useful
        instance = object_name.substr(0, object_name.find("e")+1);
        if(object_name == Name)
            rtnval = m_table[object_name];
        iter++;
    return rtnval;
// global declaration of the table that all objects can reference
ObjectTable *gObjectTable = NULL;
// message payload class
class Message
public:   
    Message(std::string Text);
    ~Message(void);
    std::string m_messageText;
Message::Message(std::string Text)
    m_messageText = Text;
Message::~Message(void)
// the main living object class
class LivingObject
public:
    LivingObject(std::string ObjectName);
    ~LivingObject(void);
    void HandleMessages(void);
    void QueueMessage(Message* pMsg);
    pthread_mutex_t m_criticalSectionMutex;
    pthread_cond_t m_messageEventCondition;
    pthread_mutex_t m_messageEventMutex;   
    std::list<Message*> m_messageList;
    std::string m_myName;
LivingObject::LivingObject(std::string ObjectName)
    pthread_mutex_init(&m_criticalSectionMutex, NULL);      
    pthread_cond_init(&m_messageEventCondition, NULL);
    pthread_mutex_init(&m_messageEventMutex, NULL);
    m_messageList.clear();
    m_myName = ObjectName;
LivingObject::~LivingObject(void)
void LivingObject::HandleMessages(void)
    char buf[16];   
    unsigned int seed = 4925;   
    while(1)
        pthread_cond_wait(&m_messageEventCondition, &m_messageEventMutex);
        while(m_messageList.size() > 0)
            pthread_mutex_lock(&m_criticalSectionMutex);           
            Message *p_msg = (Message*) m_messageList.front();
            m_messageList.pop_front();
            pthread_mutex_unlock(&m_criticalSectionMutex);  
            LivingObject *p_object;           
            do
                // pick a random object to send the message to (can't be ourselves)               
                seed = rand_r(&seed);           
                int object_number = (int) floor(((double)seed/(double)RAND_MAX) * THREAD_COUNT);
                sprintf(buf, "Instance%d", object_number);
                std::string object_name = buf;
                // Turn the following line on to show the message activity between threads
                // When the cout is active, it may delay the SEGV issue.
                //cout << m_myName << " is sending " << p_msg->m_messageText << " to " << object_name << endl;
                // the SEGV crash should occur in this call - gObjectTable is the global pointer
                p_object = (LivingObject*) gObjectTable->GetObjectPointer(object_name);
                if(p_object != this && p_object != NULL)               
                    p_object->QueueMessage(p_msg);
            } while(p_object == this);
void LivingObject::QueueMessage(Message *pMsg)
    // protect the message list since it is read-write
    pthread_mutex_lock(&m_criticalSectionMutex);   
    m_messageList.push_back(pMsg);
    pthread_cond_signal(&m_messageEventCondition);
    pthread_mutex_unlock(&m_criticalSectionMutex);   
// thread entry point for the LivingObject class
extern "C" void* LivingObjectThread(void* param)
    std::string object_name = (char*) param;
    LivingObject *alive_object = new LivingObject(object_name);    
    cout << object_name << " is alive!" << endl;
    gObjectTable->m_table[object_name] = (void*) alive_object;
    // HandleMessages() will block indefinitely...
    alive_object->HandleMessages();
    // ...and we never get here
    return 0;
int main(int argc, char* argv[])
    char *name_buf;
    gObjectTable = new ObjectTable();
    // create lots of threads
    pthread_t tid;   
    for(int i=0; i<THREAD_COUNT; i++)
        name_buf = new char[16];
        sprintf(name_buf, "Instance%d", i);       
        pthread_create(&tid, NULL, LivingObjectThread, (void*)name_buf);
    // Get the ball rolling - effectively these "messages" will bounce around
    // through all of the object threads just created.  the idea is that
    // eventually two threads will enter the ObjectTable::GetObjectPointer
    // at the same time and cause the STLPort crash in _STLP_atomic_exchange().   
    LivingObject *instance0 = NULL;
    do
        instance0 = (LivingObject*) gObjectTable->GetObjectPointer((std::string)"Instance0");       
    } while(instance0 == NULL);   
    // create lots of messages
    char message_buf[64];   
    for(int i=0; i<MESSAGE_COUNT; i++)
        sprintf(message_buf, "Message Number %d", i+1);
        Message *msg = new Message(message_buf);
        instance0->QueueMessage(msg);
    // block the app from exiting (CTRL-C is the only way out)
    sem_t never_exit_event;   
    sem_init(&never_exit_event, 0, 0);   
    sem_wait(&never_exit_event);
    return 0;
// stlproblem.cpp code end