Fix: common: fs_handle_seek returns negative value on success
authorJonathan Rajotte <jonathan.rajotte-julien@efficios.com>
Thu, 21 May 2020 00:53:45 +0000 (20:53 -0400)
committerJérémie Galarneau <jeremie.galarneau@efficios.com>
Thu, 21 May 2020 14:19:06 +0000 (10:19 -0400)
Observed issue
==============

Babeltrace 1/2 fails to fetch data from a live session.

Error:

 PLUGIN/SRC.CTF.LTTNG-LIVE/VIEWER lttng_live_get_stream_bytes@viewer-connection.c:1593 [lttng-live] Received get_data_packet response: error
 PLUGIN/CTF/MSG-ITER request_medium_bytes@msg-iter.c:546 [lttng-live] User function failed: status=ERROR
 PLUGIN/CTF/MSG-ITER ctf_msg_iter_get_next_message@msg-iter.c:2881 [lttng-live] Cannot handle state: msg-it-addr=0x562d87521a40, state=DSCOPE_TRACE_PACKET_HEADER_BEGIN
 PLUGIN/SRC.CTF.LTTNG-LIVE lttng_live_iterator_next_handle_one_active_data_stream@lttng-live.c:821 [lttng-live] CTF message iterator failed to get next message: msg-iter=0x562d87521a40, msg-iter-status=ERROR
 PLUGIN/SRC.CTF.LTTNG-LIVE lttng_live_msg_iter_next@lttng-live.c:1499 [lttng-live] Error preparing the next batch of messages: live-iter-status=LTTNG_LIVE_ITERATOR_STATUS_ERROR
 LIB/MSG-ITER bt_message_iterator_next@iterator.c:865 Component input port message iterator's "next" method failed: iter-addr=0x562d8751ab70, iter-upstream-comp-name="lttng-live", iter-upstream-comp-log-level=WARNING, iter-upstream-comp-class-type=SOURCE, iter-upstream-comp-class-name="lttng-live", iter-upstream-comp-class-partial-descr="Connect to an LTTng relay daemon", iter-upstream-port-type=OUTPUT, iter-upstream-port-name="out", status=ERROR
 PLUGIN/FLT.UTILS.MUXER muxer_upstream_msg_iter_next@muxer.c:446 [muxer] Upstream iterator's next method returned an error: status=ERROR
 PLUGIN/FLT.UTILS.MUXER validate_muxer_upstream_msg_iters@muxer.c:989 [muxer] Cannot validate muxer's upstream message iterator wrapper: muxer-msg-iter-addr=0x562d87515280, muxer-upstream-msg-iter-wrap-addr=0x562d8751ca90
 PLUGIN/FLT.UTILS.MUXER muxer_msg_iter_next@muxer.c:1417 [muxer] Cannot get next message: comp-addr=0x562d8751a260, muxer-comp-addr=0x562d8751a2e0, muxer-msg-iter-addr=0x562d87515280, msg-iter-addr=0x562d8751aa90, status=ERROR
 LIB/MSG-ITER bt_message_iterator_next@iterator.c:865 Component input port message iterator's "next" method failed: iter-addr=0x562d8751aa90, iter-upstream-comp-name="muxer", iter-upstream-comp-log-level=WARNING, iter-upstream-comp-class-type=FILTER, iter-upstream-comp-class-name="muxer", iter-upstream-comp-class-partial-descr="Sort messages from multiple inpu", iter-upstream-port-type=OUTPUT, iter-upstream-port-name="out", status=ERROR
 LIB/GRAPH consume_graph_sink@graph.c:462 Component's "consume" method failed: status=ERROR, comp-addr=0x562d8751a3d0, comp-name="pretty", comp-log-level=WARNING, comp-class-type=SINK, comp-class-name="pretty", comp-class-partial-descr="Pretty-print messages (`text` fo", comp-class-is-frozen=0, comp-class-so-handle-addr=0x562d8751a110, comp-class-so-handle-path="/usr/local/lib/babeltrace2/plugins/babeltrace-plugin-text.so", comp-input-port-count=1, comp-output-port-count=0
 CLI cmd_run@babeltrace2.c:2529 Graph failed to complete successfully
 PLUGIN/SRC.CTF.LTTNG-LIVE/VIEWER lttng_live_session_detach@viewer-connection.c:1211 [lttng-live] Unknown detach return code 0

