From: Ian Rogers <irogers@google.com>
To: linux-trace-devel@vger.kernel.org, Steven Rostedt <rostedt@goodmis.org>
Cc: Ian Rogers <irogers@google.com>
Subject: [PATCH v1] libtraceevent: Fix event-parse memory leak in process_cond
Date: Tue, 30 Apr 2024 00:39:08 -0700 [thread overview]
Message-ID: <20240430073908.1706482-1-irogers@google.com> (raw)
Leak sanitizer was reporting a stack trace with perf:
```
$ perf stat -e 'kvm:kvm_inj_exception' true
Performance counter stats for 'true':
0 kvm:kvm_inj_exception
0.001701473 seconds time elapsed
0.000000000 seconds user
0.001865000 seconds sys
=================================================================
==1705137==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 2 byte(s) in 1 object(s) allocated from:
#0 0x7f413ee80778 in __interceptor_strdup ../../../../src/libsanitizer/asan/asan_interceptors.cpp:454
#1 0x7f413ecb7b66 in __read_token libtraceevent/src/event-parse.c:1274
#2 0x7f413ecb85bb in read_token libtraceevent/src/event-parse.c:1432
#3 0x7f413ecbeaaa in process_entry libtraceevent/src/event-parse.c:2554
#4 0x7f413ecc54ae in process_arg_token libtraceevent/src/event-parse.c:3698
#5 0x7f413ecbb52e in process_arg libtraceevent/src/event-parse.c:2017
#6 0x7f413ecbd05a in process_op libtraceevent/src/event-parse.c:2357
#7 0x7f413ecc5a56 in process_arg_token libtraceevent/src/event-parse.c:3752
#8 0x7f413ecbb52e in process_arg libtraceevent/src/event-parse.c:2017
#9 0x7f413ecc5dd6 in event_read_print_args libtraceevent/src/event-parse.c:3791
#10 0x7f413ecc6511 in event_read_print libtraceevent/src/event-parse.c:3879
#11 0x7f413ecda16c in parse_format libtraceevent/src/event-parse.c:7808
#12 0x7f413ecda667 in __parse_event libtraceevent/src/event-parse.c:7866
#13 0x7f413ecda71b in tep_parse_format libtraceevent/src/event-parse.c:7908
#14 0x561672439029 in tp_format util/trace-event.c:94
#15 0x561672439141 in trace_event__tp_format util/trace-event.c:109
#16 0x56167230a429 in evsel__newtp_idx util/evsel.c:472
#17 0x561672329f99 in add_tracepoint util/parse-events.c:552
#18 0x56167232a5b4 in add_tracepoint_event util/parse-events.c:627
#19 0x56167232ebf2 in parse_events_add_tracepoint util/parse-events.c:1313
#20 0x561672411e0e in parse_events_parse util/parse-events.y:500
#21 0x561672332409 in parse_events__scanner util/parse-events.c:1878
#22 0x561672333cd4 in __parse_events util/parse-events.c:2146
#23 0x561672334e74 in parse_events_option util/parse-events.c:2349
#24 0x56167269ec23 in get_value tools/lib/subcmd/parse-options.c:251
#25 0x56167269fe65 in parse_short_opt tools/lib/subcmd/parse-options.c:351
#26 0x5616726a0e4d in parse_options_step tools/lib/subcmd/parse-options.c:539
#27 0x5616726a1d86 in parse_options_subcommand tools/lib/subcmd/parse-options.c:654
#28 0x5616720e6ad2 in cmd_stat tools/perf/builtin-stat.c:2531
#29 0x5616722b0f5d in run_builtin tools/perf/perf.c:350
$ cat /sys/kernel/tracing/events/kvm/kvm_inj_exception/format
name: kvm_inj_exception
ID: 1956
format:
field:unsigned short common_type; offset:0; size:2; signed:0;
field:unsigned char common_flags; offset:2; size:1; signed:0;
field:unsigned char common_preempt_count; offset:3; size:1; signed:0;
field:int common_pid; offset:4; size:4; signed:1;
field:u8 exception; offset:8; size:1; signed:0;
field:u8 has_error; offset:9; size:1; signed:0;
field:u32 error_code; offset:12; size:4; signed:0;
field:bool reinjected; offset:16; size:1; signed:0;
print fmt: "%s%s%s%s%s", __print_symbolic(REC->exception, { 0, "#" "DE" }, { 1, "#" "DB" }, { 3, "#" "BP" }, { 4, "#" "OF" }, { 5, "#" "BR" }, { 6, "#" "UD" }, { 7, "#" "NM" }, { 8, "#" "DF" }, { 10, "#" "TS" }, { 11, "#" "NP" }, { 12, "#" "SS" }, { 13, "#" "GP" }, { 14, "#" "PF" }, { 16, "#" "MF" }, { 17, "#" "AC" }, { 18, "#" "MC" }), !REC->has_error ? "" : " (", !REC->has_error ? "" : __print_symbolic(REC->error_code, { }), !REC->has_error ? "" : ")", REC->reinjected ? " [reinjected]" : ""
```
The issue appears to be that when process_cond returns an error,
callers clear the variable holding the string but the string was never
freed. This change adds the free when process_cond returns
TEP_EVENT_ERROR.
Signed-off-by: Ian Rogers <irogers@google.com>
---
src/event-parse.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/event-parse.c b/src/event-parse.c
index d607556..b6ae67e 100644
--- a/src/event-parse.c
+++ b/src/event-parse.c
@@ -2373,6 +2373,8 @@ process_op(struct tep_event *event, struct tep_print_arg *arg, char **tok)
/* it will set arg->op.right */
type = process_cond(event, arg, tok);
+ if (type == TEP_EVENT_ERROR)
+ free(token);
} else if (strcmp(token, ">>") == 0 ||
strcmp(token, "<<") == 0 ||
--
2.44.0.769.g3c40516874-goog
next reply other threads:[~2024-04-30 7:39 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-30 7:39 Ian Rogers [this message]
2024-04-30 8:03 ` [PATCH v1] libtraceevent: Fix event-parse memory leak in process_cond Ian Rogers
2024-05-17 0:40 ` Steven Rostedt
2024-05-28 15:50 ` Ian Rogers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240430073908.1706482-1-irogers@google.com \
--to=irogers@google.com \
--cc=linux-trace-devel@vger.kernel.org \
--cc=rostedt@goodmis.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).