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