Bug #796
Crash in ReceiverTask w/o Stacktrace on MacOS
| Status: | Rejected | Start date: | 01/06/2012 | |
|---|---|---|---|---|
| Priority: | Normal | Due 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
Associated revisions
early workaround for crash in notfiyHandler, more sophisticated error handling strategy required, refs #796
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 12 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 12 years ago
Where do the events come from?
#3 Updated by S. Wrede over 12 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 over 10 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 about 10 years ago
- Target version set to rsb-0.11
#6 Updated by J. Moringen about 10 years ago
- Status changed from In Progress to Rejected