Bug #1381
openlttng list-triggers crashing with 2.13.9
0%
Description
This was discussed offline, but I am opening a ticket here for tracking purposes. With the latest 2.13.9 I'm seeing the following assert:
#0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44 #1 0x00007fb11ad09723 in __pthread_kill_internal (signo=6, threadid=<optimized out>) at pthread_kill.c:78 #2 0x00007fb11acbe876 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 #3 0x00007fb11aca97e3 in __GI_abort () at abort.c:79 #4 0x00007fb11aca9719 in __assert_fail_base (fmt=<optimized out>, assertion=<optimized out>, file=<optimized out>, line=<optimized out>, function=<optimized out>) at assert.c:92 #5 0x00007fb11acb78e6 in __GI___assert_fail (assertion=assertion@entry=0x475fd2 "element_index < array->size", file=file@entry=0x4832e8 "../../../lttng-tools-2.13.9/src/common/dynamic-array.h", line=line@entry=55, function=function@entry=0x498120 <__PRETTY_FUNCTION__.1> "lttng_dynamic_array_get_element") at assert.c:101 #6 0x0000000000469311 in lttng_dynamic_array_get_element (array=0x4b7f10, element_index=0) at ../../../lttng-tools-2.13.9/src/common/dynamic-array.h:55 #7 lttng_dynamic_array_get_element (element_index=0, array=0x4b7f10) at ../../../lttng-tools-2.13.9/src/common/dynamic-array.h:52 #8 lttng_action_path_copy (src=src@entry=0x4b7f10, dst=dst@entry=0x4b8250) at ../../../lttng-tools-2.13.9/src/common/actions/path.c:109 #9 0x000000000043595c in lttng_error_query_action_create (action_path=0x4b7f10, trigger=0x4b8240) at ../../../lttng-tools-2.13.9/src/common/error-query.c:230 #10 lttng_error_query_action_create (trigger=trigger@entry=0x4b5ea0, action_path=action_path@entry=0x4b7f10) at ../../../lttng-tools-2.13.9/src/common/error-query.c:206 #11 0x000000000042c62a in print_action_errors (action=<optimized out>, action_path_length=0, action_path_indexes=0x0, trigger=0x4b5ea0) at ../../../../lttng-tools-2.13.9/src/bin/lttng/commands/list_triggers.c:766 #12 print_one_action (trigger=0x4b5ea0, action=<optimized out>, action_path_indexes=0x0, action_path_length=0) at ../../../../lttng-tools-2.13.9/src/bin/lttng/commands/list_triggers.c:966 #13 0x000000000042d105 in print_one_trigger (trigger=0x4b5ea0) at ../../../../lttng-tools-2.13.9/src/bin/lttng/commands/list_triggers.c:1124 #14 print_sorted_triggers (triggers=<optimized out>) at ../../../../lttng-tools-2.13.9/src/bin/lttng/commands/list_triggers.c:1202 #15 cmd_list_triggers (argc=<optimized out>, argv=<optimized out>) at ../../../../lttng-tools-2.13.9/src/bin/lttng/commands/list_triggers.c:1421 #16 0x0000000000410be0 in handle_command (argv=0x7ffc348fc9c0, argc=1) at ../../../../lttng-tools-2.13.9/src/bin/lttng/lttng.c:237 #17 parse_args (argv=0x7ffc348fc9b8, argc=<optimized out>) at ../../../../lttng-tools-2.13.9/src/bin/lttng/lttng.c:426 #18 main (argc=<optimized out>, argv=0x7ffc348fc9b8) at ../../../../lttng-tools-2.13.9/src/bin/lttng/lttng.c:475
There's nothing particular fancy about the trigger being printed, it's just a buffer usage trigger. Here is it being displayed on an older version of lttng-tools:
- name: foo_bar_bufferUsageTrigger owner uid: 0 condition: buffer usage high session name: foo_bar channel name: foo_bar-ust domain: ust threshold (ratio): 0.70 errors: none action:notify errors: none errors: none
This trigger is being created with the following pseudocode:
pCondition = lttng_condition_buffer_usage_high_create(); lttng_condition_buffer_usage_set_session_name(...); lttng_condition_buffer_usage_set_channel_name(...); lttng_condition_buffer_usage_set_threshold_ratio(...); lttng_condition_buffer_usage_set_domain_type(); pAction = lttng_action_notify_create(); pTrigger = lttng_trigger_create(pCondition, pAction); lttng_register_trigger_with_name(pTrigger, pTriggerName);
I think this was introduced by this commit:
https://github.com/lttng/lttng-tools/commit/1ad48d9678f8f123dc7d44dbbfadc9957b7e970e#diff-e9fa6863d3580e2d95137ddaab0280d5391e830657a46f47cde39e0cfabc8fb7R109
In lttng_action_path_copy the code as is doesn't handle the case of there being no destination action path. A way to fix this is to make this code handle this scenario, attached is a patch that does this. But, perhaps we shouldn't even be hitting this scenario where there is no action path and this is just a bandaid.
Thanks,
Heman
Files
No data to display