Actions
Bug #1227
opencli: Error when using --clock-cycles and -c sink.text.pretty at the same time
Start date:
02/17/2020
Due date:
% Done:
0%
Estimated time:
Description
When using both --clock-cycles
and -c sink.text.pretty
at the same time, the cli tries to instantiate two pretty components:
Source component instances: 'source.test-trimmer.TheSourceOfAllEvil': Name: source.test-trimmer.TheSourceOfAllEvil Parameters: { } Filter component instances: 'filter.utils.muxer': Name: muxer Parameters: { } 'filter.utils.trimmer': Name: trimmer Parameters: begin: 350 Sink component instances: 'sink.text.pretty': Name: sink.text.pretty Parameters: { } 'sink.text.pretty': Name: pretty Parameters: verbose: yes clock-cycles: yes Connections: source.test-trimmer.TheSourceOfAllEvil.* -> muxer.* muxer.* -> trimmer.* trimmer.* -> sink.text.pretty.* trimmer.* -> pretty.*
one of which has an input not connected. It later hits the assertion:
06-28 23:41:33.022 26827 26827 F LIB/MSG-ITER bt_self_component_port_input_message_iterator_create@iterator.c:427 Babeltrace 2 library precondition not satisfied; error is: 06-28 23:41:33.022 26827 26827 F LIB/MSG-ITER bt_self_component_port_input_message_iterator_create@iterator.c:427 Port is not connected: port-addr=0x607000002390, port-type=BT_PORT_TYPE_INPUT, port-name="in" 06-28 23:41:33.022 26827 26827 F LIB/MSG-ITER bt_self_component_port_input_message_iterator_create@iterator.c:427 Aborting...
Updated by Jonathan Rajotte Julien over 4 years ago
Follow up:
From Philippe Proulx:
This is intended, even if it looks weird: why would you specify @sink.text.pretty@ if you already use @--clock-cycles@, and even then, it's the default sink. Dedicated @convert@ options apply to implicit components, while specific components created with @-c@ are completely independent. This is why you get two @sink.text.pretty@ components with this command. The default sink is @sink.text.pretty@, but when you specify at least one sink with @-c sink.X.Y@, you override it. But then @--clock-cycles@ brings it back. At least this is the way it works now, but I'm open to changes. I guess you would have expected that specifying @-c sink.text.pretty@ is a special case which does nothing. I would accept that. I think the @convert@ command should also allow a single sink component. If you specify something else than @-c sink.text.pretty@, then use that one. But you should not be able to specify @-c sink.X.Y@ two times or more because the @convert@ topology is fixed (you can't specify connections), and one of them will never be connected. To avoid the precondition failure, @sink.text.pretty@ must check that its input port is connected (@bt_port_is_connected()@) before it calls @bt_self_component_port_input_message_iterator_create()@, and fail gracefully if not.
From Jonathan Rajotte:
This is moved to 2.0 and could even be moved to 2.1. For now bt2 muxer support only a single output, inherently we support a single sink since we do not have a "dmux/tee" filter (component). We do not foresee any problem with the current API limiting the implementation of such component thus we move it to 2.0 or 2.1.
Updated by Jonathan Rajotte Julien over 4 years ago
- Author changed from 215 to 8
Updated by Jonathan Rajotte Julien over 4 years ago
Migrated from internal bug tracker.
Actions