Project

General

Profile

Bug #1227

cli: Error when using --clock-cycles and -c sink.text.pretty at the same time

Added by Simon Marchi 10 months ago. Updated 10 months ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
CLI
Target version:
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...
#1

Updated by Jonathan Rajotte Julien 10 months 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.
#2

Updated by Jonathan Rajotte Julien 10 months ago

  • Author changed from 215 to 8
#3

Updated by Jonathan Rajotte Julien 10 months ago

Migrated from internal bug tracker.

Also available in: Atom PDF