LTTng » LTTng-tools

Hi,

Yes, I did just now on the ubuntu machine. Same behaviour.

Regards.

Hi,

I've been debugging a bit. Within the sessiond_poll thread ,on receiving command 11 - LTTNG_CONSUMER_CLOSE_METADATA, the wait fd/poll pipe of the metadata stream is not closed when using snapshot sessions. Because the channel key passed to close_metadata() ( calling consumer_find_channel() and passing the channel ref to lttng_ustconsumer_close_metadata() ) corresponds to a channel for which the condition !channel->metadata_stream ( within lttng_ustconsumer_close_metadata() ) evaluates as true. Causing the metadata_poll thread to not get any LPOLLHUP event over the pipe and it doesn't call consumer_del_metadata_stream() to free the shm_table.
Does any of this make any sense? Do you think this is possibly the reason for the behaviour I'm getting?

Regards.

Florea Irinel wrote:

Hi,

I've been debugging a bit.

Good!

Within the sessiond_poll thread ,on receiving command 11 - LTTNG_CONSUMER_CLOSE_METADATA, the wait fd/poll pipe of the metadata stream is not closed when using snapshot sessions. Because the channel key passed to close_metadata() (
calling consumer_find_channel() and passing the channel ref to lttng_ustconsumer_close_metadata() ) corresponds to a channel for which the condition !channel->metadata_stream ( within lttng_ustconsumer_close_metadata() ) evaluates as
true. Causing the metadata_poll thread to not get any LPOLLHUP event over the pipe and it doesn't call consumer_del_metadata_stream() to free the shm_table.
Does any of this make any sense? Do you think this is possibly the reason for the behaviour I'm getting?

Well, were you able to fix your issue ? If so do you have a patch we can look at?

Since you have a reproducer I would suggest that you poke around and try a fix while we find some time to look at it.

Cheers

Regards.

Hi,

Since on snapshot sessions the metadata stream is not monitored by the metadata thread the stream has to be freed somewhere else (the closing of the wait fd's does not suffice). Do you agree? If yes, what is the best approach :
- to make sessiond to issue a LTTNG_CONSUMER_DESTROY_CHANNEL command after the LTTNG_CONSUMER_CLOSE_METADATA?
- in consumerd at receiving LTTNG_CONSUMER_CLOSE_METADATA if the metadata stream is not monitored , notify channel thread using notify_thread_del_channel() ?
- something else.

Regards.

Florea Irinel wrote:

Hi,

Since on snapshot sessions the metadata stream is not monitored by the metadata thread the stream has to be freed somewhere else (the closing of the wait fd's does not suffice). Do you agree? If yes, what is the best approach :
- to make sessiond to issue a LTTNG_CONSUMER_DESTROY_CHANNEL command after the LTTNG_CONSUMER_CLOSE_METADATA if the session is in snapshot mode?
- in consumerd at receiving LTTNG_CONSUMER_CLOSE_METADATA if the metadata stream is not monitored , notify channel thread using notify_thread_del_channel() ?
- something else.

Regards.

Hi Florea,

I would recommend that you send a proper email to the mailing with the patch inline with a more verbose message explaining everything in the commit message (valgrind report, causes etc.) Please read http://lttng.org/community/#contributors-guide for more detail.

I'm very glad that you went the patch way! We are always looking for new contributors.

Cheers!