The relevant relayd log:

 DEBUG2 - Relay get data packet (in viewer_get_packet() at live.c:1770)
 PERROR - Failed to seek file system handle of viewer stream 4 to offset 2244861952: Success (in viewer_get_packet() at live.c:1810)
 DEBUG1 - Sent 262156 bytes for stream 4 (in viewer_get_packet() at live.c:1852)

Cause
=====

The fs_handle_seek function calls lseek on a stream file of ~2.5GB. The
return value of the lseek call is downcasted from off_t (signed 64 bit
on my system) to int. The resulting value is negative and force an error
at the call sites.

Solution
========

Use off_t as the return type.

Note that current call sites of fs_handle_seek already expect an off_t
return value.

ag fs_handle_seek:

 src/bin/lttng-relayd/stream.c
 249: lseek_ret = fs_handle_seek(previous_stream_file, previous_stream_copy_origin, SEEK_SET);

 src/bin/lttng-relayd/live.c
 1804: lseek_ret = fs_handle_seek(vstream->stream_file.handle,

 src/bin/lttng-relayd/viewer-stream.c
 176: lseek_ret = fs_handle_seek(

ag lseek_ret:

 src/bin/lttng-relayd/stream.c
 193: off_t lseek_ret, previous_stream_copy_origin;

 src/bin/lttng-relayd/live.c
 1760: off_t lseek_ret;

 src/bin/lttng-relayd/viewer-stream.c
 174: off_t lseek_ret;

Known drawbacks
=========

This limitation existed before this patch.

On 32bit system without _FILE_OFFSET_BITS=64 defined at compile time
(-D_FILE_OFFSET_BITS=64) the lseek operation could return EOVERFLOW for
stream file bigger then 2,147,483,647 bytes. Anybody working on a 32bit
system should be aware of the limitation of working in 32bit.

Signed-off-by: Jonathan Rajotte <jonathan.rajotte-julien@efficios.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: Ib6c7bb3c9c402bdfbe9b447b1f8f298de6058caa

src/common/fs-handle.c
src/common/fs-handle.h

index ff081235cb8d6d2c3ecebf505963ec02fcf9d40d..46d9d7de5d322f2f82940c72c8eef2619b40e0ad 100644 (file)
@@ -70,7 +70,7 @@ end:
 LTTNG_HIDDEN
 int fs_handle_truncate(struct fs_handle *handle, off_t offset)
 {
-        int ret;
+       int ret;
        const int fd = fs_handle_get_fd(handle);
 
        if (fd < 0) {
@@ -85,9 +85,9 @@ end:
 }
 
 LTTNG_HIDDEN
-int fs_handle_seek(struct fs_handle *handle, off_t offset, int whence)
+off_t fs_handle_seek(struct fs_handle *handle, off_t offset, int whence)
 {
-        int ret;
+       off_t ret;
        const int fd = fs_handle_get_fd(handle);
 
        if (fd < 0) {
index e36f7a4dea1cd38ebaad3a408b6586105c2e6a62..1627f7cfeb122197e346aed58bc7508bd140c899 100644 (file)
@@ -69,6 +69,6 @@ LTTNG_HIDDEN
 int fs_handle_truncate(struct fs_handle *handle, off_t offset);
 
 LTTNG_HIDDEN
-int fs_handle_seek(struct fs_handle *handle, off_t offset, int whence);
+off_t fs_handle_seek(struct fs_handle *handle, off_t offset, int whence);
 
 #endif /* FS_HANDLE_H */
This page took 0.026592 seconds and 4 git commands to generate.