SIGSEGV on MacOS when running tests with relative path

[cprieto]

I am facing a SIGSEGV when trying to compile a copy of the examples. I am using cmake and conan to handle dependencies. This is my conanfile.txt:

[requires]
clove-unit/2.4.4

[layout]
cmake_layout

[generators]
CMakeDeps
CMakeToolchain

I placed the example in src/example.c:

#define CLOVE_SUITE_NAME MySuite01
#include "clove-unit.h"

CLOVE_TEST(FirstTest) {
    int a = 1;
    int b = 1;
    CLOVE_INT_EQ(a, b);
}

CLOVE_TEST(SecondTest) {
    CLOVE_IS_TRUE(1);
}

And src/main.c:

#define CLOVE_IMPLEMENTATION
#include "clove-unit.h"

CLOVE_RUNNER()

My CMakeLists.txt file is simple as well:

cmake_minimum_required(VERSION 3.26)
project(all_tests C)
set(CMAKE_C_STANDARD 11)
find_package(clove-unit REQUIRED)
set(TESTS src/main.c src/example.c)
add_executable(all_tests ${TESTS})
target_link_libraries(all_tests clove-unit::clove-unit)

From there simple steps:

conan install .
cmake --preset conan-debug
cmake --build --preset conan-debug

But when running the tests:

❯ build/Debug/all_tests
[INFO] Executing Test Runner with detail level: 'Full'
[INFO] Suites / Tests found: 1 / 2
fish: Job 1, 'build/Debug/all_tests' terminated by signal SIGSEGV (Address boundary error)

I am on macOS 14.4.1 using Clang 15.0.0, my conan profile is:

[settings]
arch=armv8
build_type=Debug
compiler=apple-clang
compiler.cppstd=gnu17
compiler.libcxx=libc++
compiler.version=15
os=Macos

Any idea what could be happening?

[fdefelici]

Hi @cprieto, thanks reporting the issue in detail.

I'll try to replicate this scenario, and provide back some feedback

[fdefelici]

@cprieto by now, I didn't succeed to reproduce the issue.

To avoid falling into the cliché "On my machine works :)", I've put in place a dedicated repository with related github actions trying to reproduce your enviroment and example.

More in detail you can look at:

• the branch named test
• and here the related action outocome

In the action you can find some useful output like these:

Environment related

Binary Format

Test Execution

May I ask to you 3 things:

• Could execute file command on the all_tests binary file to check if it's format is Mach-O 64-bit executable arm64?
• It seems in your example you are using fish shell. I didn't test it on github actions. Eventually could you try executing using bash (It's just a try...)?
• Could you check endianess of your machine using this code snippet?

int main() 
{
   unsigned int i = 1;
   char *c = (char*)&i;
   if (*c) puts("System Endianess: Little endian");
   else puts("System Endianess: Big endian");
   return 0;
}

[cprieto]

Ok, thanks for answering!

I did a little more research around this and tested in different systems:

• It compiles fine in all platforms tested so far
• In Windows/Linux x86_64 it all works fine, no problem at all
• In Linux armv8 (a Docker container running in my Apple silicon mac) using GCC, it works fine
• In Linux with Apple Silicon using Clang, it works
• In macOS in Apple silicon, this is where the stuff fails with SIGSEGV
• I tried compiling with GCC instead of Clang in macOS with Apple Silicon, still getting SIGSEGV

In conclusion, so far the problem is appearing only in Apple Silicon running macOS. I had not tried in Apple Intel but I suspect it will be the same problem.

Yes, file is Machos and little endian.

[fdefelici]

Thanks for your analisys.

About platforms and compilers:

• for Windows and Linux (with both gcc and clang) I can confirm too (dedicated jobs/actions on clove-unit repository exists and run for each release)
• for MacOS on Intel chip I can confirm it is working (I have a MacBook Pro on i9)
• for MacOS on Apple Silicon chip I was thrusting clove-unit github actions too (this is also the scenario taken into account in https://github.com/fdefelici/clove-unit-conan-example (runner is on an M1 chip, even if virtual), but unluckly is not working on real hardware like yours)

For what I know, MACH-O binary format should be the same for Intel and Apple Silicon.
So, clove-unit should be able to parse test symbols where:

• mach-o is of type "executable" (not "bundle") and "64 bit"
• platform is "Little Endian"

At the moment I don't have an Apple Silicon hardware, but I'll try to dig it further
if any ideas come to your mind, please let me know.

PS: I'll rename this issue accordly to reflect the problem

[fdefelici]

@cprieto I succeeded to replicate the issue on MacOS Apply Silicon and Intel.

Basically the issue is present mainly when running test using a relative path to the executable (instead with absolute path every worked fine)

With relative path, an error in computing the proper image slide address of the binary is done. This bring to wrong test symbol function address and then a segmentation fault.

Meanwhile I add more tests and make the solution more robust, you could try this clove-unit.h patch