Thread Rating:
  • 0 Votes - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
No stack trace for assertion failure on Linux NAS
07-10-2012, 10:26 PM
Post: #1
No stack trace for assertion failure on Linux NAS
When running ohNet on a Linux x86 NAS, an assertion failure produces an error message identifying the assertion location, but there's no stack trace. The output is as follows:

ERROR: Recursive lock attempted on mutex DSUM from thread NACN
Assertion failed. OpenHome/Thread.cpp:89

My impression from reading the code is that the default error handler calls abort() after printing these messages.

Should the abort() call produce a stack trace on Linux? This would be very useful for problem determination. I found some code in Exception.cpp that calls backtrace(), but this only seems to be used for Mac OS X.

I believe abort() is supposed to raise a SIGABRT exception. For a SIGSEGV signal raised by a native thread, the JVM's exception handler prints an error report including a backtrace for the signalling thread. I'd have expected the same thing to happen for a SIGABRT signal, but for some reason it doesn't.

I'd like to investigate this JVM behaviour further. To help me do this, I would appreciate some information about the expected behaviour when ohNet either produces a SIGSEGV or does an abort() call in a non-Java Linux environment.
Find all posts by this user
08-10-2012, 10:05 AM
Post: #2
RE: No stack trace for assertion failure on Linux NAS
I've committed a fix for this now.

Stack traces aren't currently generated on Linux. For them to be added, we'd need to add code to the OsStackTrace* functions in ohNet/Os/Posix/Os.c.

I won't have time to look at this immediately. I'd happily accept a patch if you happen to know off-hand how to implement this :-).
Find all posts by this user
08-10-2012, 10:14 AM
Post: #3
RE: No stack trace for assertion failure on Linux NAS
Based on a quick search, the ifdef'd code for Mac in Os.c may just work on Linux...
Find all posts by this user
08-10-2012, 10:45 AM (This post was last modified: 08-10-2012 11:27 AM by simoncn.)
Post: #4
RE: No stack trace for assertion failure on Linux NAS
(08-10-2012 10:14 AM)simonc Wrote:  Based on a quick search, the ifdef'd code for Mac in Os.c may just work on Linux...

Yes, I think this code would probably work on Linux. I can test this.

This code is currently called as part of OpenHome::UnhandledExceptionHandler(). I presume I would need to add code to also call it as part of InitialisationParams::FatalErrorHandlerDefault().

Does this seem like a reasonable approach? If so, I'd be happy to test it and provide a patch.

(08-10-2012 10:05 AM)simonc Wrote:  I've committed a fix for this now.

Thanks very much!

Does this fix the mutex recursive lock error, or the crash in DviSessionUpnp::~DviSessionUpnp(), or both of these?
Find all posts by this user
08-10-2012, 01:17 PM
Post: #5
RE: No stack trace for assertion failure on Linux NAS
(08-10-2012 10:45 AM)simoncn Wrote:  This code is currently called as part of OpenHome::UnhandledExceptionHandler(). I presume I would need to add code to also call it as part of InitialisationParams::FatalErrorHandlerDefault().

Does this seem like a reasonable approach? If so, I'd be happy to test it and provide a patch.

That sounds about right. You might be able to cover this by moving code from OpenHome::UnhandledExceptionHandler (in Exception.cpp) into CallFatalErrorHandler

(08-10-2012 10:45 AM)simoncn Wrote:  Thanks very much!

Does this fix the mutex recursive lock error, or the crash in DviSessionUpnp::~DviSessionUpnp(), or both of these?

The recursive lock error. I'm still investigating the crash in ~DviSessionUpnp.
Find all posts by this user
08-10-2012, 04:16 PM
Post: #6
RE: No stack trace for assertion failure on Linux NAS
(08-10-2012 01:17 PM)simonc Wrote:  That sounds about right. You might be able to cover this by moving code from OpenHome::UnhandledExceptionHandler (in Exception.cpp) into CallFatalErrorHandler

That makes sense, except that the stack trace code might be better placed in FatalErrorHandlerDefault to give the application the opportunity to override it if desired. This would be a slight change to the current treatment of Mac OS X unhandled exceptions, which always write a stack trace even if a replacement fatal error handler is installed. Do you think the writing of the stack trace should be overrideable in this way?
Find all posts by this user
08-10-2012, 04:18 PM
Post: #7
RE: No stack trace for assertion failure on Linux NAS
(08-10-2012 04:16 PM)simoncn Wrote:  That makes sense, except that the stack trace code might be better placed in FatalErrorHandlerDefault to give the application the opportunity to override it if desired. This would be a slight change to the current treatment of Mac OS X unhandled exceptions, which always write a stack trace even if a replacement fatal error handler is installed. Do you think the writing of the stack trace should be overrideable in this way?

This might be taking configuration too far. I can't think off-hand of any case where an app could reasonably expect to be able to suppress logging of crash data.
Find all posts by this user
08-10-2012, 06:28 PM
Post: #8
RE: No stack trace for assertion failure on Linux NAS
(08-10-2012 04:18 PM)simonc Wrote:  This might be taking configuration too far. I can't think off-hand of any case where an app could reasonably expect to be able to suppress logging of crash data.

I was thinking more of an app redirecting it rather than suppressing it. However, it wouldn't do any harm to print this to stderr, as an app could direct it elsewhere (in addition) if necessary. I'll put this code into CallFatalErrorHandler.
Find all posts by this user


Forum Jump: