Project

General

Profile

Actions

Bug #1411

closed

Memory leak when relay daemon exits before application starts

Added by Mikael Beckius about 2 months ago. Updated 23 days ago.

Status:
Resolved
Priority:
Normal
Target version:
Start date:
03/13/2024
Due date:
% Done:

0%

Estimated time:

Description

When the relay daemon is shutdown after creating a live session but before applications are started the shared memory allocated for tracing appears to remain and new memory is allocated for every application start.

How to reproduce:
host:~# lttng create micke --live
Spawning a session daemon
Spawning a relayd daemon
Live session micke created.
Traces will be output to tcp4://127.0.0.1:5342/ [data: 5343]
Live timer interval set to 1000000 us

host:~# lttng enable-event --userspace --all
All ust events are enabled in channel channel0

host:~# lttng start
Tracing started for session micke

host:~# killall -9 lttng-relayd

host:~# free -h
total used free shared buff/cache available
Mem: 15Gi 207Mi 15Gi 572Ki 320Mi 15Gi
Swap: 0B 0B 0B

host:~# ./micke-lttng
Mikael LTTNG 2015 - Starting
Mikael LTTNG 2015 - Signing out

host:~# free -h
total used free shared buff/cache available
Mem: 15Gi 248Mi 15Gi 40Mi 360Mi 15Gi
Swap: 0B 0B 0B

host:~# ./micke-lttng
Mikael LTTNG 2015 - Starting
Mikael LTTNG 2015 - Signing out

host:~# free -h
total used free shared buff/cache available
Mem: 15Gi 288Mi 15Gi 80Mi 400Mi 15Gi
Swap: 0B 0B 0B

host:~# lttng destroy micke
Destroying session micke..
Session micke destroyed

host:~# free -h
total used free shared buff/cache available
Mem: 15Gi 289Mi 15Gi 80Mi 400Mi 15Gi
Swap: 0B 0B 0B
host:~#

Version:
lttng-tools 2.13.11

Analyzis:
It seems that when the first application of a session starts, after the relay daemon has been shutdown, a failure to transfer streams to the relay deamon triggers a clean up through a call to ust_consumer_destroy_channel. But it appears that the cleanup isn't complete and the channel reference count remains incremented. Decrementing the reference count appears to be blocked in clean_channel_stream_list by stream->monitor = 0; preventing CONSUMER_CHANNEL_DEL from reaching consumer_del_channel(chan);

Information has it that this problem is NOT reproduced on 2.13 but I haven't tested that myself

Actions

Also available in: Atom PDF