Bug #796

Crash in ReceiverTask w/o Stacktrace on MacOS

Added by S. Wrede over 9 years ago. Updated over 7 years ago.

Status:RejectedStart date:01/06/2012
Priority:NormalDue date:
Assignee:S. Wrede% Done:

0%

Category:C++
Target version:rsb-0.11

Description

Trying to receive events containing rst.vision.Image data as payload (send as fragmented notifications), the client program (rsbvideoreceiver) crashes without backtrace although compiled with debugging info on MacOS. While this may perfectly be related to the code running inside the handler itself, the current (not existing) error handling in ReveiverTask::notifyHandler is a potential problem (already indicative is also the TODO comment in line 147). Putting a catch all statement around the relevant lines prevents the crash but is obviously not a working solution.

The console log is currently as follows (on MacOS Lion, using rsbag replayed video data):

1325888169340 rsbvideoreceiver.main [INFO]: RSB Objects created
1325888169387 rsbvideoreceiver.main [INFO]: Waiting for RST images
1325888169519 rsb.transport.spread.SpreadConnection [DEBUG]: regular spread message received
1325888169519 rsb.transport.spread.SpreadConnection [DEBUG]: received message, addressed at group with name 6666cd76f96956469e7be39d750cc7d
1325888169519 rsb.transport.spread.SpreadConnection [DEBUG]: received message, addressed at group with name 9451dbe609f25fd752a2fb5ab53f332
1325888169519 rsb.transport.spread.SpreadConnection [DEBUG]: received message, addressed at group with name 13e3137296cf2067027c79cbb46686b
1325888169519 rsb.transport.spread.SpreadConnection [DEBUG]: received message, addressed at group with name 96eec47af803e5856d376490efae223
1325888169519 rsb.spread.ReceiverTask [DEBUG]: ReceiverTask::execute new SpreadMessage received 0x7f9cbbc29400
1325888169519 rsb.spread.ReceiverTask [TRACE]: Parsed event seqnum: 1023
1325888169519 rsb.spread.ReceiverTask [TRACE]: Binary length: 99919
1325888169519 rsb.spread.ReceiverTask [TRACE]: Number of split message parts: 2
1325888169519 rsb.spread.ReceiverTask [TRACE]: ... received message part    : 0
1325888169519 rsb.spread.AssemblyPool [TRACE]: Creating new assembly for notification 1023
1325888169520 rsb.spread.Assembly[1023] [TRACE]: Adding notification 1023 (part 0/2) to assembly
1325888169520 rsb.spread.AssemblyPool [TRACE]: dataPool size: 1
1325888169520 rsc.threading.RepetitiveTask [TRACE]: Times (last cycle = 0.036597s)
1325888169520 rsc.threading.RepetitiveTask [TRACE]: run cycle done
1325888169520 rsb.transport.spread.SpreadConnection [DEBUG]: regular spread message received
1325888169520 rsb.transport.spread.SpreadConnection [DEBUG]: received message, addressed at group with name 6666cd76f96956469e7be39d750cc7d
1325888169520 rsb.transport.spread.SpreadConnection [DEBUG]: received message, addressed at group with name 9451dbe609f25fd752a2fb5ab53f332
1325888169520 rsb.transport.spread.SpreadConnection [DEBUG]: received message, addressed at group with name 13e3137296cf2067027c79cbb46686b
1325888169520 rsb.transport.spread.SpreadConnection [DEBUG]: received message, addressed at group with name 96eec47af803e5856d376490efae223
1325888169520 rsb.spread.ReceiverTask [DEBUG]: ReceiverTask::execute new SpreadMessage received 0x7f9cbc809870
1325888169520 rsb.spread.ReceiverTask [TRACE]: Parsed event seqnum: 1023
1325888169520 rsb.spread.ReceiverTask [TRACE]: Binary length: 53783
1325888169520 rsb.spread.ReceiverTask [TRACE]: Number of split message parts: 2
1325888169520 rsb.spread.ReceiverTask [TRACE]: ... received message part    : 1
1325888169520 rsb.spread.AssemblyPool [TRACE]: Adding notification 1023 to existing assembly 0x7f9cbc80b6f0
1325888169520 rsb.spread.Assembly[1023] [TRACE]: Adding notification 1023 (part 1/2) to assembly
1325888169520 rsb.spread.Assembly[1023] [TRACE]: Joining fragments
1325888169520 rsb.spread.AssemblyPool [TRACE]: dataPool size: 0
1325888169520 rsb.spread.ReceiverTask [TRACE]: ReceiverTask::execute fragmented notification joined, last message 0x7f9cbc809870
terminate called without an active exceptionAbort trap: 6

Related issues

Related to Robotics Service Bus - Bug #344: C++ Spread: Transport-level errors are not handled properly New 06/05/2011
Related to Robotics Service Bus - Tasks #1768: Evaluate Boost.Exception for dealing with re-thrown excep... New 02/14/2014
Related to Robotics Service Bus - Tasks #1513: Document exception handling in main function of RSB-using... Resolved 05/27/2013

Associated revisions

Revision 0dd8bad5
Added by S. Wrede over 9 years ago

early workaround for crash in notfiyHandler, more sophisticated error handling strategy required, refs #796

Revision 8b3c813f
Added by J. Moringen over 9 years ago

Control start of recording in src/rsb/*.lisp
refs #796
  • src/rsb/protocol.lisp (events->bag listener bag): added start?
    keyword parameter; updated documentation string accordingly
  • src/rsb/construction.lisp (events->bag listener bag): added start?
    keyword parameter; pass to constructed channel connection
  • src/rsb/channel-connection.lisp
    (initialize-instance :after recording-channel-connection): added
    start? initarg; only start recording if its value is true

History

#1 Updated by S. Wrede over 9 years ago

  • Status changed from New to In Progress

Just a note: The actual reason for the exception is that no matching converter can be found:

ReceiverTask::notifyHandler catched std exception: No converter for wire-schema or data-type `NIL'.

#2 Updated by J. Moringen over 9 years ago

Where do the events come from?

#3 Updated by S. Wrede over 9 years ago

The data comes from a NAO dataset recording as part of the Geniale activities. To tackle this problem, I openend another issue #797 in the RSBag project.

In this ticket, we should discuss how to deal with errors in the notifyHandler method. For instance, I could add a similar errorHandlingStrategy mechanism as in place in the Connector classes to prevent this kind of uncontrolled segfault. Any opinions on this?

#4 Updated by J. Wienke about 8 years ago

I don't think this will help us with this precise issue, but backtraces can sometimes be found in Console.app on Mac. Did you check this? Can you reproduce this issue again so that we can work on it?

#5 Updated by J. Moringen over 7 years ago

  • Target version set to rsb-0.11

#6 Updated by J. Moringen over 7 years ago

  • Status changed from In Progress to Rejected

I'm rejecting this since there has been no feedback for a long time and we have to tackle the problem more generally anyway. In particular, the related issues #1768 and #1513 subsume this problem.

Also available in: Atom PDF