{"payload":{"feedbackUrl":"https://github.com/orgs/community/discussions/53140","repo":{"id":18915743,"defaultBranch":"master","name":"lttng-tools","ownerLogin":"lttng","currentUserCanPush":false,"isFork":false,"isEmpty":false,"createdAt":"2014-04-18T14:45:45.000Z","ownerAvatar":"https://avatars.githubusercontent.com/u/7333024?v=4","public":true,"private":false,"isOrgOwned":true},"refInfo":{"name":"","listCacheKey":"v0:1712344279.0","currentOid":""},"activityList":{"items":[{"before":"a6df2497a5c3d9b46b049d6fa0b2fd8a1965cf8a","after":"fc67b8bfaeeff5f8355fb336df75651de1963ccf","ref":"refs/heads/master","pushedAt":"2024-05-13T18:42:28.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"jgalar","name":"Jérémie Galarneau","path":"/jgalar","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1395184?s=80&v=4"},"commit":{"message":".gitignore: ignore local vscode workspace settings file\n\nSigned-off-by: Jérémie Galarneau \nChange-Id: I518d85077566ab341acb4644d27132ade79b5749","shortMessageHtmlLink":".gitignore: ignore local vscode workspace settings file"}},{"before":"f59edc7cf8bfcf1450ce2d9e649f70c1e6796da0","after":"a6df2497a5c3d9b46b049d6fa0b2fd8a1965cf8a","ref":"refs/heads/master","pushedAt":"2024-05-08T19:54:16.000Z","pushType":"push","commitsCount":2,"pusher":{"login":"jgalar","name":"Jérémie Galarneau","path":"/jgalar","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1395184?s=80&v=4"},"commit":{"message":"Import CStringView from the Babeltrace tree\n\nThe class is imported as of 1dcaf4b74 in the babeltrace tree. It is\nrenamed and reformated to fit the LTTng-tools conventions.\n\nNo changes in behaviour are intended.\n\nSigned-off-by: Jérémie Galarneau \nChange-Id: I8acc3833c52c4ac23a91af87157aade0b4bbb7c1","shortMessageHtmlLink":"Import CStringView from the Babeltrace tree"}},{"before":"6dee08cf205eb0c5f9edc37eeb5d10ad61abd0e1","after":"f59edc7cf8bfcf1450ce2d9e649f70c1e6796da0","ref":"refs/heads/master","pushedAt":"2024-05-02T16:08:45.000Z","pushType":"push","commitsCount":4,"pusher":{"login":"jgalar","name":"Jérémie Galarneau","path":"/jgalar","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1395184?s=80&v=4"},"commit":{"message":"Clean-up: modernize pretty_xml.cpp\n\nSince pretty_xml was converted to C++, clang-tidy had a number of\ngrievances such as the use of NULL (instead of nullptr).\n\nSince the file is very small, it is modernized to address those issues:\n - Wrap libxml2 resources in RAII wrappers\n - Use C++ IO APIs in lieu of fprintf\n\nSigned-off-by: Jérémie Galarneau \nChange-Id: Ie90e3e05130f7916f411e0de36e8aac72a0f790c","shortMessageHtmlLink":"Clean-up: modernize pretty_xml.cpp"}},{"before":"b9984811575702dea69108d180f5e90098709d13","after":"6dee08cf205eb0c5f9edc37eeb5d10ad61abd0e1","ref":"refs/heads/master","pushedAt":"2024-05-01T14:57:49.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"jgalar","name":"Jérémie Galarneau","path":"/jgalar","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1395184?s=80&v=4"},"commit":{"message":"fix: relayd: unaligned access in trace_chunk_registry_ht_key_hash\n\nIn 328c2fe7297c941aa9cbcfa4ce944fca1bd7300f, the type of 'lttng_uuid'\nwas changed from a C array of 16 'uint8_t' to a C++ std::array of the\nsame type and length.\n\nIn 'trace_chunk_registry_ht_key_hash()' we access these 16 bytes as 2\n'uint64_t', to do so we used to cast the array to '(uint64_t *)' and\nthen access index 0 and 1.\n\nWhen it was converted to C++, an error was introduced where instead we\nreinterpret_cast to 'const uint64_t *' the index 0 and 1 of the array\nwhich results in a 'uint64_t' pointer to the first and second bytes of\nthe array. These values overlap but since they are used as keys for an\nhash table it still works. However, on platforms that don't allow\nunaligned access, the second pointer being only offset by one byte\nresults in a 'Bus error'.\n\nReintroduce the old behavior by applying the index 0 and 1 to the\npointer resulting from the reinterpret_cast.\n\nChange-Id: I2bc287edbe6864a2a870f9de1f3b4dd8f8a90ace\nSigned-off-by: Michael Jeanson \nSigned-off-by: Jérémie Galarneau ","shortMessageHtmlLink":"fix: relayd: unaligned access in trace_chunk_registry_ht_key_hash"}},{"before":"8ab63dfb6a51460c9744828f7248d0fdca602ad3","after":"b9984811575702dea69108d180f5e90098709d13","ref":"refs/heads/master","pushedAt":"2024-04-30T19:36:48.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"jgalar","name":"Jérémie Galarneau","path":"/jgalar","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1395184?s=80&v=4"},"commit":{"message":"Clean-up: consumer.hpp: coding style indentation fix\n\nCaught this that slipped by when running ./format-cpp\n\nSigned-off-by: Jérémie Galarneau \nChange-Id: Ie16dc145d0776acba2ddcee31f2180b840112921","shortMessageHtmlLink":"Clean-up: consumer.hpp: coding style indentation fix"}},{"before":"a881d7c95fa9f6d47dbc89e9ddffbc2e950c05cb","after":"8ab63dfb6a51460c9744828f7248d0fdca602ad3","ref":"refs/heads/master","pushedAt":"2024-04-27T09:58:33.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"jgalar","name":"Jérémie Galarneau","path":"/jgalar","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1395184?s=80&v=4"},"commit":{"message":"Fix: syscall event rule: emission sites not compared in is_equal\n\nThe emission sites are not compared when comparing two kernel-syscall\nevent rules. This prevents users from subscribing to notifications of\ntriggers that use event-rule-matches syscall conditions which differ\nonly by their emission site (entry, exit, entry+exit).\n\nSigned-off-by: Jérémie Galarneau \nChange-Id: Id15eb682cd40f4966ca10911314ae7e8839712da","shortMessageHtmlLink":"Fix: syscall event rule: emission sites not compared in is_equal"}},{"before":"9a28bc04902b4a98d4f6ed613b27607c10ee5a3b","after":"a881d7c95fa9f6d47dbc89e9ddffbc2e950c05cb","ref":"refs/heads/master","pushedAt":"2024-04-25T20:58:19.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"jgalar","name":"Jérémie Galarneau","path":"/jgalar","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1395184?s=80&v=4"},"commit":{"message":"vscode: Add configurations to run the executables under the debugger\n\nAdd tasks.json and launch.json which allow VSCode users to build the\nproject and run the various binaries (lttng, lttng-relayd,\nlttng-sessiond) under the integrated debugger.\n\nFor the moment, the configuration assumes the user wants to build\n\"in-tree\" and has setup the tree to build the project (running\n./bootstrap and ./configure).\n\nThe build job attempts to build a compile database if 'bear' is\navailable on the system.\n\nTo debug the LTTng client, make sure to edit the matching configuration\nin .vscode/launch.json to provide your desired arguments (for the\nmoment, 'help' is passed by default).\n\nSigned-off-by: Jérémie Galarneau \nChange-Id: Iee6d6e012bef82f5d3df4296925a3669ad7027d6","shortMessageHtmlLink":"vscode: Add configurations to run the executables under the debugger"}},{"before":"bc13dc0f9eaa7742a589ce6d8faece4990f77f75","after":"9a28bc04902b4a98d4f6ed613b27607c10ee5a3b","ref":"refs/heads/master","pushedAt":"2024-04-24T20:37:05.000Z","pushType":"push","commitsCount":2,"pusher":{"login":"jgalar","name":"Jérémie Galarneau","path":"/jgalar","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1395184?s=80&v=4"},"commit":{"message":"Tests: Add test to check shared-memory FD leaks after relayd dies\n\nRefs: https://bugs.lttng.org/issues/1411\n\nChange-Id: I9804011320c28a9867af1fdc6a8d82ad0671fe3d\nSigned-off-by: Kienan Stewart \nSigned-off-by: Jérémie Galarneau ","shortMessageHtmlLink":"Tests: Add test to check shared-memory FD leaks after relayd dies"}},{"before":"048f01efd5931e364cc777d47c284c3f7d7d6ed6","after":"bc13dc0f9eaa7742a589ce6d8faece4990f77f75","ref":"refs/heads/master","pushedAt":"2024-04-10T20:32:01.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"jgalar","name":"Jérémie Galarneau","path":"/jgalar","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1395184?s=80&v=4"},"commit":{"message":"docs: Add supported versions and fix-backport policy\n\nChange-Id: Idb22c6487e2397b807c5d1b78acbc2adb03be363\nSigned-off-by: Kienan Stewart \nSigned-off-by: Jérémie Galarneau ","shortMessageHtmlLink":"docs: Add supported versions and fix-backport policy"}},{"before":"78f5b22de60c114c5c83410015a08bdd212edc0b","after":"048f01efd5931e364cc777d47c284c3f7d7d6ed6","ref":"refs/heads/master","pushedAt":"2024-04-09T20:45:33.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"jgalar","name":"Jérémie Galarneau","path":"/jgalar","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1395184?s=80&v=4"},"commit":{"message":"docs: Partially document the liblttng-ctl C API\n\nThis patch:\n\n1. Performs the required changes to make the build system able to build\n an HTML API documentation using Doxygen.\n\n The way it's done is a replica of what does the Babeltrace 2 project,\n which you may be familiar with.\n\n `doc/api` is for all API documentation projects while\n `doc/api/liblttng-ctl` is the specific liblttng-ctl API documentation\n project.\n\n To build and view the HTML API documentation:\n\n a) Configure the project with the `--enable-api-doc` option.\n\n b) Build and install the project.\n\n c) Open\n `$prefix/share/doc/lttng-tools/api/liblttng-ctl/html/index.html`,\n where `$prefix` is the installation prefix (for example,\n `/usr/local`).\n\n2. Fully documents some modules while not documenting others at all.\n\n Because some liblttng-ctl headers contain functions/types which\n conceptually belong to more than one module (unlike in Babeltrace 2),\n I decided to put all the Doxygen group (module) definitions and any\n \"extra\" module documentation in `dox/groups.dox`. The latter is a\n huge file of which most of the contents was copied from the\n LTTng-tools manual pages (and from the online LTTng Documentation)\n and adapted to the C API context.\n\n Images are direct copies from the LTTng Documentation.\n\n The complete module tree and its state, as of this patch, is as\n follows, where ✅ means it's fully documented and ❌ means it's not\n documented at all:\n\n ✅ Home page\n\n ✅ General API (error codes, session daemon connection,\n common definitions)\n\n Includes parts of `lttng.h`, `lttng-error.h`, and\n `constant.h`.\n\n ✅ Recording session API\n\n Includes parts of `lttng.h`, `channel.h`, `handle.h`,\n `domain.h`, and `session.h`.\n\n ✅ Recording session descriptor API\n\n Includes all `session-descriptor.h`.\n\n ✅ Recording session destruction handle API\n\n Includes all `destruction-handle.h`.\n\n ✅ Domain and channel API\n\n Includes parts of `channel.h`, `domain.h`, and `event.h`.\n\n ✅ Recording event rule API\n\n Includes parts of `event.h`.\n\n ❌ Process attribute inclusion set API\n\n Would include parts of `tracker.h`.\n\n ✅ Recording session clearing API\n\n Includes all `clear.h` and `clear-handle.h`.\n\n ❌ Recording session snapshot API\n\n Would include all `snapshot.h`.\n\n ❌ Recording session rotation API\n\n Would include all `rotation.h` and `location.h`.\n\n ❌ Recording session saving and loading API\n\n Would include all `save.h` and `load.h`.\n\n ✅ Instrumentation point listing API\n\n Includes parts of `event.h`.\n\n ❌ Trigger API\n\n Would include all `trigger/trigger.h`.\n\n ❌ Trigger condition API\n\n Would include all `condition/buffer-usage.h`,\n `condition/condition.h`, `condition/evaluation.h`,\n `condition/session-consumed-size.h`, and\n `condition/session-rotation.h`.\n\n ❌ \"Event rule matches\" trigger condition API\n\n Would include all `condition/event-rule-matches.h`.\n\n ❌ Event rule API\n\n Would include all headers in `event-rule` as well\n as all `kernel-probe.h` and `userspace-probe.h`.\n\n ❌ Log level rule API\n\n Would include all `log-level-rule.h`.\n\n ❌ Event expression API\n\n Would include all `event-expr.h`.\n\n ❌ Event field value API\n\n Would include all `event-field-value.h`.\n\n ❌ Trigger action API\n\n Would include all `action/action.h`,\n `action/firing-policy.h`, `action/list.h`, `action/path.h`,\n `action/rate-policy.h`, `action/rotate-session.h`,\n `action/snapshot-session.h`, `action/start-session.h`, and\n `action/stop-session.h`.\n\n ❌ Notify trigger action API\n\n Would include all `action/notify.h`,\n `notification/channel.h`, and\n `notification/notification.h`, as well as parts of\n `endpoint.h`.\n\n ❌ Error query API\n\n Would include all `error-query.h`.\n\n I'm voluntarily not documenting the health API (`health.h`), as I\n believe it's not super important for most users. We could document it\n on demand.\n\n In `groups.dox`, the groups of the undocumented modules are already\n defined, so that the complete tree above is visible in the rendered\n \"API reference\" section. The undocumented modules simply show the\n text \"To be done\". Because there are references to undocumented\n modules in `groups.dox` and in the documented headers, this means\n that the links at least resolve.\n\n Note that there are non-comment changes in `include/lttng`: I needed\n to name some anonymous, nested types so that I could reference their\n members, as you can only link to the member of a named type with\n Doxygen. For example, the type of the `u` union member of\n `struct lttng_event_context` is now `union lttng_event_context_u`;\n then you can reference its `probe` member as such:\n `lttng_event_context::lttng_event_context_u::probe` (_not_\n `lttng_event_context::u::probe`).\n\nSigned-off-by: Philippe Proulx \nSigned-off-by: Jérémie Galarneau \nChange-Id: I2783419159f4892a992fe5bc760b6e2cd6d13a60","shortMessageHtmlLink":"docs: Partially document the liblttng-ctl C API"}},{"before":"9fed015cbc40e9323cca8f22702eb17ba1d9c2f2","after":"78f5b22de60c114c5c83410015a08bdd212edc0b","ref":"refs/heads/master","pushedAt":"2024-04-09T17:18:58.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"jgalar","name":"Jérémie Galarneau","path":"/jgalar","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1395184?s=80&v=4"},"commit":{"message":"Fix: rotation-destroy-flush: fix session daemon abort if no kernel module present\n\nTesting rotation-destroy-flush when no lttng kernel modules present, it\nwould be failed with error message:\n\n Error: Unable to load required module lttng-ring-buffer-client-discard\n not ok 1 - Start session daemon\n Failed test 'Start session daemon'\n not ok 2 - Create session rotation_destroy_flush in -o /tmp/tmp.test_rot ...\n ...\n\nThis because test script that sets the LTTNG_ABORT_ON_ERROR environment\nvariable. It's this environment variable that causes the sessiond to\nhandle the kernel module loading failure as an abort rather than a\nwarning.\n\nUsing \"check_skip_kernel_test\" to detect whether the kernel module fails\nto load is expected or not. If the failure is expected, the script won't\nset that environment variable any more.\n\nFixes: 3a174400\n(\"tests:add check_skip_kernel_test to check root user and lttng kernel modules\")\n\nChange-Id: I371e9ba717613e2940186f710cf3cccd35baed6c\nSigned-off-by: Xiangyu Chen \nSigned-off-by: Jérémie Galarneau ","shortMessageHtmlLink":"Fix: rotation-destroy-flush: fix session daemon abort if no kernel mo…"}},{"before":"bd60b0dbd7eddccabefa8fee82156fcb2e2f2bef","after":"e6681c668131605c5ef9ab012f3357034e21e573","ref":"refs/heads/stable-2.13","pushedAt":"2024-04-05T19:11:19.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"jgalar","name":"Jérémie Galarneau","path":"/jgalar","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1395184?s=80&v=4"},"commit":{"message":"Update version to v2.13.13\n\nSigned-off-by: Jérémie Galarneau ","shortMessageHtmlLink":"Update version to v2.13.13"}},{"before":"2e435abd2c3e09706fab156e1f965deccbbc68d5","after":"4290fa20633867bd6e08ee2478dc7be93f1b0386","ref":"refs/heads/stable-2.12","pushedAt":"2024-04-05T19:01:57.000Z","pushType":"push","commitsCount":2,"pusher":{"login":"jgalar","name":"Jérémie Galarneau","path":"/jgalar","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1395184?s=80&v=4"},"commit":{"message":"Fix: consumerd: wrong timer mentioned in error logging\n\nAs its name indicates, consumer_timer_monitor_stop() stops the _monitor_\ntimer; not the live timer. This is most likely a copy-paste error.\n\nThe error logging is fixed to mention the appropriate timer.\n\nSigned-off-by: Jérémie Galarneau \nChange-Id: I9768408581fc6a06f47892850a3a91669df35188","shortMessageHtmlLink":"Fix: consumerd: wrong timer mentioned in error logging"}},{"before":"c0e55b9aa6c04ffffa8ca9a164b09e07df7f7a5d","after":"bd60b0dbd7eddccabefa8fee82156fcb2e2f2bef","ref":"refs/heads/stable-2.13","pushedAt":"2024-04-05T17:57:17.000Z","pushType":"push","commitsCount":3,"pusher":{"login":"jgalar","name":"Jérémie Galarneau","path":"/jgalar","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1395184?s=80&v=4"},"commit":{"message":"Fix: consumerd: leak of tracing buffers on relayd connectivity issue\n\nObserved issue\n==============\n\nA leak of the tracing buffers can be noticed when the relay daemon is\nterminated following the creation of a live session, but prior to the\ninitiation of any applications.\n\nThe issue can be reproduced with the following steps:\n # Create a live session\n $ lttng create --live\n\n # Kill the relay daemon before the allocation of the buffers\n $ killall lttng-relayd\n $ lttng enable-event --userspace --all\n $ lttng start\n\n # Launch an instrumented application\n $ ./my_app\n\n # Destroy all sessions\n $ lttng destroy --all\n\n # List the open file descriptors of the lttng-consumerd process\n # and notice how the tracing buffer are still visible.\n $ ls -lah /proc/$pid_of_lttng_consumerd/fd\n\n[...]\nlrwx------ 1 root root 64 Mar 19 19:50 987 -> '/dev/shm/shm-ust-consumer-358446 (deleted)'\nlrwx------ 1 root root 64 Mar 19 19:50 988 -> '/dev/shm/shm-ust-consumer-358446 (deleted)'\nlrwx------ 1 root root 64 Mar 19 19:50 989 -> '/dev/shm/shm-ust-consumer-358446 (deleted)'\n[...]\n\nCause\n=====\n\nThe consumer daemon allocates recording channels and their tracing\nbuffers in a two-step process.\n\nFirst, the session daemon emits an `ASK_CHANNEL_CREATION` command, which\nresults in the allocation of the internal consumer channel structures\nand of the actual tracing buffers. The channel's unique key is returned\nto the session daemon.\n\nAfter this command, the channel temporarily holds a list of streams\nwhich are waiting to be sent to the session and relay daemons as a\nresult of the `GET_CHANNEL` command.\n\nAt this moment, the channel's reference count is one over the number of\nstreams as they all hold a back-reference to their parent channel and\nthere is a global reference held by the session daemon.\n\nThe session daemon uses the key it received to emit the `GET_CHANNEL`\ncommand. When executing this command, the consumer daemon attempts to\nsend the streams to the relay daemon.\n\nOn failure to do so, the session daemon is informed of the connection\nerror. The consumer daemon then omits a step of the command: the streams\nare never handed-off from the channel's internal list to the\nconsumption/monitoring thread. This hand-off is what is internally\nreferred-to as making the streams \"globally visible\".\n\nThe session daemon, upon receiving the failure error code of the\nGET_CHANNEL command, tears down its internal ust_app channel structures.\nAs part of that process, it emits the `DESTROY_CHANNEL` command to\nreclaim the channel on the consumer daemon's end. This command is\ndeferred to the channel poll thread as the `CHANNEL_DEL`\ninternal command.\n\nAs part of this internal command, the channel poll thread cleans the\nchannel's stream list to clean-up any streams that are not \"globally\nvisible\": all of them, in our case.\n\nThen, the session daemon's global reference is released which should\nnormally result in the reclamation of the channel itself.\n\nWhile reproducing the problem, we noted that channel wasn't reclaimed\nand that its reference count matched the number of CPUs on the system at\nthe time the `CHANNEL_DEL` command completed.\n\nThis hinted at the streams holding a reference to the channel even after\nthe completion of the reclamation command.\n\nLooking at clean_channel_stream_list(), which cleans up the channel's\ntemporary stream list, we note that the streams' monitor property is\noverridden to `false` just before the call to consumer_stream_destroy().\n\nThis is strange and a comment (added as part of 212d67a2 in 2014) hints\nat a locking problem that was being worked-around. In all likelihood,\nthis no longer applies as the locking strategies used have evolved quite\na bit since then.\n\nStill, setting the monitor property to `false` is problematic as, in\nthat mode (say, channels that are used to record a snapshot), streams do\nnot hold a reference to their parent channel. This causes the clean-up\ncode to forego the clean-up of the channel, resulting in its leak.\n\nSince the channel ultimately owns the 'stream_fds' which represent the\nshared memory files, those files (and associated memory) are also leaked\n(they are closed during the execution of lttng_ustconsumer_del_channel()).\n\nSolution\n========\n\nWe simply remove the stream monitor mode override to leave it in its\nappropriate state. The clean-up then proceeds normally, ensuring the\ntracing buffers are properly reclaimed.\n\nKnown drawbacks\n===============\n\nNone.\n\nFixes #1411\n\nSigned-off-by: Jérémie Galarneau \nChange-Id: I9556cad5fd22cbbcba0a2d6716d46cd963c7778f","shortMessageHtmlLink":"Fix: consumerd: leak of tracing buffers on relayd connectivity issue"}},{"before":"c91ccadee5bfbc94a95540e17c879ce976caf6a2","after":"9fed015cbc40e9323cca8f22702eb17ba1d9c2f2","ref":"refs/heads/master","pushedAt":"2024-04-05T17:56:02.000Z","pushType":"push","commitsCount":2,"pusher":{"login":"jgalar","name":"Jérémie Galarneau","path":"/jgalar","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1395184?s=80&v=4"},"commit":{"message":"Fix: consumerd: wrong timer mentioned in error logging\n\nAs its name indicates, consumer_timer_monitor_stop() stops the _monitor_\ntimer; not the live timer. This is most likely a copy-paste error.\n\nThe error logging is fixed to mention the appropriate timer.\n\nChange-Id: I418580d8928752a0702d522e3ca74fe54cbe6f8f\nSigned-off-by: Jérémie Galarneau ","shortMessageHtmlLink":"Fix: consumerd: wrong timer mentioned in error logging"}},{"before":"7229988e2eb1a3574335b25328a400c48a8dcf76","after":"2e435abd2c3e09706fab156e1f965deccbbc68d5","ref":"refs/heads/stable-2.12","pushedAt":"2024-03-28T20:14:12.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"jgalar","name":"Jérémie Galarneau","path":"/jgalar","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1395184?s=80&v=4"},"commit":{"message":"Update version to v2.12.15\n\nSigned-off-by: Jérémie Galarneau ","shortMessageHtmlLink":"Update version to v2.12.15"}},{"before":"9ecc3a7b9a935e2c06e550f724fb8c67950711d1","after":"7229988e2eb1a3574335b25328a400c48a8dcf76","ref":"refs/heads/stable-2.12","pushedAt":"2024-03-28T20:09:54.000Z","pushType":"push","commitsCount":7,"pusher":{"login":"jgalar","name":"Jérémie Galarneau","path":"/jgalar","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1395184?s=80&v=4"},"commit":{"message":"Fix: baddr-statedump: use $(LIBTOOL) --mode=execute\n\nGNU libtool inconsistently places the compiled executable in the source\ndirectory or in the .libs directory where a libtool wrapper script is\nplaced in the source directory.\n\nWhile slibtool will always place the compiled executable in the .libs\ndirectory and a wrapper script in the source directory.\n\nThis will result with a build error when using slibtool since objcopy\nneeds the executable and not the shell wrapper script, but this can be\nsolved for both implementations by using $(LIBTOOL) --mode=execute on all\ncommands that operate on the libtool compiled executables.\n\nGentoo issue: https://bugs.gentoo.org/858095\n\nThe GNU libtool --mode=excute is documented upstream.\n\nhttps://www.gnu.org/software/libtool/manual/html_node/Execute-mode.html\nhttps://www.gnu.org/software/libtool/manual/html_node/Debugging-executables.html\n\nAnd the GNU libtool behavior of when to create a wrapper script is\ndocumented in the 'Linking Executables' section.\n\n \"Notice that the executable, hell, was actually created in the .libs\n subdirectory. Then, a wrapper script (or, on certain platforms, a\n wrapper executable see Wrapper executables) was created in the current\n directory.\n\n Since libtool created a wrapper script, you should use libtool to\n install it and debug it too. However, since the program does not depend\n on any uninstalled libtool library, it is probably usable even without\n the wrapper script.\"\n\nhttps://www.gnu.org/software/libtool/manual/html_node/Linking-executables.html\n\nAnd the inconsistency between GNU libtool and slibtool is documented at\nthe Gentoo wiki.\n\n \"One difference between GNU libtool and slibtool is that the former will\n conditionally place the compiled executable or a shell wrapper script in\n the build directory, depending on whether or not the executable depends\n on a build-local libtool library (e.g. libfoo.la). Where slibtool will\n always place a compatible wrapper script in the build directory where\n GNU libtool would have conditionally placed the executable. When the\n wrapper script is created both GNU libtool and slibtool will place the\n executable in the .libs directory within the build directory.\n Consequently build systems, ebuilds, and other users should take care to\n avoid scenarios like installing the wrapper script to the system instead\n of the executable. In these cases ideally the executable would be\n installed by the same libtool implementation that compiled it.\"\n\nhttps: //wiki.gentoo.org/wiki/Slibtool#Installing_or_using_binaries_created_by_libtool_manually\nSigned-off-by: orbea \nSigned-off-by: Jérémie Galarneau \nChange-Id: I03102ed78af835daa9b9a5836c2979a5f5d4bd8c","shortMessageHtmlLink":"Fix: baddr-statedump: use $(LIBTOOL) --mode=execute"}},{"before":"53f09728d515ea5475d4f0b38b11418bae3afe2c","after":"c0e55b9aa6c04ffffa8ca9a164b09e07df7f7a5d","ref":"refs/heads/stable-2.13","pushedAt":"2024-03-28T20:03:30.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"jgalar","name":"Jérémie Galarneau","path":"/jgalar","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1395184?s=80&v=4"},"commit":{"message":"Update version to v2.13.12\n\nSigned-off-by: Jérémie Galarneau ","shortMessageHtmlLink":"Update version to v2.13.12"}},{"before":"283c6fa6cc573166ec4e41b70a9db57f8356f4aa","after":"53f09728d515ea5475d4f0b38b11418bae3afe2c","ref":"refs/heads/stable-2.13","pushedAt":"2024-03-28T18:27:05.000Z","pushType":"push","commitsCount":7,"pusher":{"login":"jgalar","name":"Jérémie Galarneau","path":"/jgalar","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1395184?s=80&v=4"},"commit":{"message":"Fix: baddr-statedump: use $(LIBTOOL) --mode=execute\n\nGNU libtool inconsistently places the compiled executable in the source\ndirectory or in the .libs directory where a libtool wrapper script is\nplaced in the source directory.\n\nWhile slibtool will always place the compiled executable in the .libs\ndirectory and a wrapper script in the source directory.\n\nThis will result with a build error when using slibtool since objcopy\nneeds the executable and not the shell wrapper script, but this can be\nsolved for both implementations by using $(LIBTOOL) --mode=execute on all\ncommands that operate on the libtool compiled executables.\n\nGentoo issue: https://bugs.gentoo.org/858095\n\nThe GNU libtool --mode=excute is documented upstream.\n\nhttps://www.gnu.org/software/libtool/manual/html_node/Execute-mode.html\nhttps://www.gnu.org/software/libtool/manual/html_node/Debugging-executables.html\n\nAnd the GNU libtool behavior of when to create a wrapper script is\ndocumented in the 'Linking Executables' section.\n\n \"Notice that the executable, hell, was actually created in the .libs\n subdirectory. Then, a wrapper script (or, on certain platforms, a\n wrapper executable see Wrapper executables) was created in the current\n directory.\n\n Since libtool created a wrapper script, you should use libtool to\n install it and debug it too. However, since the program does not depend\n on any uninstalled libtool library, it is probably usable even without\n the wrapper script.\"\n\nhttps://www.gnu.org/software/libtool/manual/html_node/Linking-executables.html\n\nAnd the inconsistency between GNU libtool and slibtool is documented at\nthe Gentoo wiki.\n\n \"One difference between GNU libtool and slibtool is that the former will\n conditionally place the compiled executable or a shell wrapper script in\n the build directory, depending on whether or not the executable depends\n on a build-local libtool library (e.g. libfoo.la). Where slibtool will\n always place a compatible wrapper script in the build directory where\n GNU libtool would have conditionally placed the executable. When the\n wrapper script is created both GNU libtool and slibtool will place the\n executable in the .libs directory within the build directory.\n Consequently build systems, ebuilds, and other users should take care to\n avoid scenarios like installing the wrapper script to the system instead\n of the executable. In these cases ideally the executable would be\n installed by the same libtool implementation that compiled it.\"\n\nhttps: //wiki.gentoo.org/wiki/Slibtool#Installing_or_using_binaries_created_by_libtool_manually\nSigned-off-by: orbea \nSigned-off-by: Jérémie Galarneau \nChange-Id: I03102ed78af835daa9b9a5836c2979a5f5d4bd8c","shortMessageHtmlLink":"Fix: baddr-statedump: use $(LIBTOOL) --mode=execute"}},{"before":"77c8b540e0389c630764b6298ec71f81ed03c72d","after":"c91ccadee5bfbc94a95540e17c879ce976caf6a2","ref":"refs/heads/master","pushedAt":"2024-03-26T20:34:34.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"jgalar","name":"Jérémie Galarneau","path":"/jgalar","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1395184?s=80&v=4"},"commit":{"message":"scope-exit: Clarify scope_exit noexcept requirement\n\nSigned-off-by: Jérémie Galarneau \nChange-Id: Iec34c435327e63e046319fa12f78a74ec50f4163","shortMessageHtmlLink":"scope-exit: Clarify scope_exit noexcept requirement"}},{"before":"0729ea5558053d5a1a0d7aea51febf63ee1f3b3f","after":"77c8b540e0389c630764b6298ec71f81ed03c72d","ref":"refs/heads/master","pushedAt":"2024-03-25T14:37:15.000Z","pushType":"push","commitsCount":7,"pusher":{"login":"jgalar","name":"Jérémie Galarneau","path":"/jgalar","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1395184?s=80&v=4"},"commit":{"message":"Clean-up: lttng: utils: missing special member functions\n\nclang-tidy warns:\n warning: class 'session_list' defines a move constructor but does not define a destructor, a copy constructor, a copy assignment operator or a move assignment operator [cppcoreguidelines-special-member-functions]\n\nThis warning related to the \"Rule of Five\":\n\nIf a class requires a custom destructor, copy constructor, or copy\nassignment operator due to manual resource management, it likely needs\nto explicitly define all five (including move constructor and move\nassignment operator) to correctly manage the resources across all types\nof object copying and moving scenarios. This rule helps prevent resource\nleaks, double frees, and other common issues related to resource\nmanagement.\n\nSigned-off-by: Jérémie Galarneau \nChange-Id: I970cd1ab905eb877241f7e559b47349b9371f261","shortMessageHtmlLink":"Clean-up: lttng: utils: missing special member functions"}},{"before":"9cde3a4ab8b763df804f8105728d90f59521438b","after":"0729ea5558053d5a1a0d7aea51febf63ee1f3b3f","ref":"refs/heads/master","pushedAt":"2024-03-22T14:56:43.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"jgalar","name":"Jérémie Galarneau","path":"/jgalar","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1395184?s=80&v=4"},"commit":{"message":"Fix: lttng-destroy: string formating error when default session is unset\n\nUsing `lttng destroy` when no default session is set in .lttngrc results\nin the following print-out:\n\n Error: Can't find valid lttng config /root/lttng-build/home/.lttngrc\n Did you create a session? (lttng create )\n Error: Failed to format string: string pointer is null\n\nThis is because the client attempts to format the following message:\n ERR_FMT(\"Session `{}` not found\", spec.value);\n\nWhen no default session could be found in .lttngrc, spec.value is left\nat nullptr and it is assumed that the listing succeeded.\n\nA new CLI-specific exception, no_default_session_error, is added to the\nproject and thrown when the session listing fails. This allows the\ncalling code to mark the listing as having failed.\n\nSigned-off-by: Jérémie Galarneau \nChange-Id: I33b4f38a424f22dfa9d3628cf12441b59df53f12","shortMessageHtmlLink":"Fix: lttng-destroy: string formating error when default session is unset"}},{"before":"e1b89bf00b15f64523d24cf3e652cdc706d38843","after":"9cde3a4ab8b763df804f8105728d90f59521438b","ref":"refs/heads/master","pushedAt":"2024-03-22T14:53:36.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"jgalar","name":"Jérémie Galarneau","path":"/jgalar","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1395184?s=80&v=4"},"commit":{"message":"Revert \"Fix: lttng-destroy: string formating error when default session is unset\"\n\nThis reverts commit e8c353ad12851366573d9bfe45d333a9e9ff742d as it is\nmissing files (wrong revision of the change picked-up from gerrit).\n\nChange-Id: Ia426a8004d9827ee72ed39db52d7894f5d4eb34f\nSigned-off-by: Jérémie Galarneau ","shortMessageHtmlLink":"Revert \"Fix: lttng-destroy: string formating error when default sessi…"}},{"before":"bb1c9fc3f89c2faffb0228c0b77e32653e018a23","after":"e1b89bf00b15f64523d24cf3e652cdc706d38843","ref":"refs/heads/master","pushedAt":"2024-03-22T14:49:48.000Z","pushType":"push","commitsCount":5,"pusher":{"login":"jgalar","name":"Jérémie Galarneau","path":"/jgalar","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1395184?s=80&v=4"},"commit":{"message":"Fix: lttng-destroy: string formating error when default session is unset\n\nUsing `lttng destroy` when no default session is set in .lttngrc results\nin the following print-out:\n\n Error: Can't find valid lttng config /root/lttng-build/home/.lttngrc\n Did you create a session? (lttng create )\n Error: Failed to format string: string pointer is null\n\nThis is because the client attempts to format the following message:\n ERR_FMT(\"Session `{}` not found\", spec.value);\n\nWhen no default session could be found in .lttngrc, spec.value is left\nat nullptr and it is assumed that the listing succeeded.\n\nA new CLI-specific exception, no_default_session_error, is added to the\nproject and thrown when the session listing fails. This allows the\ncalling code to mark the listing as having failed.\n\nSigned-off-by: Jérémie Galarneau \nChange-Id: I33b4f38a424f22dfa9d3628cf12441b59df53f12","shortMessageHtmlLink":"Fix: lttng-destroy: string formating error when default session is unset"}},{"before":"79d885cf5420880fea7fc853944841a8762a8f01","after":"bb1c9fc3f89c2faffb0228c0b77e32653e018a23","ref":"refs/heads/master","pushedAt":"2024-03-18T19:08:21.000Z","pushType":"push","commitsCount":2,"pusher":{"login":"jgalar","name":"Jérémie Galarneau","path":"/jgalar","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1395184?s=80&v=4"},"commit":{"message":"Fix: baddr-statedump: use $(LIBTOOL) --mode=execute\n\nGNU libtool inconsistently places the compiled executable in the source\ndirectory or in the .libs directory where a libtool wrapper script is\nplaced in the source directory.\n\nWhile slibtool will always place the compiled executable in the .libs\ndirectory and a wrapper script in the source directory.\n\nThis will result with a build error when using slibtool since objcopy\nneeds the executable and not the shell wrapper script, but this can be\nsolved for both implementations by using $(LIBTOOL) --mode=execute on all\ncommands that operate on the libtool compiled executables.\n\nGentoo issue: https://bugs.gentoo.org/858095\n\nThe GNU libtool --mode=excute is documented upstream.\n\nhttps://www.gnu.org/software/libtool/manual/html_node/Execute-mode.html\nhttps://www.gnu.org/software/libtool/manual/html_node/Debugging-executables.html\n\nAnd the GNU libtool behavior of when to create a wrapper script is\ndocumented in the 'Linking Executables' section.\n\n \"Notice that the executable, hell, was actually created in the .libs\n subdirectory. Then, a wrapper script (or, on certain platforms, a\n wrapper executable see Wrapper executables) was created in the current\n directory.\n\n Since libtool created a wrapper script, you should use libtool to\n install it and debug it too. However, since the program does not depend\n on any uninstalled libtool library, it is probably usable even without\n the wrapper script.\"\n\nhttps://www.gnu.org/software/libtool/manual/html_node/Linking-executables.html\n\nAnd the inconsistency between GNU libtool and slibtool is documented at\nthe Gentoo wiki.\n\n \"One difference between GNU libtool and slibtool is that the former will\n conditionally place the compiled executable or a shell wrapper script in\n the build directory, depending on whether or not the executable depends\n on a build-local libtool library (e.g. libfoo.la). Where slibtool will\n always place a compatible wrapper script in the build directory where\n GNU libtool would have conditionally placed the executable. When the\n wrapper script is created both GNU libtool and slibtool will place the\n executable in the .libs directory within the build directory.\n Consequently build systems, ebuilds, and other users should take care to\n avoid scenarios like installing the wrapper script to the system instead\n of the executable. In these cases ideally the executable would be\n installed by the same libtool implementation that compiled it.\"\n\nhttps: //wiki.gentoo.org/wiki/Slibtool#Installing_or_using_binaries_created_by_libtool_manually\nSigned-off-by: orbea \nSigned-off-by: Jérémie Galarneau \nChange-Id: I03102ed78af835daa9b9a5836c2979a5f5d4bd8c","shortMessageHtmlLink":"Fix: baddr-statedump: use $(LIBTOOL) --mode=execute"}},{"before":"20c4b46aee1a984bc558b483826c1078f24d35e9","after":"79d885cf5420880fea7fc853944841a8762a8f01","ref":"refs/heads/master","pushedAt":"2024-03-18T15:12:12.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"jgalar","name":"Jérémie Galarneau","path":"/jgalar","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1395184?s=80&v=4"},"commit":{"message":"extras/zsh-completion/_lttng: add missing \"requires\" verb\n\nSigned-off-by: Philippe Proulx \nChange-Id: I9221a31e2a265e93b17242b152a00e8e1851cab7\nSigned-off-by: Jérémie Galarneau ","shortMessageHtmlLink":"extras/zsh-completion/_lttng: add missing \"requires\" verb"}},{"before":"283a96e49f066a4263726271bc64aa7e94ae0e92","after":"20c4b46aee1a984bc558b483826c1078f24d35e9","ref":"refs/heads/master","pushedAt":"2024-03-12T20:58:52.000Z","pushType":"push","commitsCount":2,"pusher":{"login":"jgalar","name":"Jérémie Galarneau","path":"/jgalar","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1395184?s=80&v=4"},"commit":{"message":"Clean-up: sessiond: use empty() instead of comparing size to 0\n\nHarmonize the project's coding style a little by favoring the use of the\n'empty()' methood of containers rather than comparing their size to 0.\n\nSigned-off-by: Jérémie Galarneau \nChange-Id: I22e6b7fe4d94d8f43362fe119b4ca6d480587291","shortMessageHtmlLink":"Clean-up: sessiond: use empty() instead of comparing size to 0"}},{"before":"d73aeddd1b4de7fadc7b6f6f5004c6298208602a","after":"283a96e49f066a4263726271bc64aa7e94ae0e92","ref":"refs/heads/master","pushedAt":"2024-03-12T17:24:21.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"jgalar","name":"Jérémie Galarneau","path":"/jgalar","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1395184?s=80&v=4"},"commit":{"message":"Fix: relayd: live client not notified of inactive streams\n\nObserved issue\n--------------\n\nSome LTTng-tools live tests failures appear to show babeltrace2\nhanging (failing to print expected events). The problem is intermittent,\nbut Kienan was able to develop a test case that's reproducible for him.\n\nThe test case performs the following steps:\n - Start a ust application and leave it running\n - Configure and then start an lttng live session\n - Connect a live viewer (babeltrace)\n - Run a second ust application\n - Wait for the expected number of events\n - In the failing case, no events are seen by babeltrace\n\nUsing per-uid buffers, the test typically completes normally. With\nper-pid buffers the test fails, hanging indefinitely if waiting for the\nspecified number of events. While \"hanging\", babeltrace2 is polling the\nrelayd.\n\nThis affects for babeltrace2 stable-2.0 and master while using\nlttng-tools master.\n\nFor more information, see the description of bug #1406[1]\n\nCause\n-----\n\nWhen consuming a live trace captured in per-PID mode, Babeltrace\nperiodically requests the index of the next packet it should consume.\n\nAs part of the reply, it gets a 'flags' field which is used to announce\nthat new streams, or new metadata, are available to the viewer.\nUnfortunately, these 'flags' are only set when the relay daemon has new\ntracing data to deliver. It is not set when the relay daemon indicates\nthat the stream is inactive (see LTTNG_VIEWER_INDEX_INACTIVE).\n\nIn the average case where an application is spawned while others are\nactively emiting events, a request for new data will result in a reply\nthat returns an index entry (code LTTNG_VIEWER_INDEX_OK) for an\navailable packet accompanied by the LTTNG_VIEWER_FLAG_NEW_STREAM flag.\n\nThis flag indicates to the viewer that it should request new\nstreams (using the LTTNG_VIEWER_GET_NEW_STREAMS live protocol command)\nbefore consuming the new data.\n\nIn the cases where we observe a hang, an application is running but not\nemiting new events. As such, the relay daemon periodically emits \"live\nbeacons\" to indicate that the session's streams are inactive up to a\ngiven time 'T'.\n\nSince the existing application remains inactive and the viewer is never\nnotified that new streams are available, the viewer effectively remains\n\"stuck\" and never notices the new application being traced.\n\nThe LTTNG_VIEWER_FLAG_NEW_METADATA communicates a similar semantic with\nregards to the metadata. However, ignoring it for inactive streams isn't\nas deleterious: the same information is made available to the viewer the\nnext time it will successfully request a new index to the relay daemon.\n\nThis would only become a problem if the tracers start to express\nnon-layout data (like supplemental environment information, but I don't\nsee a real use-case) as part of the metadata stream that should be made\navailable downstream even during periods of inactivity.\n\nNote that the same problem most likely affects the per-UID buffer\nallocation mode when multiple users are being traced.\n\nSolution\n--------\n\nOn the producer end, LTTNG_VIEWER_FLAG_NEW_STREAM is set even when\nreturning an inactivity index.\n\nNote that to preserve compatibility with older live consumers that don't\nexpect this flag in non-OK response, the LTTNG_VIEWER_FLAG_NEW_STREAM\nnotification is repeated until the next LTTNG_VIEWER_GET_NEW_STREAMS\ncommand that returns LTTNG_VIEWER_INDEX_OK.\n\nThe 'new_streams' state is no longer cleared from relay sessions during\nthe processing of the LTTNG_VIEWER_GET_NEXT_INDEX commands. Instead, it\nis cleared when the viewer requests new streams.\n\nOn Babeltrace's end, the handler of the LTTNG_VIEWER_GET_NEXT_INDEX\ncommand (lttng_live_get_next_index) is modified to expect\nLTTNG_VIEWER_FLAG_NEW_STREAM in the cases where the command returns:\n - LTTNG_VIEWER_INDEX_OK (as done previously),\n - LTTNG_VIEWER_INDEX_HUP (new),\n - LTTNG_VIEWER_INDEX_INACTIVE (new).\n\nDrawbacks\n---------\n\nThis is arguably a protocol change as none of the producers ever set the\nNEW_METADATA/NEW_STREAM flags when indicating an inactive stream.\n\nReferences\n----------\n\n[1] https://bugs.lttng.org/issues/1406\n\nFixes #1406\n\nChange-Id: I84f53f089597ac7b22ce8bd0962d4b28112b7ab6\nSigned-off-by: Jérémie Galarneau ","shortMessageHtmlLink":"Fix: relayd: live client not notified of inactive streams"}},{"before":"f506900f904887310c26a441ea86352fc27242c2","after":"d73aeddd1b4de7fadc7b6f6f5004c6298208602a","ref":"refs/heads/master","pushedAt":"2024-03-12T17:18:46.000Z","pushType":"push","commitsCount":6,"pusher":{"login":"jgalar","name":"Jérémie Galarneau","path":"/jgalar","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1395184?s=80&v=4"},"commit":{"message":"Clean-up: tests: bt2 plug-ins: modernize the plug-ins\n\nBy virtue of their use of the C Babeltrace 2 APIs, the test plug-ins\nperform a fair amount of manual resource management.\n\nTo make it possible to adopt a more modern C++ style in those plug-ins,\na number of helpers are introduced.\n\nIntroduce reference wrappers for the Babeltrace 2 interface:\n - value_ref: wraps a bt_value reference using std::unique_ptr\n - message_const_ref: wraps a constant message reference using a\n unique_ptr\n - message_iterator_ref: wraps a message iterator reference using a\n unique_ptr\n - event_class_const_ref: wraps a constant event class reference using\n a unique_ptr\n\nA specialized random_access_container_wrapper is specialized to wrap\nbt_value arrays of strings.\n\nIn doing so, it is possible to eliminate the use of gotos and manual\nreference management on error paths. Some struct/classes are renamed to\neliminate ambiguities that arose over the refactoring.\n\nThe changes allow some simplifications of the code flow in places which\nare applied directly.\n\nChange-Id: I25c148d7970cb89add55a86f2c162973d3d27e4a\nSigned-off-by: Jérémie Galarneau ","shortMessageHtmlLink":"Clean-up: tests: bt2 plug-ins: modernize the plug-ins"}},{"before":"f6fd58e865ae9918ca5c9b935c526140b1622f3c","after":"f506900f904887310c26a441ea86352fc27242c2","ref":"refs/heads/master","pushedAt":"2024-03-08T16:34:57.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"jgalar","name":"Jérémie Galarneau","path":"/jgalar","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1395184?s=80&v=4"},"commit":{"message":"tests: Split test_ust_constructor into several tests\n\nObserved issue\n==============\n\nTAP parsers fail when parsing a single executable that contains\nseveral plans. Eg.,\n\n```\nok 44 - Found no unexpected events\nPASS: ust/ust-constructor/test_ust_constructor.py 44 - Found no unexpected events\n\n1..44\nERROR: ust/ust-constructor/test_ust_constructor.py - multiple test plans\nok 1 - Create a session\nERROR: ust/ust-constructor/test_ust_constructor.py 1 - Create a session # UNPLANNED\n```\n\nand\n\n```\n14:03:23 org.tap4j.parser.ParserException: Error parsing TAP Stream: Duplicated TAP Plan found.\n14:03:23 \tat org.tap4j.parser.Tap13Parser.parseTapStream(Tap13Parser.java:257)\n14:03:23 \tat org.tap4j.parser.Tap13Parser.parseFile(Tap13Parser.java:231)\n14:03:23 \tat org.tap4j.plugin.TapParser.parse(TapParser.java:172)\n14:03:23 \tat org.tap4j.plugin.TapPublisher.loadResults(TapPublisher.java:475)\n14:03:23 \tat org.tap4j.plugin.TapPublisher.performImpl(TapPublisher.java:352)\n14:03:23 \tat org.tap4j.plugin.TapPublisher.perform(TapPublisher.java:312)\n14:03:23 \tat jenkins.tasks.SimpleBuildStep.perform(SimpleBuildStep.java:123)\n14:03:23 \tat hudson.tasks.BuildStepCompatibilityLayer.perform(BuildStepCompatibilityLayer.java:80)\n14:03:23 \tat hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20)\n14:03:23 \tat hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:818)\n14:03:23 \tat hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:767)\n14:03:23 \tat hudson.model.Build$BuildExecution.post2(Build.java:179)\n14:03:23 \tat hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:711)\n14:03:23 \tat hudson.model.Run.execute(Run.java:1918)\n14:03:23 \tat hudson.matrix.MatrixRun.run(MatrixRun.java:153)\n14:03:23 \tat hudson.model.ResourceController.execute(ResourceController.java:101)\n14:03:23 \tat hudson.model.Executor.run(Executor.java:442)\n14:03:23 Caused by: org.tap4j.parser.ParserException: Duplicated TAP Plan found.\n14:03:23 \tat org.tap4j.parser.Tap13Parser.parseLine(Tap13Parser.java:354)\n14:03:23 \tat org.tap4j.parser.Tap13Parser.parseTapStream(Tap13Parser.java:252)\n14:03:23 \t... 16 more\n```\n\nCause\n=====\n\n09a872ef0b4e1432329aa42fecc61f50e9baa367 introduced multiple plans in\nto test_ust_constructor\n\nSolution\n========\n\nSplit the script into several smaller test scripts sharing a common\nimport for data and the bulk of execution.\n\nKnown drawbacks\n===============\n\nNone.\n\nSigned-off-by: Kienan Stewart \nSigned-off-by: Jérémie Galarneau \nChange-Id: I81649d714afe0e325996b730d5c72cfd5b28d1f8","shortMessageHtmlLink":"tests: Split test_ust_constructor into several tests"}}],"hasNextPage":true,"hasPreviousPage":false,"activityType":"all","actor":null,"timePeriod":"all","sort":"DESC","perPage":30,"cursor":"djE6ks8AAAAESLmo_wA","startCursor":null,"endCursor":null}},"title":"Activity · lttng/lttng-tools"}