pmacct / pmacct

pmacct is a small set of multi-purpose passive network monitoring tools [NetFlow IPFIX sFlow libpcap BGP BMP RPKI IGP Streaming Telemetry].

Home Page:http://www.pmacct.net

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Openwrt: compile error for [-Werror=stringop-overflow=] in src/external_libs/libcdada/include/cdada/__list_internal.h

Konstantin-Glukhov opened this issue · comments

pmacct-1.7.9/src/external_libs/libcdada/include/cdada/__list_internal.h:255:15: error: 'void* memcpy(void*, const void*, size_t)' writing 2 or more bytes into a region of size 1 overflows the destination [-Werror=stringop-overflow=]
  255 |         memcpy(&aux, val, m->user_val_len);
      |         ~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~

Is it a real error or something that can be remedied with a compiler option, like removing -Werror flag?
What happens if m->user_val_len > sizeof(T)? Should the code be something like this?

T aux;
if (m->user_val_len <= sizeof(T)) {
    memset(&aux, 0, sizeof(T));
    memcpy(&aux, val, m->user_val_len);
} else {
    // Handle the case where m->user_val_len is greater than sizeof(T)
    // Log an error or take other appropriate action.
}

or it is always guaranteed that m->user_val_len <= sizeof(T)?

@Konstantin-Glukhov thanks for the report.

m->user_val_len can only be < sizeof(T) at this point, given that cdada_list_create implementation sets it:

https://github.com/msune/libcdada/blob/master/src/list.cc#L10

The compiler can't infer that from the code, obviously. The only way this can be problematic is if cdada_list_t would get memory corrupted (e.g. a bug in the code using the library, like pmacct). This will apply to all types (set, map etc.)

I can add an unlikely() branch to exit if m->user_val_len is > sizeof(T), which would likely remove that warning. Can you open a bug report in https://github.com/msune/libcdada/ adding the the compiler version and arch ? I can have a look sometime this weekend.

thx

Thank you for looking at this promptly. I opened the issue as requested.

So, following the discussion in libcdada's issue, and doing the following changes to the OpenWRT Makefile recipe ( -Wno-stringop-overflow):

TARGET_CFLAGS += -ffunction-sections -fdata-sections -Wno-stringop-overflow
TARGET_CXXLAGS += -Wno-stringop-overflow
TARGET_LDFLAGS += -Wl,--gc-sections

I got past the error. It compiles libcdada and the rest of pmacct objects. Linking ultimately fails, and I don't know exactly why:

libtool:   error: '/builder/shared-workdir/build/staging_dir/toolchain-arm_cortex-a15+neon-vfpv4_gcc-12.3.0_musl_eabi/arm-openwrt-linux-muslgnueabi/lib/libstdc++.la' is not a valid libtool archive
gmake[6]: *** [Makefile:407: libnfprobe_plugin.la] Error 1
gmake[6]: Leaving directory '/root/sdk/build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/pmacct-1.7.9/src/nfprobe_plugin'

Now, this seems a common problem for OpenWRT with libstdc++; see this and this, which btw mentions pmacct as one of the problematic packages.

Several thoughts:

  • My initial guess is that libstdc++ is actually NOT installed in the target based on this comment. So it might be this is missing. I tried it, but I failed. Maybe you will manage.
  • I don't completely discard there is something fishy with libtool/autoconf, but we have cross-compiled pmacct in multiple platforms before without a problem.

Let me know if you manage to link it. In the meantime I will try to fix the warnings in libcdada. I don't like the fact that even in raspberry pie these warnings are no appearing(raspi CI run), which means I can't easily add a lightweight regression in pmacct's and/or libcdada's CI 😢

There seems to be a bug or something that I do not understand about the OpenWrt build process.
/builder/shared-workdir/build/ is supposed to be replaced with /home/user_name/sdk/staging_dir by the configure process.
To successfully build the package create the following link as a workaround:

mkdir -p /builder/shared-workdir/build/
ln -s /home/user_name/sdk/staging_dir /builder/shared-workdir/build/

Also add libstdcpp to the dependencies list in ~/my_packages/pmacct/Makefile:

DEPENDS:=+libpcap +libpthread +libstdcpp

Did you manage to build the package with the workaround above?

Yes I did. Sorry I was not clear about it in my reply. I also successfully installed the package on my router and it seems to be working.

Yes I did. Sorry I was not clear about it in my reply. I also successfully installed the package on my router and it seems to be working.

Glad to hear that @Konstantin-Glukhov .

@paololucente As I said, I will try to fix the warnings of libcdada in v0.6.0. But I don't like we won't be able to run regressions on openwrt.

Let's keep this issue as a reference for the workaround on the warning + the issues with openwrt build itself for C++.

I think we can close it.

How to compile pmacct in OpenWRT

Base package recipe: msune/libcdada#14 (comment)

and

doing the following changes to the OpenWRT Makefile recipe ( -Wno-stringop-overflow):

TARGET_CFLAGS += -ffunction-sections -fdata-sections -Wno-stringop-overflow
TARGET_CXXLAGS += -Wno-stringop-overflow
TARGET_LDFLAGS += -Wl,--gc-sections

and

There seems to be a bug or something that I do not understand about the OpenWrt build process.
/builder/shared-workdir/build/ is supposed to be replaced with /home/user_name/sdk/staging_dir by the configure process.

To successfully build the package create the following link as a workaround:

mkdir -p /builder/shared-workdir/build/
ln -s /home/user_name/sdk/staging_dir /builder/shared-workdir/build/

Also add libstdcpp to the dependencies list in ~/my_packages/pmacct/Makefile:

DEPENDS:=+libpcap +libpthread +libstdcpp

I agree. Gracias por abordarlo rápidamente.