Skip to content

[BUG] Incorrect cmake command while building fuzzer with build-tools.sh #2656

Closed

Description

@crazoes

Describe the bug
When using the build-tools script to build the fuzzer, in build step for sof_parser_ep, one of the cmake commands is not correct. Getting the following halfway in the output:

[ 42%] Performing build step for 'sof_parser_ep'
Usage

  cmake [options] <path-to-source>
  cmake [options] <path-to-existing-build>

Specify a source directory to (re-)generate a build system for it in the
current working directory.  Specify an existing build directory to
re-generate its build system.

Run 'cmake --help' for more information.

[ 50%] Performing install step for 'sof_parser_ep'

Despite this, the script and build both are running successfully or so it seems, so this may or may not be a bug, but this certainly doesn't look right since one of the intermediate cmake commands is not getting executed. I tried tracing this, but seems like these files are generated from CMakeLists.txt file located in tools/fuzzer directory.

To Reproduce

./scripts/build-tools.sh -f

Reproduction Rate
1/1

Expected behavior
All cmake commands run successfully and not get help midway execution.

Impact
What impact does this issue have on your progress (e.g., annoyance, showstopper)

Environment

  1. Branch name and commit hash of the 2 repositories: sof (firmware/topology) and linux (kernel driver).

Screenshots or console output
https://gist.github.com/crazoes/8542f5c90bad18644a66e63d331ef622#file-logs-L9820-L9829

Activity

  1. added
    bugSomething isn't working as expected
    on Mar 28, 2020
  2. lgirdwood commented on Mar 29, 2020

    @lgirdwood
    Member

    @jajanusz any inputs ?

  3. marc-hb commented on Mar 30, 2020

    @marc-hb
    Collaborator

    Good catch, even more impressive catch without #2654 :-)

    I had a very quick look at this.

    Here's a more "focused" reproduction:

    ./scripts/build_tools -f
    make -C tools/build_tools/build_fuzzer/ VERBOSE=1
    
    
    make[2]: Entering directory 'SOF/sof/tools/build_tools/build_fuzzer'
    [  7%] Performing build step for 'sof_parser_ep'
    cd SOF/sof/tools/build_tools/build_fuzzer/sof_parser/build && /usr/bin/cmake
    Usage
    
      cmake [options] <path-to-source>
      cmake [options] <path-to-existing-build>
      cmake [options] -S <path-to-source> -B <path-to-build>
    

    The tools/fuzzer/CMakeLists.txt:ExternalProject_Add(sof_parser_ep,...) command looks suspicious.

    It's very scary that this failure doesn't stop the build, but maybe it's just because this library is not used anywhere now yet built anyway because of BUILD_ALWAYS 1?

  4. changed the title [-][BUG](maybe) Incorrect cmake command while building fuzzer with build-tools.sh[/-] [+][BUG] Incorrect cmake command while building fuzzer with build-tools.sh[/+] on Apr 1, 2020
  5. singalsu commented on Aug 27, 2020

    @singalsu
    Collaborator

    Yep, just confirm as assigned that this still happens. I'll see if I can fix this or need to get help.

  6. singalsu commented on Aug 27, 2020

    @singalsu
    Collaborator

    Umm, deleting line for BUILD_COMMAND seems to avoid the error and everything seems to be working. How did I find this out? Looked other examples of ExternalProject_Add() in SOF... I'll do a PR.

  7. marc-hb commented on Aug 27, 2020

    @marc-hb
    Collaborator

    I spent more time testing this and I now understand why this BUILD_COMMAND cmake mistake was not fatal. It's the tricky combination of two things:

    cmake; echo $?
    Usage
    
      cmake [options] <path-to-source>
      ...
    
    0

    With BUILD_COMMAND fubar the build aborts immediately - but not with BUILD_COMMAND cmake

    So at this point ExternalCommand wrongly believes /lib/libsof_tplg_parser.so was built. Yet that library was not built, so how come the rest of the build is successful? Because the next, install step for sof_parser_ep which is only meant to install "accidentally" builds+installs. Easy to spot in the build logs when looking specifically for it.

  8. singalsu commented on Aug 28, 2020

    @singalsu
    Collaborator

    Thanks for explanation @marc-hb ! Is there a way to debug cmake execution somehow? Tutorials? I've found it hard to understand, and out of the two nuisances even the m4 feels better to me.

  9. marc-hb commented on Aug 29, 2020

    @marc-hb
    Collaborator

    Is there a way to debug cmake execution somehow?

    Yes and no. Both cmake and make are very difficult to debug. There are a few tricks.

    • Write as little cmake code as possible. If CMake code grows complicated, it's time to move it to a Python script that can be run (and of course: debugged) independently
    • Break the code you're trying to debug and make sure it does break the build to make sure it's relevant. It's very frequent to stare at irrelevant code! Sometimes the resulting error messages also give useful clues, e.g: BUILD_COMMAND fubar
    • cmake -v, VERBOSE=1 , make -dr, etc. etc. |& _.log
    • With make and ninja build as little as possible to reduce the noise. Either 1. build very specific targets or 2. build everything then touch only one (relevant) file, don't clean and rebuild. Or both.
    • printf as usual
    • Google and Stackoverflow
    • recursive grep -C 5 CMake-generated code
  10. added a commit that references this issue on Aug 31, 2020
    f430add
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

bugSomething isn't working as expected

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions