Add on Linux/macOS smoke tests and fix OpenAL macOS problems

[traversaro]

Added some simple execution of the Gazebo commands and check of their output. This should permit to debug if RoboStack/ros-noetic#55 is a problem in the generated binary or some specific problem in the user system.

Checklist

• Used a personal fork of the feedstock to propose changes
• Bumped the build number (if the version is unchanged)
• Reset the build number to 0 (if the version changed)
• Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
• Ensured the license file is being packaged.

[conda-forge-linter]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

[traversaro]

@conda-forge-admin, please rerender

[github-actions]

Hi! This is the friendly automated conda-forge-webservice.
I tried to rerender for you, but it looks like I wasn't able to push to the add-smoke-tests
branch of traversaro/gazebo-feedstock. Did you check the "Allow edits from maintainers" box?

NOTE: PRs from organization accounts cannot be rerendered because of GitHub
permissions.

[traversaro]

Hi! This is the friendly automated conda-forge-webservice.
I tried to rerender for you, but it looks like I wasn't able to push to the add-smoke-tests
branch of traversaro/gazebo-feedstock. Did you check the "Allow edits from maintainers" box?

NOTE: PRs from organization accounts cannot be rerendered because of GitHub
permissions.

I am afraid that this happens because mine is a fork of a fork. In any case, in this case the re-rendering is probably not necessary.

[traversaro]

Unfortunately the macOS build is working fine, the only failure is on Linux due to the missing yum_requirements, I will add them now.

[traversaro]

The Linux change of yum_requirements.txt are not working because I need to re-render the feedstock, unfortunately I need to do that manually.

[traversaro]

I was finally able to trigger a Gazebo failure with the script in :

Launch gzserver in verbose mode
Sleep for 10 seconds
Gazebo multi-robot simulator, version 11.3.0
Copyright (C) 2012 Open Source Robotics Foundation.
Released under the Apache 2 License.
http://gazebosim.org

/Users/runner/miniforge3/conda-bld/gazebo_1614704588943/test_tmp/run_test.sh: line 9: 17495 Segmentation fault: 11  gzserver --verbose
Test if gzserver is still running
Tests failed for gazebo-11.3.0-hc02bdab_8.tar.bz2 - moving package to /Users/runner/miniforge3/conda-bld/broken

The error seems to be a segmentation fault, so I don't know if it is exactly the same problem of @sonelu in RoboStack/ros-noetic#55 . However, it is probably worth trying to apply the patch in gazebosim/gazebo-classic#2941 to check if it fixes the problem. Even if it does not fix it, it may be possible that the reason for which the program does not work is something else, so we could just disable the test and leave the patch.

[wolfv]

I have an macOS machine here. Anything I can do to help debug this?

[traversaro]

I have an macOS machine here. Anything I can do to help debug this?

With 11.3.0_7 build of Gazebo if you run gzserver --verbose do you have the same failure of RoboStack/ros-noetic#55 ? Which macOS version do you have?

[traversaro]

Even with the patch from gazebosim/gazebo-classic#2941, the script https://github.com/conda-forge/gazebo-feedstock/pull/54/files#diff-43e7f7952718f9b999101617f6a78ef0c73c54eb498cfa50a4959db2a774a4ce still results in segfault, so I wonder if it is a different problem.

[Tobias-Fischer]

I fixed your patch so that the cmake error does not occur (mixing old-style with new-style target_link_libraries, i.e. using one that specifies PRIVATE and another without specification is not supported). Let's see whether that makes the segfault disappear :)

[traversaro]

I fixed your patch so that the cmake error does not occur (mixing old-style with new-style target_link_libraries, i.e. using one that specifies PRIVATE and another without specification is not supported). Let's see whether that makes the segfault disappear :)

Thanks! I wrongly checked the previous commit.

[traversaro]

I fixed your patch so that the cmake error does not occur (mixing old-style with new-style target_link_libraries, i.e. using one that specifies PRIVATE and another without specification is not supported). Let's see whether that makes the segfault disappear :)

Thanks! I wrongly checked the previous commit.

I propagated the fix to gazebosim/gazebo-classic#2941 .

[Tobias-Fischer]

Still segfaulting ..

[traversaro]

Indeed, probably the source of segfault is not directly related to OpenAL or the failure of RoboStack/ros-noetic#55 . I wonder if we should try to get the patch in in anycase, or try to disable OpenAL on macOS (as in any case if I understood correctly OpenAL is not enable on Windows/Linux).

[Tobias-Fischer]

Sorry for directly working on your branch - let's check whether disabling openal helps.

[traversaro]

Sorry for directly working on your branch - let's check whether disabling openal helps.

No problem. With ~1.20 H debug cycle, any quick iteration is welcome.

[Tobias-Fischer]

And still segfaulting .. same as before. So it seems unrelated ..

[wolfv]

I have an intel mac mini that I can test on, that has 11.X Big Sur installed. So far I am also seeing the missing _alcOpenDevice symbols problem, but I am in the process of recompiling.

One (potential) source of issue is also how conda does relocation (replace the prefix string in binary). That works well for 99% of the cases (string will be padded with \0 but when C++ std::string are used there is a smart compiler and small buffer optimization and that sometimes make C++ "think" it knows how long a string is supposed to be, and then bad things can happen. I am just mentioning this as a potential source of this issue.

I was planning to run gazebo with GDB or LLDB once it's rebuilt.

[traversaro]

I created a small repo to build the test suite of Gazebo against conda-forge provided dependencies and to test the conda-forge binaries: https://github.com/traversaro/gazebo-conda-force-ci, that perhaps should provide us some additional info.

[traversaro]

I created a small repo to build the test suite of Gazebo against conda-forge provided dependencies and to test the conda-forge binaries: https://github.com/traversaro/gazebo-conda-force-ci, that perhaps should provide us some additional info.

The segfault of run_test.sh on macOS was reproduced in https://github.com/traversaro/gazebo-conda-force-ci/runs/2020690996 .

[wolfv]

When testing locally gazebo seems to work fine so far (I am startign with gazebo --verbose). I can see issues when dragging+dropping objects (first time works fine, but second time there seems to be some probelm with the Ogre Resources?).

Here are screenshots:

[traversaro]

So, the PR solved the _alcOpenDevice problem? In that case, I think we can merge the PR (removing the run_test.sh that is clearly not working) so that we have a working Gazebo on macOS, and we can track the other problems in other issues.

[wolfv]

yes, the PR has solved that issue for me! Are there other segfaults you were finding? I haven't deeply checked gazebo, so let me know if I should run any additional tests.

[traversaro]

yes, the PR has solved that issue for me! Are there other segfaults you were finding? I haven't deeply checked gazebo, so let me know if I should run any additional tests.

Just to double check, can you verify if gzserver --verbose is running fine without any segfault?

Furthermore, did you just used the latest patch of @Tobias-Fischer that completely disable OpenAL, or the one that fixes the link?

[wolfv]

I used e3aa51ed3d25aea13f34aca6a735793eabd87746 which is the last commit by tobias on this PR

gzserver --verbose works without problems.

Do you want me to try with OpenAL enabled? I read that Apple is deprecating it ...
Also, just FYI, the OGRE / OpenGL seems a bit sluggish. Not sure if this is related to not-very-powerful hardware, large screen or some issues in our OGRE build. But this is unrelated :)

[traversaro]

I used e3aa51ed3d25aea13f34aca6a735793eabd87746 which is the last commit by tobias on this PR

Perfect, given that OpenAL is disabled on Windows and Linux, I think it is safe to just disable, unless some users really needs it. : )

[traversaro]

Given the thumbs up, I plan to merge once CI is green.