Issue 55999 in oss-fuzz: elfutils: Fuzzing build failure

Issue 55999 in oss-fuzz: elfutils: Fuzzing build failure

[ClusterFuzz-External via monorail]

[-- Attachment #1: Type: text/plain, Size: 1038 bytes --]

Status: New
Owner: ----
CC: elfut...@sourceware.org, da...@adalogics.com, evv...@gmail.com, izzeem@google.com 
Labels: Proj-elfutils
Type: Build-Failure

New issue 55999 by ClusterFuzz-External: elfutils: Fuzzing build failure
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=55999

The last 3 builds for elfutils have been failing.
Build log: https://oss-fuzz-build-logs.storage.googleapis.com/log-843b41d5-2949-48cb-9dbf-f05d5f435626.txt
Build type: fuzzing

To reproduce locally, please see: https://google.github.io/oss-fuzz/advanced-topics/reproducing#reproducing-build-failures

This bug tracker is not being monitored by OSS-Fuzz team. If you have any questions, please create an issue at https://github.com/google/oss-fuzz/issues/new.

**This bug will be automatically closed within a day once it is fixed.**

-- 
You received this message because:
  1. You were specifically CC'd on the issue

You may adjust your notification preferences at:
https://bugs.chromium.org/hosting/settings

Reply to this email to add a comment.

Re: Issue 55999 in oss-fuzz: elfutils: Fuzzing build failure

[Mark Wielaard]

Hi Evgeny,

Could you take a look at this. I think the problem is that the
clusterfuzz setup doesn't use configure --enable-sanitize-address

Note that we also recently got support for --enable-sanitize-memory but
that needs a bit of setup and only works with the clang compiler. See
https://inbox.sourceware.org/elfutils-devel/6e576e707fa3da14f4e9045cbf53ba887823a543.camel@linux.ibm.com/T/

Thanks,

Mark

On Wed, 2023-02-15 at 04:01 -0800, ClusterFuzz-External via monorail
via Elfutils-devel wrote:
> Status: New
> Owner: ----
> CC: elfut...@sourceware.org, da...@adalogics.com, evv...@gmail.com, izzeem@google.com 
> Labels: Proj-elfutils
> Type: Build-Failure
> 
> New issue 55999 by ClusterFuzz-External: elfutils: Fuzzing build failure
> https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=55999
> 
> The last 3 builds for elfutils have been failing.
> Build log: https://oss-fuzz-build-logs.storage.googleapis.com/log-843b41d5-2949-48cb-9dbf-f05d5f435626.txt
> Build type: fuzzing
> 
> To reproduce locally, please see: https://google.github.io/oss-fuzz/advanced-topics/reproducing#reproducing-build-failures
> 
> This bug tracker is not being monitored by OSS-Fuzz team. If you have any questions, please create an issue at https://github.com/google/oss-fuzz/issues/new.
> 
> **This bug will be automatically closed within a day once it is fixed.**
> 

Re: Issue 55999 in oss-fuzz: elfutils: Fuzzing build failure

[Evgeny Vereshchagin]

Hi Mark,

I fixed the build failure in
https://github.com/google/oss-fuzz/pull/9718. Once it's merged
and reaches ClusterFuzz OSS-Fuzz should close the issue.

> Note that we also recently got support for --enable-sanitize-memory but
> that needs a bit of setup and only works with the clang compiler. See
> https://inbox.sourceware.org/elfutils-devel/6e576e707fa3da14f4e9045cbf53ba887823a543.camel@linux.ibm.com/T/

Thanks! It helped to pinpoint the issue. I think it would be better if
it was possible to turn off --no-undefined
separately to make it easier to build elfutils on OSS-Fuzz (where I
can't pass `--enable-sanitize-*`) and avoid
build failures like that going forward. It was discussed in
https://sourceware.org/pipermail/elfutils-devel/2021q4/004418.html
but didn't go anywhere though.

Thanks,
Evgeny Vereshchagin

Issue 55999 in oss-fuzz: elfutils: Fuzzing build failure

[ClusterFuzz-External via monorail]

[-- Attachment #1: Type: text/plain, Size: 443 bytes --]

Updates:
	Status: Verified

Comment #1 on issue 55999 by ClusterFuzz-External: elfutils: Fuzzing build failure
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=55999#c1

The latest build has succeeded, closing this issue.

-- 
You received this message because:
  1. You were specifically CC'd on the issue

You may adjust your notification preferences at:
https://bugs.chromium.org/hosting/settings

Reply to this email to add a comment.

Re: Issue 55999 in oss-fuzz: elfutils: Fuzzing build failure

[Mark Wielaard]

Hi Evgeny,

On Wed, 2023-02-15 at 20:07 +0300, Evgeny Vereshchagin via Elfutils-
devel wrote:
> I fixed the build failure in
> https://github.com/google/oss-fuzz/pull/9718. Once it's merged
> and reaches ClusterFuzz OSS-Fuzz should close the issue.

Thanks. That seems to have worked.

> > Note that we also recently got support for --enable-sanitize-memory but
> > that needs a bit of setup and only works with the clang compiler. See
> > https://inbox.sourceware.org/elfutils-devel/6e576e707fa3da14f4e9045cbf53ba887823a543.camel@linux.ibm.com/T/
> 
> Thanks! It helped to pinpoint the issue. I think it would be better if
> it was possible to turn off --no-undefined
> separately to make it easier to build elfutils on OSS-Fuzz (where I
> can't pass `--enable-sanitize-*`) and avoid
> build failures like that going forward. It was discussed in
> https://sourceware.org/pipermail/elfutils-devel/2021q4/004418.html
> but didn't go anywhere though.

Why can't you simply use the configure support? We try to make it so
that things just work to enable the different sanitizers.

Also I think there is simply a bug in clang that it doesn't link
properly with libasan/ubsan when -fsanitize=address/undefined is given.

If you could add a configure check for that bug then we could add the
no no-undefined trick independent of compiler used.

Cheers,

Mark

Re: Issue 55999 in oss-fuzz: elfutils: Fuzzing build failure

[Evgeny Vereshchagin]

Hi Mark,

> Why can't you simply use the configure support?

I can't interfere with CFLAGS/CXXFLAGS passed by OSS-Fuzz. For example if
I used `--enable-sanitize-undefined` I would overwrite all the
`-fsanitize=...` and
`-fno-sanitize-recover=...` flags used by OSS-Fuzz. I also embed
elfutils into the
libbpf builds there so if I relied on the configure script I would
effectively instrument libbpf
and elfutils differently because libbpf would still be built with the
original CFLAGS.

Generally OSS-Fuzz doesn't expect its CFLAGS/CXXFLAGS to be changed in
any way by build
systems. When they collide stuff just stops working sometimes. The
latest example would be
https://github.com/google/oss-fuzz/pull/9427#issuecomment-1384195091
(where meson collided
with OSS-Fuzz and systemd, lxc and dbus-broker just failed to compile).

> Also I think there is simply a bug in clang that it doesn't link
> properly with libasan/ubsan when -fsanitize=address/undefined is given.

I think it's always been this way and it's unlikely to ever be fixed.
Issues like
https://bugs.llvm.org/show_bug.cgi?id=30333 have been open for years and
for example meson just gave up and started printing warnings in
https://github.com/mesonbuild/meson/commit/bde99eb6c40a9c7bc4055b0dc84a31021b7623d2
to make it clear that it isn't responsible for making clang, ASan and
--no-undefined,z,defs work.

> If you could add a configure check for that bug then we could add the
> no no-undefined trick independent of compiler used.

I'll try to figure out how it can be done. Apart from OSS-Fuzz (which
I think is a corner case in a way)
It should hopefully make `--enable-sanitize-*` work with clang.

Thanks,
Evgeny Vereshchagin