Fix: bytecode interpreter context_get_index() leaves byte order uninitialized
authorMathieu Desnoyers <mathieu.desnoyers@efficios.com>
Wed, 30 Mar 2022 18:24:54 +0000 (14:24 -0400)
committerMathieu Desnoyers <mathieu.desnoyers@efficios.com>
Fri, 3 Jun 2022 15:42:21 +0000 (11:42 -0400)
commit2c70564defbb66d6c2a776719642cef2bc17a2f6
tree3aed6d2993b873f3b7bae28b37019538d05b02c0
parented1149ef88fb62c365ac66cf62c58ac6abd8d7e8
Fix: bytecode interpreter context_get_index() leaves byte order uninitialized

Observed Issue
==============

When using the event notification capture feature to capture a context
field, e.g. '$ctx.cpu_id', the captured value is often observed in
reverse byte order.

Cause
=====

Within the bytecode interpreter, context_get_index() leaves the "rev_bo"
field uninitialized in the top of stack.

This only affects the event notification capture bytecode because the
BYTECODE_OP_GET_SYMBOL bytecode instruction (as of lttng-tools 2.13)
is only generated for capture bytecode in lttng-tools. Therefore, only
capture bytecode targeting contexts are affected by this issue. The
reason why lttng-tools uses the "legacy" bytecode instruction to get
context (BYTECODE_OP_GET_CONTEXT_REF) for the filter bytecode is to
preserve backward compatibility of filtering when interacting with
applications linked against LTTng-UST 2.12.

Solution
========

Initialize the rev_bo field based on the context field type
reserve_byte_order field.

Known drawbacks
===============

None.

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: I1483642b0b8f6bc28d5b68be170a04fb419fd9b3
src/lttng-bytecode-interpreter.c
This page took 0.026017 seconds and 4 git commands to generate.