The stream ID and stream instance ID are invariant for a stream, so
there is no point reading them from the packet header currently owned by
the consumer (between get/put subbuf).
Actually, the consumer try to access the stream_id from the live timer
when sending a live beacon without getting the reader subbuffer first,
which can trigger WARN_ON safety nets in libringbuffer. This safety
net triggers a kernel OOPS report and disables tracing for that channel.
In the case where a ring buffer does not have any data ready, it makes
no sense to try to get a subbuffer for reading anyway, so the approach
was broken.
So return the stream id and stream instance id from the internal
data structures rather than reading it from the ring buffer.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoy...@efficios.com>
---
lttng-ring-buffer-client.h | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/lttng-ring-buffer-client.h b/lttng-ring-buffer-client.h
index dc3356e4..d5c512c5 100644
--- a/lttng-ring-buffer-client.h
+++ b/lttng-ring-buffer-client.h
@@ -479,9 +479,10 @@ static int client_stream_id(const struct
lib_ring_buffer_config *config,
struct lib_ring_buffer *buf,
uint64_t *stream_id)
{
- struct packet_header *header = client_packet_header(config, buf);
- *stream_id = header->stream_id;
+ struct channel *chan = buf->backend.chan;
+ struct lttng_channel *lttng_chan = channel_get_private(chan);
+ *stream_id = lttng_chan->id;
return 0;
}
@@ -510,8 +511,7 @@ int client_instance_id(const struct lib_ring_buffer_config
*config,
struct lib_ring_buffer *buf,
uint64_t *id)
{
- struct packet_header *header = client_packet_header(config, buf);
- *id = header->stream_instance_id;
+ *id = buf->backend.cpu;
return 0;
}
--
2.11.0
_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
