Bug #1227
open
cli: Error when using --clock-cycles and -c sink.text.pretty at the same time
Added by Simon Marchi almost 5 years ago.
Updated almost 5 years ago.
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...
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.
- Author changed from 215 to 8
Migrated from internal bug tracker.
Also available in: Atom
PDF