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
On Thu, Jun 17, 2004 at 03:05:01PM +1200, Craig Box wrote:
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()); }
I've encountered problems before when doing things like string + "c string" + string You could try changing that to string + string("c string") + string just in case it is a casting/pointer arithmetic problem. C++ string handling seems to be a pet hate of many of the wlug members who are programmers... Another alternative is that the bug is somewhere else entirely, but it happens to modify memory at this particular point, so everything runs fine until it uses this bit of memory. John McPherson
John, beware that my sample was only indicative of the problem associated with the stack trace I submitted along with it. A fact is that the "crash-point" is somewhere else each time. I have not paid sufficient attention to whether or not each crash involves heap allocation/deallocation activities. I will pay extra attention in future crashes though. Of course, the command gEC.ReportDiagnostic(/*...*/) below means considerable heap allocation/deallocation activity as a result of stl string manipulation. So again, if the issue is realted to an insufficiently large local heap it might to some degree explain the situation. However, I would have though that this would result in an "uncaught exception error" and not a "egmentation fault".
On Thu, Jun 17, 2004 at 03:05:01PM +1200, Craig Box wrote:
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()); }
I've encountered problems before when doing things like string + "c string" + string
You could try changing that to string + string("c string") + string just in case it is a casting/pointer arithmetic problem.
C++ string handling seems to be a pet hate of many of the wlug members who are programmers...
Another alternative is that the bug is somewhere else entirely, but it happens to modify memory at this particular point, so everything runs fine until it uses this bit of memory.
John McPherson
Pete wrote:
John, beware that my sample was only indicative of the problem associated with the stack trace I submitted along with it. A fact is that the "crash-point" is somewhere else each time. I have not paid sufficient attention to whether or not each crash involves heap allocation/deallocation activities. I will pay extra attention in future crashes though.
I'd suspect that you've written past the end of an allocated block of memory. If you do that then your program will crash next time you try to malloc() or free() memory. valgrind should find it for you (And lots and lots of other bugs :)
participants (4)
-
Craig Box -
John R. McPherson -
Perry Lorier -
Pete