Help diagnosing gcc7 on MacOS 10.13 and SIGABRT

[David]

Here’s the problem.

I can’t create a little example, everything I’ve tried works just fine.

The code is (basically)
try {
	run();
} catch(Exception&ex) {
	process ex
	throw;
}

run() is in generated code that we compile and link to the system as a shared library.

It catches an error being sent across a communication path (socket to another thread). The contents of the message are an Exception, so cast and throw as received.

The problem is in the stack walk for ‘throw’. It will walk up the stack, finding the destructors to run and calling them as needed and then fail to find the enclosing catch block, thus calling SIGABRT. In MacOS 10.10 it successfully walks the stack and finds the enclosing catch block, returning there.

My question is: Is there any significant changes in the try/catch logic between 10.10 and 10.13 that might affect gcc7.2 that might cause this?

	David


Exception looks like
class Exception
{
public:
	A lot of constructors
private:
  void* operator new (size_t size);
  void  operator delete (void* p);

  int       m_code;                          // error code
  char      m_entity[EXC_MAX_STRING_LEN];    // what caused the error
  char      m_buffer[EXC_MAX_BUFFER_SIZE];   // buffer for non-default error msgs

  char      m_func[EXC_MAX_STRING_LEN];      // where the error occurred
  char      m_file[EXC_MAX_STRING_LEN];      // where the error occurred
  int       m_line;                          // where the error occurred
  pid_t     m_pid;                           // process that threw the exception
  pid_t     m_tid;                           // thread that threw the exception
  int64     m_timestamp;                     // when the error occurred

  char      m_describe[EXC_MAX_BUFFER_SIZE + (EXC_MAX_STRING_LEN * 3) + EXC_OVERFLOW]; //  describe() buffer
};

> On Sep 10, 2018, at 11:13 AM, Chris Jones <jonesc at hep.phy.cam.ac.uk> wrote:
> 
> Hi,
> 
> Its going to be a little difficult to help without a complete example to look at. For instance I would want to see exact how Exception is defined and exactly what is in the struct you are effectively casting it to (the cast looks suspicious to me, I have to say).
> 
> I would suggest you first try and create a small stand-alone example of the issue. It will then be much easier to offer help.
> 
> Chris
> 
>> On 10 Sep 2018, at 5:46 pm, David <david at kdbarto.org> wrote:
>> 
>> The interesting thing is that the same code, compiled with the same
>> compiler (gcc-mp-7 7.2) works just fine on 10.10. This doesn't happen on
>> every throw, just one in particular.
>> 
>> While not a bug (necessarily) I'm looking for some guidance on where to
>> look to track down the differences in the throw operation between the two
>> OS releases. Any assistance would be useful.
>> 
>> The following code is the specific location where the SIGABRT comes from.
>> We have pushed an exception into our stream and when we detect it we
>> reformat the payload and throw it for a higher layer to capture and
>> report. The contents of the payload matches the class Exception. Exception
>> contains only POD members.
>> 
>> if ( m_packet->io.cmd_code == CmdAbort )
>>   throw *(Exception*)m_packet->io.payload;
>> 
>> The code throws exceptions in multiple other locations, and those all work
>> as expected.
>> 
>> Again, any hints would be very useful.
>> 
>>   David
>> 
>