Exception not always caught in Sun Studio 12

Question

Hi,
We're using Sun Studio 12 (Sun C++ 5.9 SunOS_sparc Patch 124863-01 2007/07/25) on a Solaris 10 SPARC machine. In our applications an exception thrown is sometimes not caught in the try/catch statement and the program continues at an outer catch statement (which usually leads to the program exiting). So far I've not been able to reduce the code down to a simple example and I don't yet know what conditions causes this behaviour.
In general the code has a big try/catch statement in main. Somewhere deep in the code there is a second try/catch statement which protects against a piece of code which we know may throw an exception. This is usually a smart pointer being dereferenced. The act of dereferencing the smart pointer in turn causes an exception to be thrown which is caught internally in a third try/catch inside the dereference code. The exception is successfully caught and some clean up is done. Then the exception is re-thrown by either using a throw; statement or a new throw xmsg("...");. All our exceptions are always of type xmsg which simply takes a string argument.
When the problem manifests itself the second try/catch is ignored and the re-thrown exception is instead caught in the outer catch statement in main which causes the program to log an error and exit.
We have lots of code which is structured the same way and the same style of code works in many cases only to fail in some specific case. It's an elusive problem because the problem moves around and it also depends on how the program is compiled. It only seems to happen when compiled in debug mode. If I compile with -xO4 the problem seems to go away.
The problem also goes away or moves to a different place if the code has changed somewhere between compiles, i.e. some other developer has modified some code, not necessarily in the same are where the problem originally happened.
One thing we have is a function we call DoThrow (used to suppress a warning on an older compiler) defined like this:
void DoThrow(const std::string& msg)
  throw xmsg(msg);
}As an experiment I replaced the call to DoThrow with a straight throw xmsg(...) at a place where the first exception was thrown and the problem went away. I'm not sure if removing the call to DoThrow fixed the problem or if the minor restructuring of the code was enough to move the problem elsewhere.
For production releases we still use WorkShop 6, update 2 which does not have any problems like this. We really would like to upgrade to Sun Studio 12 because it's a much better compiler over all. We can't upgrade until we feel confident we have a workaround.
Does anyone have any thoughts on what might be wrong or any ideas on what I can do to narrow down the problem?
Thanks,
Krister

Answer 1

Many thanks. You've given me a few areas to focus on and I'll bring my house in order.
The only external C++ library we depend on is STLport 5.0.2 which we compile ourselves. It's currently compiled with 5.3 on Solaris 8 and I will recompile it with 5.9 on Solaris 10. All other external libraries are C libraries. Our own code is put in static libraries and linked statically. I've read that exceptions thrown in shared libraries can be problematic.
Your comment about complex conditional expressions (a ? f() : g()) is interesting. We've been bitten before by compiler bugs affecting those types of expressions. Destructors called twice or destructors called for temporaries never created. We may still have some conditional expressions like that.
The exception is of type xmsg, defined this way:
class xmsg
  public:
    xmsg(const char* s) : _msg(s) {}
    xmsg(const std::string& s) : _msg(s) {}
    const std::string& why() const { return _msg; }
  private:
    const std::string _msg;
};There are three catch blocks involved and all the try/catch statement look like this:
try
catch(const xmsg& msg)
}Here is a stack trace from dbx at the point where the exception is thrown the first time.
  [1] __exdbg_notify_of_throw(0xffbf4ae8, 0xffbf4ad0, 0x959b292c, 0xffff0000, 0x0, 0xfc00), at 0xfb6549b4
  [2] _ex_debug_handshake1(0x0, 0x101cb84, 0x1, 0x14ffc, 0xfb66a67c, 0xfb66ad38), at 0xfb655728
  [3] _ex_throw_body(0xfb66af80, 0x80b2ac, 0xfb66a67c, 0x14d9c, 0x0, 0xfb66af80), at 0xfb655934
  [4] __Crun::ex_throw(0xfb66afd0, 0x1460bf8, 0x7ead20, 0x0, 0x16538, 0x1), at 0xfb6558bc
=>[5] TransportSource<User>::Activate(this = 0x1624810, r = CLASS, _ARG3 = CLASS), line 39 in "TransportSource.H"
  [6] Source<User>::DoActivate(this = 0x162486c, r = CLASS, e = CLASS), line 272 in "Factory.H"
  [7] BaseFactory::Load(this = 0x16020a8, e = CLASS), line 2799 in "BaseFactory.C"
  [8] GPAuthorizationSource::Load(this = 0x15d2440), line 110 in "GPAuthorization.C"
  [9] ExchangeServer::ExchangeServer(this = 0xffbfa95c, argc = 8, argv = 0xffbfbaec), line 380 in "exchangeServer.C"
  [10] main(argc = 8, argv = 0xffbfbaec), line 1525 in "exchangeServer.C"Here is the code for the Activate function in stack frame 5. The exception thrown is the second one.
    virtual T& Activate(const Reference& r, Exemplar<T>&)
      _transport->In().Write(r);
      DemarshallStream out;
      _transport->Method(Process::Activate, out);
      if(!out.Data())
     throw xmsg("Failed to call Activate on server " + _transport->Name());
      if(!out.GetBool())
     throw xmsg("Server returned error: " + out.GetString());
      const ClassHandle& h = out.GetClassHandle(&_connection);
      // don't need to pass refresh flag here because a call to Activate
      // means the object is being loaded for the first time.
      BaseExemplar* x = _handle.GetFactory().Demarshall(h, out, false,
     &_connection, this);
      BaseTransportSource::DoActivate(out);
      if(!x)
     throw xmsg("Failed to activate ref: " + r.ExternalValue());
      return static_cast<T&>(*x->GetInstance());
    }The exception is caught (frame 7 in the stack trace above) and re-thrown in the below code, at the last throw statement.
void BaseFactory::Load(BaseExemplar& e)
  SourceMap::iterator p = _sources.find(&e._key->Type());
  if(p == _sources.end())
    throw xmsg("Factory<" + _handle.Name() + ">::Load - no source for: "
      + e._key->ExternalValue());
  AutoPointer<BaseGuard> g(Guard());
  std::list<BaseSource*>::iterator i = p->second.begin();
  while(true)
    try
      (*i)->_currentExemplar = &e;
      BO& x = (*i)->DoActivate(*e._key, e);
      (*i)->_currentExemplar = 0;
      if(!e._instance)
     e._instance = &x;
     Activate(e, ActivatedOld, 0);
      return;
    catch(const xmsg& msg)
      (*i)->_currentExemplar = 0;
      ++i;
      if(i == p->second.end())
     throw;
}There is a second try/catch one level up (stack frame 8, the call to GPAuthorizationSource::Load). Here's a snippet of that piece of code.
    try
      const Exemplar<User>& user = UserFactory::Instance().CreateExemplar(
     *new UserReference(authorizationTable._login.Value()));
      *user;
    catch(const xmsg& msg)
      Logger::Instance() << LogHeader << MsgClass(MsgClass::Error)
     << "Error PMAutorizationSource: " << msg.why() << EndMsg;
    // ...I put a break-point in the catch block in the above code but I never hit the break point and the exception is caught in an outer try/catch, an error is printed and the program exits.
  try
  catch(const xmsg& msg)
    std::cerr << "ERROR: " << msg.why() << std::endl;
  }I'm sorry I have not yet been able to produce a smaller example that can be compiled and tested in isolation. I know that's important in order to track down the problem. It seems like the smallest change in seemingly unrelated parts of the code makes the problem come or go.