This message from Peter got eaten by the "too big" fairy the first time around -- Craig -- Thanks for your many insightful comments Perry.
What signal is it dying with?
The message I get is: Program exited with signal 11 (Segmentation Fault) However, from the attached stack frame you can see that erros occur inside stl code. In this particular case, it all has to do with simple std::string manipulations which require resizing the strings internal buffer. However, the error can also occur at entirely different locations. Also, I'm really puzzled why I only see 11 frames on the stack for this thread. What the code actually does is call a method of class ExceptionContext to write a message to a log file (the method behaves basically like sprintf). The following code reflects somehow what the code might have been doing at the time of the crash (error occurs at gEC.ReportDiagnostic()): #include "Exception.h" ExceptionContext gEC("mylogfile.log"); void foo() { std::string strDB = "Database"; std::string strTbl = "Table"; std::string strK1 = "12"; std::string strK2 = "A92bit12"; std::string strK3 = "901-12"; gEC.ReportDignostic("Table %s has key %s", (std::string("[") + strDB + "." + strTbl + "]").c_str(), (std::string("[") + strK1 + "/" + strK2 + "/" + strK3 + "]").c_str()); } Clearly, there are more frames on the stack, but I simply don't understand how to get the complete picture. But don't be fooled by this stack trace; a fact is that the error is everytime totally different and only occurs under HP-UX.
Linux has a great program called "valgrind" that can be used for debugging memory and threading issues. If you can get it to compile under Linux on x86 I'd **highly** recommend you run valgrind on your program.
I will most definitively try this one out. Pete
