On Fri, Dec 31, 2021 at 2:35 AM Alex <bpf@xxxxxxxxxxxxxx> wrote:
>
> With valgrind I discovered the following in v0.6.1:
>
> ```
> ==923672== Memcheck, a memory error detector
> ==923672== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
> ==923672== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
> ==923672== Command: ...
> ==923672==
> ==923672== Conditional jump or move depends on uninitialised value(s)
> ==923672== at 0x46707C: strlen (in ...)
> ==923672== by 0x466F4D: strdup (in ...)
> ==923672== by 0x41DE90: internal_map_name (libbpf.c:1521)
> ==923672== by 0x41DE90: bpf_object__init_internal_map (libbpf.c:1540)
> ==923672== by 0x4200B0: bpf_object__init_global_data_maps (libbpf.c:1601)
> ==923672== by 0x4266B5: bpf_object__init_maps (libbpf.c:2601)
> ==923672== by 0x4266B5: __bpf_object__open.part.0 (libbpf.c:6937)
> ==923672== by 0x429609: __bpf_object__open (libbpf.c:6885)
> ==923672== by 0x429609: bpf_object__open_mem (libbpf.c:6999)
> ==923672== by 0x4315C0: bpf_object__open_skeleton (libbpf.c:11529)
> ```
>
> I believe `map_name` in `internal_map_name` of src/libbpf.c is the culprit:
>
> char map_name[BPF_OBJ_NAME_LEN], *p;
>
> The issue disappears when I change this line to:
>
> char map_name[BPF_OBJ_NAME_LEN] = {}, *p;
>
> Should I submit a patch?
I don't understand where the issue is, tbh. map_name is clearly
initialized by snprintf() unconditionally, so by the time we do
strdup(map_name) it's a properly initialized string. What am I
missing?
>
> --
> Alex
