[lttng-dev] Race condition between lttng destroy and lttng load commands
Hi,
I found there is a race condition between lttng destroy and lttng load commands
in deleting and creating the shared memory path.
lttng -V
lttng (LTTng Trace Control) 2.8.6 - Isseki Nicho - v2.8.6
The test commands are as following:
1) lttng create rcs --shm-path=/var/log/lttng/shm
2) lttng enable-event -s rcs -c ch1 -a -u
3) lttng start rcs
4) lttng save rcs
./Application
5) lttng stop rcs
6) lttng destroy rcs
7) lttng load
Added some debug logs in the following function,
570 int mkdir_check_exists(const char *path, mode_t mode)
571 {
572 int ret = 0;
573 struct stat st;
574
575 fprintf(stderr, "Path %s\n", path);
576 ret = stat(path, );
577 if (ret == 0) {
578 fprintf(stderr, "path stat %s\n", path);
579 fprintf(stderr, "Link count: %ld\n", (long) st.st_nlink);
580 if (S_ISDIR(st.st_mode)) {
581 /* Directory exists, skip. */
582 goto end;
583 } else {
584 /* Exists, but is not a directory. */
585 errno = ENOTDIR;
586 ret = -1;
587 goto end;
588 }
589 }
590
591 /*
592 * Let mkdir handle other errors as the caller expects mkdir
593 * semantics.
594 */
595 ret = mkdir(path, mode);
596 if (ret)
597 PERROR("Mkdir path %s", path);
598 end:
599 return ret;
600 }
The LTTng log is as following:
...
DEBUG3 - 05:49:55.357467 [30485/30489]: mkdir() recursive
/var/log/lttng/shm//rcs-20180529-034348/ust/uid/0/32-bit with mode 504
for uid 0 and gid 0 (in run_as_mkdir_recursive() at runas.c:472)
DEBUG1 - 05:49:55.357490 [30485/30489]: Using run_as worker (in
run_as() at runas.c:451)
Path /var
path stat /var
Link count: 11
Path /var/log
path stat /var/log
Link count: 3
Path /var/log/lttng
path stat /var/log/lttng
Link count: 3
Path /var/log/lttng/shm
path stat /var/log/lttng/shm
Link count: 3
Path /var/log/lttng/shm/
path stat /var/log/lttng/shm/
Link count: 3
Path /var/log/lttng/shm//rcs-20180529-034348
path stat /var/log/lttng/shm//rcs-20180529-034348
Link count: 3
Path /var/log/lttng/shm//rcs-20180529-034348/ust
path stat /var/log/lttng/shm//rcs-20180529-034348/ust
Link count: 3
Path /var/log/lttng/shm//rcs-20180529-034348/ust/uid
path stat /var/log/lttng/shm//rcs-20180529-034348/ust/uid
Link count: 3
Path /var/log/lttng/shm//rcs-20180529-034348/ust/uid/0
path stat /var/log/lttng/shm//rcs-20180529-034348/ust/uid/0
Link count: 3
Path /var/log/lttng/shm//rcs-20180529-034348/ust/uid/0/32-bit
PERROR - 05:49:55.363127 [30486/30486]: Mkdir path
/var/log/lttng/shm//rcs-20180529-034348/ust/uid/0/32-bit: No such file
or directory (in mkdir_check_exists() at utils.c:607)
PERROR - 05:49:55.363156 [30486/30486]: mkdir recursive last element:
No such file or directory (in _utils_mkdir_recursive_unsafe() at
utils.c:692)
PERROR - 05:49:55.363221 [30485/30489]: run_as_mkdir_recursive: No
such file or directory (in ust_registry_session_init() at
ust-registry.c:893)
DEBUG3 - 05:49:55.363261 [30485/30489]: rmdir_recursive()
/var/log/lttng/shm//rcs-20180529-034348 with for uid 0 and gid 0 (in
run_as_rmdir_recursive() at runas.c:528)
DEBUG1 - 05:49:55.363285 [30485/30489]: Using run_as worker (in
run_as() at runas.c:451)
DEBUG3 - 05:49:55.364605 [30486/30486]: Attempting rmdir
/var/log/lttng/shm//rcs-20180529-034348 (in utils_recursive_rmdir() at
utils.c:1343)
DEBUG3 - 05:49:55.365543 [30485/30489]: Buffer registry per UID
destroy with id: 2, ABI: 32, uid: 0 (in buffer_reg_uid_destroy() at
buffer-registry.c:678)
DEBUG3 - 05:49:55.365590 [30485/30489]: Buffer registry per UID find
id: 2, ABI: 32, uid: 0 (in buffer_reg_uid_find() at
buffer-registry.c:203)
DEBUG3 - 05:49:55.365639 [30485/30487]: [ht-thread] Returning from
poll on 2 fds. (in thread_ht_cleanup() at ht-cleanup.c:73)
DEBUG1 - 05:49:55.365647 [30485/30489]: Sending response (size: 20,
retcode: UST create channel failed (58)) (in thread_manage_clients()
at main.c:4588)
Regards,
Liguang
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
Re: [lttng-dev] Babeltrace performance issue in live-reading mode
Hi, On Thu, Sep 21, 2017 at 11:03 PM, Jonathan Rajotte Julien < jonathan.rajotte-jul...@efficios.com> wrote: > Hi, > > On 2017-09-21 05:34 AM, liguang li wrote: > > Hi, > > > > On Wed, Sep 20, 2017 at 10:58 PM, Jonathan Rajotte Julien < > jonathan.rajotte-jul...@efficios.com <mailto:Jonathan.rajotte- > jul...@efficios.com>> wrote: > > > > Hi, > > > > On 2017-09-20 05:12 AM, liguang li wrote: > > > > > > > > > On Tue, Sep 19, 2017 at 10:57 PM, Jonathan Rajotte-Julien < > jonathan.rajotte-jul...@efficios.com <mailto:jonathan.rajotte- > jul...@efficios.com> <mailto:jonathan.rajotte-jul...@efficios.com jonathan.rajotte-jul...@efficios.com>>> wrote: > > > > > > On Tue, Sep 19, 2017 at 03:53:27PM +0800, liguang li wrote: > > > >Hi, > > > >On Mon, Sep 18, 2017 at 11:18 PM, Jonathan Rajotte-Julien > > > ><[1]jonathan.rajotte-jul...@efficios.com jonathan.rajotte-jul...@efficios.com> <mailto:jonathan.rajotte- > jul...@efficios.com <mailto:jonathan.rajotte-jul...@efficios.com>>> wrote: > > > > > > > > Hi, > > > > On Mon, Sep 18, 2017 at 11:32:07AM +0800, liguang li > wrote: > > > > >Hi, > > > > > > > > > >Create a session in live-reading mode, run a > application which > > > > having very > > > > >high event throughput, then prints > > > > >the events with babeltrace. We found the live > trace viewer are > > > > viewing > > > > >events a few seconds ago, and as time > > > > > > > > Could you provide us the version used for babeltrace, > lttng-tools and > > > > lttng-ust? > > > > > > > > Babeltrace: 1.5.1 > > > > > > Update to babeltrace 1.5.3. > > > > > > > Lttng-tools: 2.8.6 > > > > > > Update to lttng-tools 2.8.8 > > > > > > > Lttng-ust: 2.8.2 > > > > > > > > >goes on, the delay will be bigger and bigger. > > > > > > > > A similar issues was observed a couple months ago, > which implicated > > > > multiple delayed ack > > > > problems during communication between lttng-relayd and > babeltrace. > > > > > > > > The following fixes were merged: > > > > > > > > [1] > > > > [2]https://github.com/lttng/lttng-tools/commit/ > b6025e9476332b75eb8184345c3eb3e924780088 <https://github.com/lttng/ > lttng-tools/commit/b6025e9476332b75eb8184345c3eb3e924780088> < > https://github.com/lttng/lttng-tools/commit/b6025e9476332b75eb8184345c3eb3 > e924780088 <https://github.com/lttng/lttng-tools/commit/ > b6025e9476332b75eb8184345c3eb3e924780088>> > > > > [2] > > > > [3]https://github.com/efficios/babeltrace/commit/ > de417d04317ca3bc30f59685a9d19de670e4b11d <https://github.com/efficios/ > babeltrace/commit/de417d04317ca3bc30f59685a9d19de670e4b11d> < > https://github.com/efficios/babeltrace/commit/ > de417d04317ca3bc30f59685a9d19de670e4b11d <https://github.com/efficios/ > babeltrace/commit/de417d04317ca3bc30f59685a9d19de670e4b11d>> > > > > [3] > > > > [4]https://github.com/efficios/babeltrace/commit/ > 4594dbd8f7c2af2446a3e310bee74ba4a2e9d648 <https://github.com/efficios/ > babeltrace/commit/4594dbd8f7c2af2446a3e310bee74ba4a2e9d648> < > https://github.com/efficios/babeltrace/commit/ > 4594dbd8f7c2af2446a3e310bee74ba4a2e9d648 <https://github.com/efficios/ > babeltrace/commit/4594dbd8f7c2af2446a3e310bee74ba4a2e9d648>> > > > > > > > > In the event that you are already using an updated > version of babeltrace > > > > and > > > > lttng-tools, it would be pertinent to provide us with a > simple > > > > reproducer so we > > > > can assess the issue. > > > > > > The version you are using does not include the mentioned > fixes. Please update > > > and redo
[lttng-dev] [PATCH lttng-tools] Fix: lttng-consumerd crash due to double free metadata stream
When setup metadata failed, the exception handling function will free
the metadata stream twice.
Signed-off-by: Liguang Li <liguang...@windriver.com>
---
src/common/ust-consumer/ust-consumer.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/src/common/ust-consumer/ust-consumer.c
b/src/common/ust-consumer/ust-consumer.c
index 366f855..3836ef9 100644
--- a/src/common/ust-consumer/ust-consumer.c
+++ b/src/common/ust-consumer/ust-consumer.c
@@ -234,6 +234,8 @@ static int send_stream_to_thread(struct
lttng_consumer_stream *stream,
ERR("Consumer write %s stream to pipe %d",
stream->metadata_flag ? "metadata" : "data",
lttng_pipe_get_writefd(stream_pipe));
+ /* Remove node from the channel stream list. */
+ cds_list_del(>send_node);
if (stream->metadata_flag) {
consumer_del_stream_for_metadata(stream);
} else {
@@ -721,8 +723,6 @@ static int send_streams_to_thread(struct
lttng_consumer_channel *channel,
* If we are unable to send the stream to the thread,
there is
* a big problem so just stop everything.
*/
- /* Remove node from the channel stream list. */
- cds_list_del(>send_node);
goto error;
}
@@ -925,7 +925,7 @@ static int setup_metadata(struct lttng_consumer_local_data
*ctx, uint64_t key)
* a big problem so just stop everything.
*/
ret = LTTCOMM_CONSUMERD_FATAL;
- goto error;
+ goto end;
}
/* List MUST be empty after or else it could be reused. */
assert(cds_list_empty(>streams.head));
@@ -940,8 +940,14 @@ error:
* the stream is still in the local stream list of the channel. This
call
* will make sure to clean that list.
*/
- consumer_stream_destroy(metadata->metadata_stream, NULL);
cds_list_del(>metadata_stream->send_node);
+
+ /* Destroy tracer buffers of the stream. */
+ consumer_stream_destroy_buffers(metadata->metadata_stream);
+ /* Close down everything including the relayd if one. */
+ consumer_stream_close(metadata->metadata_stream);
+
+ consumer_stream_destroy(metadata->metadata_stream, NULL);
metadata->metadata_stream = NULL;
error_no_stream:
end:
--
2.7.4
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
Re: [lttng-dev] Babeltrace performance issue in live-reading mode
Hi, On Wed, Sep 20, 2017 at 10:58 PM, Jonathan Rajotte Julien < jonathan.rajotte-jul...@efficios.com> wrote: > Hi, > > On 2017-09-20 05:12 AM, liguang li wrote: > > > > > > On Tue, Sep 19, 2017 at 10:57 PM, Jonathan Rajotte-Julien < > jonathan.rajotte-jul...@efficios.com <mailto:jonathan.rajotte- > jul...@efficios.com>> wrote: > > > > On Tue, Sep 19, 2017 at 03:53:27PM +0800, liguang li wrote: > > >Hi, > > >On Mon, Sep 18, 2017 at 11:18 PM, Jonathan Rajotte-Julien > > ><[1]jonathan.rajotte-jul...@efficios.com jonathan.rajotte-jul...@efficios.com>> wrote: > > > > > > Hi, > > > On Mon, Sep 18, 2017 at 11:32:07AM +0800, liguang li wrote: > > > >Hi, > > > > > > > >Create a session in live-reading mode, run a application > which > > > having very > > > >high event throughput, then prints > > > >the events with babeltrace. We found the live trace > viewer are > > > viewing > > > >events a few seconds ago, and as time > > > > > > Could you provide us the version used for babeltrace, > lttng-tools and > > > lttng-ust? > > > > > > Babeltrace: 1.5.1 > > > > Update to babeltrace 1.5.3. > > > > > Lttng-tools: 2.8.6 > > > > Update to lttng-tools 2.8.8 > > > > > Lttng-ust: 2.8.2 > > > > > > >goes on, the delay will be bigger and bigger. > > > > > > A similar issues was observed a couple months ago, which > implicated > > > multiple delayed ack > > > problems during communication between lttng-relayd and > babeltrace. > > > > > > The following fixes were merged: > > > > > > [1] > > > [2]https://github.com/lttng/lttng-tools/commit/ > b6025e9476332b75eb8184345c3eb3e924780088 <https://github.com/lttng/ > lttng-tools/commit/b6025e9476332b75eb8184345c3eb3e924780088> > > > [2] > > > [3]https://github.com/efficios/babeltrace/commit/ > de417d04317ca3bc30f59685a9d19de670e4b11d <https://github.com/efficios/ > babeltrace/commit/de417d04317ca3bc30f59685a9d19de670e4b11d> > > > [3] > > > [4]https://github.com/efficios/babeltrace/commit/ > 4594dbd8f7c2af2446a3e310bee74ba4a2e9d648 <https://github.com/efficios/ > babeltrace/commit/4594dbd8f7c2af2446a3e310bee74ba4a2e9d648> > > > > > > In the event that you are already using an updated version of > babeltrace > > > and > > > lttng-tools, it would be pertinent to provide us with a simple > > > reproducer so we > > > can assess the issue. > > > > The version you are using does not include the mentioned fixes. > Please update > > and redo your experiment. > > > > > > Test this issue in the version you have listed, the issue still exists. > > Given that previous versions had a major timing problem there I would > expect to have some improvement. > > In that case, we will need a lot more information on your benchmarking > strategy. > We will need a simple reproducer, your benchmark code (r,gnuplot etc.), > your overall methodology > to be able to reproduce the issue locally. Otherwise, it will be very hard > to come to any conclusion. > > Sorry, we can not provide the detailed information about the benchmark code due to the company regulations. > > > > > > Cheers > > > > > > > > > > > Steps: > > > lttng create session --live -U net://* > > > lttng enable-channel -s session -u ch1 > > > lttng enable-event -s session -c ch1 -u -a > > > lttng start > > > > > > Run a high event throughput application, which is multithreaded > > >application> > > > > In the multithreaded application, each tracepoint will have the wall > > time of the system,then we can easily reproduce this issue through > > comparing the time of recorded event and the system wall time. > > > > > > > babeltrace -i lttng-live net://* > > > > > > After a while, we found the timestamp of the event in the > babeltrace is > > >different with the time in
Re: [lttng-dev] Babeltrace performance issue in live-reading mode
On Tue, Sep 19, 2017 at 10:57 PM, Jonathan Rajotte-Julien < jonathan.rajotte-jul...@efficios.com> wrote: > On Tue, Sep 19, 2017 at 03:53:27PM +0800, liguang li wrote: > >Hi, > >On Mon, Sep 18, 2017 at 11:18 PM, Jonathan Rajotte-Julien > ><[1]jonathan.rajotte-jul...@efficios.com> wrote: > > > > Hi, > > On Mon, Sep 18, 2017 at 11:32:07AM +0800, liguang li wrote: > > >Hi, > > > > > >Create a session in live-reading mode, run a application which > > having very > > >high event throughput, then prints > > >the events with babeltrace. We found the live trace viewer are > > viewing > > >events a few seconds ago, and as time > > > > Could you provide us the version used for babeltrace, lttng-tools > and > > lttng-ust? > > > > Babeltrace: 1.5.1 > > Update to babeltrace 1.5.3. > > > Lttng-tools: 2.8.6 > > Update to lttng-tools 2.8.8 > > > Lttng-ust: 2.8.2 > > > > >goes on, the delay will be bigger and bigger. > > > > A similar issues was observed a couple months ago, which implicated > > multiple delayed ack > > problems during communication between lttng-relayd and babeltrace. > > > > The following fixes were merged: > > > > [1] > > [2]https://github.com/lttng/lttng-tools/commit/ > b6025e9476332b75eb8184345c3eb3e924780088 > > [2] > > [3]https://github.com/efficios/babeltrace/commit/ > de417d04317ca3bc30f59685a9d19de670e4b11d > > [3] > > [4]https://github.com/efficios/babeltrace/commit/ > 4594dbd8f7c2af2446a3e310bee74ba4a2e9d648 > > > > In the event that you are already using an updated version of > babeltrace > > and > > lttng-tools, it would be pertinent to provide us with a simple > > reproducer so we > > can assess the issue. > > The version you are using does not include the mentioned fixes. Please > update > and redo your experiment. > > Test this issue in the version you have listed, the issue still exists. > Cheers > > > > > > > Steps: > > lttng create session --live -U net://* > > lttng enable-channel -s session -u ch1 > > lttng enable-event -s session -c ch1 -u -a > > lttng start > > > > Run a high event throughput application, which is multithreaded > >application. > In the multithreaded application, each tracepoint will have the wall time of the system,then we can easily reproduce this issue through comparing the time of recorded event and the system wall time. > > babeltrace -i lttng-live net://* > > > > After a while, we found the timestamp of the event in the babeltrace > is > >different with the time in host > > which run the application. And the delay will be bigger and bigger > with > >time goes. > > > > > > Cheers > > >I checked the source code, found Babeltrace in live-reading > mode > > will read > > >the recorded events in the CTF > > >files, and then parse and print it in a single thread. The > process > > is a > > >little slow, do you have any ideas to > > >improve the process. > >From my understanding of the source code, the process of parse and print event will consume a lot of time. For example, the multithreaded application will consume 3 CPUs, in a specified time,3 subbuffers will be filled and sent to lttng-relayd daemon, recorded into the CTF files. If in the specified time, babeltrace only handled 2 subbuffers' event, thenthe issue will happens. > > >Thanks, > > >Liguang > > > > > ___ > > > lttng-dev mailing list > > > [5]lttng-dev@lists.lttng.org > > > [6]https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev > > > > -- > > Jonathan Rajotte-Julien > > EfficiOS > > > > References > > > >Visible links > >1. mailto:jonathan.rajotte-jul...@efficios.com > >2. https://github.com/lttng/lttng-tools/commit/ > b6025e9476332b75eb8184345c3eb3e924780088 > >3. https://github.com/efficios/babeltrace/commit/ > de417d04317ca3bc30f59685a9d19de670e4b11d > >4. https://github.com/efficios/babeltrace/commit/ > 4594dbd8f7c2af2446a3e310bee74ba4a2e9d648 > >5. mailto:lttng-dev@lists.lttng.org > >6. https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev > > -- > Jonathan Rajotte-Julien > EfficiOS > ___ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
[lttng-dev] Missing discarded events message in live-reading mode
Hi,
Babeltrace in live mode is not displaying the discarded events message. But
on CTF traces the discarded events message will be printed on stderr.
Why? Is there any restriction?
I added the following patch into the ctf_live_packet_seek() function, and
found
it works well. Is there any side effect?
diff --git a/formats/lttng-live/lttng-live-comm.c
b/formats/lttng-live/lttng-live-comm.c
index a1c95bb..dc14bf5 100644
--- a/formats/lttng-live/lttng-live-comm.c
+++ b/formats/lttng-live/lttng-live-comm.c
@@ -1297,6 +1297,11 @@ retry:
ctf_update_current_packet_index(_stream->parent,
prev_index, cur_index);
+ if
((_stream->parent)->stream_class->trace->parent.collection) {
+ ctf_print_discarded_lost(stderr,
_stream->parent);
+ }
+
+
file_stream->parent.cycles_timestamp =
cur_index->ts_cycles.timestamp_begin;
file_stream->parent.real_timestamp =
...
Regards,
Liguang
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
Re: [lttng-dev] Babeltrace performance issue in live-reading mode
Hi, On Mon, Sep 18, 2017 at 11:18 PM, Jonathan Rajotte-Julien < jonathan.rajotte-jul...@efficios.com> wrote: > Hi, > > On Mon, Sep 18, 2017 at 11:32:07AM +0800, liguang li wrote: > >Hi, > > > >Create a session in live-reading mode, run a application which having > very > >high event throughput, then prints > >the events with babeltrace. We found the live trace viewer are viewing > >events a few seconds ago, and as time > > Could you provide us the version used for babeltrace, lttng-tools and > lttng-ust? > Babeltrace: 1.5.1 Lttng-tools: 2.8.6 Lttng-ust: 2.8.2 >goes on, the delay will be bigger and bigger. > > A similar issues was observed a couple months ago, which implicated > multiple delayed ack > problems during communication between lttng-relayd and babeltrace. > > The following fixes were merged: > > [1] https://github.com/lttng/lttng-tools/commit/ > b6025e9476332b75eb8184345c3eb3e924780088 > [2] https://github.com/efficios/babeltrace/commit/ > de417d04317ca3bc30f59685a9d19de670e4b11d > [3] https://github.com/efficios/babeltrace/commit/ > 4594dbd8f7c2af2446a3e310bee74ba4a2e9d648 > > In the event that you are already using an updated version of babeltrace > and > lttng-tools, it would be pertinent to provide us with a simple reproducer > so we > can assess the issue. > > Steps: lttng create session --live -U net://* lttng enable-channel -s session -u ch1 lttng enable-event -s session -c ch1 -u -a lttng start Run a high event throughput application, which is multithreaded application. babeltrace -i lttng-live net://* After a while, we found the timestamp of the event in the babeltrace is different with the time in host which run the application. And the delay will be bigger and bigger with time goes. > Cheers > > >I checked the source code, found Babeltrace in live-reading mode will > read > >the recorded events in the CTF > >files, and then parse and print it in a single thread. The process is > a > >little slow, do you have any ideas to > >improve the process. > >Thanks, > >Liguang > > > ___ > > lttng-dev mailing list > > lttng-dev@lists.lttng.org > > https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev > > > -- > Jonathan Rajotte-Julien > EfficiOS > ___ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
[lttng-dev] Babeltrace performance issue in live-reading mode
Hi, Create a session in live-reading mode, run a application which having very high event throughput, then prints the events with babeltrace. We found the live trace viewer are viewing events a few seconds ago, and as time goes on, the delay will be bigger and bigger. I checked the source code, found Babeltrace in live-reading mode will read the recorded events in the CTF files, and then parse and print it in a single thread. The process is a little slow, do you have any ideas to improve the process. Thanks, Liguang ___ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
[lttng-dev] [PATCH lttng-ust] Fix: Expand the shmobj size for the sequence number
This patch fixes a bug which was introduced by:
1ff31389b ("Generate and export the sequence number")
Signed-off-by: Liguang Li <liguang...@windriver.com>
---
libringbuffer/ring_buffer_backend.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/libringbuffer/ring_buffer_backend.c
b/libringbuffer/ring_buffer_backend.c
index 8eafc51..72c4910 100644
--- a/libringbuffer/ring_buffer_backend.c
+++ b/libringbuffer/ring_buffer_backend.c
@@ -119,7 +119,7 @@ int lib_ring_buffer_backend_allocate(const struct
lttng_ust_lib_ring_buffer_conf
bufb->buf_rsb.id = subbuffer_id(config, 0, 1, 0);
/* Allocate subbuffer packet counter table */
- align_shm(shmobj, __alignof__(struct
lttng_ust_lib_ring_buffer_backend_subbuffer));
+ align_shm(shmobj, __alignof__(struct
lttng_ust_lib_ring_buffer_backend_counts));
set_shmp(bufb->buf_cnt, zalloc_shm(shmobj,
sizeof(struct
lttng_ust_lib_ring_buffer_backend_counts)
* num_subbuf));
@@ -334,6 +334,8 @@ int channel_backend_init(struct channel_backend *chanb,
shmsize += sizeof(struct lttng_ust_lib_ring_buffer_backend_pages) *
num_subbuf_alloc;
shmsize += offset_align(shmsize, __alignof__(struct
lttng_ust_lib_ring_buffer_backend_subbuffer));
shmsize += sizeof(struct lttng_ust_lib_ring_buffer_backend_subbuffer) *
num_subbuf;
+ shmsize += offset_align(shmsize, __alignof__(struct
lttng_ust_lib_ring_buffer_backend_counts));
+ shmsize += sizeof(struct lttng_ust_lib_ring_buffer_backend_counts) *
num_subbuf;
/* Per-cpu buffer size: control (after backend) */
shmsize += offset_align(shmsize, __alignof__(struct
commit_counters_hot));
shmsize += sizeof(struct commit_counters_hot) * num_subbuf;
--
2.7.4
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
[lttng-dev] Babeltrace bug in lttng-live mode
Hi, A babeltrace BUG is found in the lttng-live mode, after analyze the backtrace and the source code, i found this issue maybe a defect of design. The reproduce steps is as following: #cat test.sh #!/bin/sh lttng -n create session --live 100 -U net://localhost/ lttng enable-channel channel0 -u --buffers-uid -C 1024k -W 1 lttng enable-event -u --channel channel0 -a babeltrace --clock-date --no-delta -i lttng-live net://localhost/host/localhost/session & sleep 2 lttng start sleep 2 sample_1 & # First application sleep 0.5 sample_2 & # Second application I checked the source code and found the issue happens in the following workflow. lttng_live_read add_traces add_one_trace--- (2) bt_context_add_trace ctf_open_mmap_trace ctf_open_mmap_trace_read ctf_open_mmap_stream_read prepare_mmap_stream_definition packet_seek(ctf_live_packet_seek) get_next_index append_metadata ctf_append_trace_metadata --- (1) In (1), the first argument of the function ctf_append_trace_metadata is invalid, because the viewer_stream->ctf_trace->handle is NULL now. The ctf_trace->handle variable is assigned in (2) after the following work is done. A fix patch is found in the mail list, but after applied this patch, we found the new metadata info can't be updated, the event id can not be found in array. The patch link: https://lists.lttng.org/pipermail/lttng-dev/2015-August/024891.html How to fix this issue, any ideas? Regards & Thanks Liguang ___ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
Re: [lttng-dev] [PATCH] Fix: truncate the metadata file in shm-path
Hi Jérémie,
Thanks for your review, i agree with your modification.
Regards,
Liguang
On 11/29/2016 06:00 AM, Jérémie Galarneau wrote:
Hi Liguang,
Good catch, thanks for the fix!
I have slightly modified the patch prior to merging it, read on.
Jérémie
On 28 November 2016 at 03:37, Liguang Li <liguang...@windriver.com> wrote:
In the shm-path mode, the metadata will be backuped to a metadata file,
when run the lttng command "lttng metadata regenerate" to resample the
wall time following a major NTP correction, the metadata file will not
be truncated and regenerated.
Add the function ust_metadata_truncate() to truncate and regenerate the
metadata file.
Signed-off-by: Liguang Li <liguang...@windriver.com>
---
src/bin/lttng-sessiond/cmd.c | 28
1 file changed, 28 insertions(+)
diff --git a/src/bin/lttng-sessiond/cmd.c b/src/bin/lttng-sessiond/cmd.c
index 325ffd2..ba83226 100644
--- a/src/bin/lttng-sessiond/cmd.c
+++ b/src/bin/lttng-sessiond/cmd.c
@@ -3378,6 +3378,25 @@ end:
}
static
+int ust_metadata_truncate(int fd, size_t length)
Changed the name of this function to clear_metadata_file(...) which
only takes an "fd" as parameter. There are no other users of this
utility yet, so I'm keeping it specific to its current use.
+{
+ int ret;
+
+ ret = lseek(fd, length, SEEK_SET);
length replaced by 0
+ if (ret < 0) {
+ PERROR("lseek");
+ goto out;
+ }
+
+ ret = ftruncate(fd, length);
length replaced by 0
+ if (ret < 0)
+ PERROR("ftruncate");
We use curly-braces even on single-line conditionals in this codebase.
+
+out:
Changed the "out" label to "end" to remain consistent with the rest of the code.
+ return ret;
+}
+
+static
int ust_regenerate_metadata(struct ltt_ust_session *usess)
{
int ret = 0;
@@ -3398,6 +3417,15 @@ int ust_regenerate_metadata(struct ltt_ust_session
*usess)
memset(registry->metadata, 0, registry->metadata_alloc_len);
registry->metadata_len = 0;
registry->metadata_version++;
+ /*truncate the metadata file*/
+ if (registry->metadata_fd > 0) {
+ ret = ust_metadata_truncate(registry->metadata_fd, 0);
+ if (ret) {
+ pthread_mutex_unlock(>lock);
+ goto end;
+ }
+ }
+
ret = ust_metadata_session_statedump(registry, NULL,
registry->major, registry->minor);
if (ret) {
--
2.7.4
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
[lttng-dev] [PATCH] Fix: truncate the metadata file in shm-path
In the shm-path mode, the metadata will be backuped to a metadata file,
when run the lttng command "lttng metadata regenerate" to resample the
wall time following a major NTP correction, the metadata file will not
be truncated and regenerated.
Add the function ust_metadata_truncate() to truncate and regenerate the
metadata file.
Signed-off-by: Liguang Li <liguang...@windriver.com>
---
src/bin/lttng-sessiond/cmd.c | 28
1 file changed, 28 insertions(+)
diff --git a/src/bin/lttng-sessiond/cmd.c b/src/bin/lttng-sessiond/cmd.c
index 325ffd2..ba83226 100644
--- a/src/bin/lttng-sessiond/cmd.c
+++ b/src/bin/lttng-sessiond/cmd.c
@@ -3378,6 +3378,25 @@ end:
}
static
+int ust_metadata_truncate(int fd, size_t length)
+{
+ int ret;
+
+ ret = lseek(fd, length, SEEK_SET);
+ if (ret < 0) {
+ PERROR("lseek");
+ goto out;
+ }
+
+ ret = ftruncate(fd, length);
+ if (ret < 0)
+ PERROR("ftruncate");
+
+out:
+ return ret;
+}
+
+static
int ust_regenerate_metadata(struct ltt_ust_session *usess)
{
int ret = 0;
@@ -3398,6 +3417,15 @@ int ust_regenerate_metadata(struct ltt_ust_session
*usess)
memset(registry->metadata, 0, registry->metadata_alloc_len);
registry->metadata_len = 0;
registry->metadata_version++;
+ /*truncate the metadata file*/
+ if (registry->metadata_fd > 0) {
+ ret = ust_metadata_truncate(registry->metadata_fd, 0);
+ if (ret) {
+ pthread_mutex_unlock(>lock);
+ goto end;
+ }
+ }
+
ret = ust_metadata_session_statedump(registry, NULL,
registry->major, registry->minor);
if (ret) {
--
2.7.4
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
