Skip to content

Bug in "Probe" logic in Entity Manager- while parsing Probe statements from EM configs #24

Description

@harsh23tyagi11

I recently discovered this little bug in the logic that parses the probe statement in Entity Manager, hence documenting it for visibility and can fix this later either by a creating an exclusive parser or some other parsing mechanism.

Bug Description:
The code line here in findProbeType() method call- https://github.com/openbmc/entity-manager/blob/master/src/entity_manager.cpp#L92 is
if probe.find(probeType->first) != std::string::npos) which fails if the probe statement has OR in it as it will find the first occurrence of the probeTypes in the string.

For instance: probe = xyz.openbmc_project.UsbDevice({'VENDOR_ID': '2frrr3'}) would fail to be probed and would be considered as a conjunction statement - since it has OR at 36th index (in vendOR_id).

probeType->first values are yielded from:

probeTypes{{{"FALSE", probe_type_codes::FALSE_T},
                {"TRUE", probe_type_codes::TRUE_T},
                {"AND", probe_type_codes::AND},
                {"OR", probe_type_codes::OR},
                {"FOUND", probe_type_codes::FOUND},
                {"MATCH_ONE", probe_type_codes::MATCH_ONE}}};

Now every time this function yields to true, the EM doesn't search the DBus for object paths and consider it as a conjunction statement such as OR, FOUND etc.

Current resolution:
Until this is fixed avoid having probeTypes character strings in the probe statements.

Potential fixes:

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions