CODEWITHSUNDEEP
macoscsegmentation-fault
Lance Pollard
Lance Pollard

Reputation: 79360

Weird C library linkage issues on Mac - Segmentation Fault

I have a strange segmentation fault that doesn't exist when everything is in 1 .c file, but does exist when I put part of the code in a dynamically linked library and link it to a test file. The complete code for the working 1 .c file code is at the bottom, the complete code for the error system with 2 .c and 1 .h file come first.

Here is the error system:

example.h:

#include <stdio.h>
#include <stdlib.h>

typedef struct MYARRAY {
  int len;
  void* items[];
} MYARRAY;

MYARRAY *collection;

void
mypush(void* p);

example.c:

#include "example.h"

void
mypush(void* p) {
  printf("Here %lu\n", sizeof collection);
  puts("FOO");
  int len = collection->len++;
  puts("BAR");
  collection->items[len] = p;
}

example2.c:

This is essentially a test file:

#include "example.h"

void
test_print() {
  puts("Here1");
  mypush("foo");
  puts("Here2");
}

int
main() {
  collection = malloc(sizeof *collection + (sizeof collection->items[0] * 1000));
  collection->len = 0;
  puts("Start");
  test_print();
  puts("Done");
  return 0;
}

Makefile:

I link example to example2 here, and run:

example:
  @clang -I . -dynamiclib \
    -undefined dynamic_lookup \
    -o example.dylib example.c
  @clang example2.c example.dylib -o example2.o
  @./example2.o
.PHONY: example

The output is:

$ make example
Start
Here1
Here 8
FOO
make: *** [example] Segmentation fault: 11

But it should show the full output of:

$ make example
Start
Here1
Here 8
FOO
BAR
Here2
Done

The weird thing is everything works if it is this system:

example.c:

#include <stdio.h>
#include <stdlib.h>

typedef struct MYARRAY {
  int len;
  void* items[];
} MYARRAY;

MYARRAY *collection;

void
mypush(void* p) {
  printf("Here %lu\n", sizeof collection);
  puts("FOO");
  int len = collection->len++;
  puts("BAR");
  collection->items[len] = p;
}

void
test_print() {
  puts("Here1");
  mypush("foo");

  puts("Here");
}

int
main() {
  collection = malloc(sizeof *collection + (sizeof collection->items[0] * 1000));
  collection->len = 0;
  puts("ASF");

  test_print();

  return 0;
}

Makefile:

example:
  @clang -o example example.c
  @./example
.PHONY: example

Wondering why it's creating a segmentation fault when it is linked like this, and what I am doing wrong.

I have checked otool and with DYLD_PRINT_LIBRARIES=YES and it shows it is importing the dynamically linked libraries, but for some reason it's segmentation faulting when linked but works fine when it isn't linked.

Upvotes: 3

Views: 67

Answers (1)

Crowman
Crowman

Reputation: 25926

Your problem is this, in example.h:

MYARRAY *collection;

Since both main.c and example.c include this file, you end up defining collection twice, which results in undefined behavior. You need to make sure you define each object only once. The details are relatively unimportant since anything can happen with undefined behavior, but what's probably happening is that main.c is allocating memory for one object, but the one example.c is using is still NULL. As mentioned in the comments, since you define collection in main.c your linker is able to build the executable without needing to look for that symbol in the dynamic library, so you don't get a link time warning about it being defined there too, and obviously there'd be no cause for a warning at the time you compile the library.

It works for you when you put everything in one file because obviously then you're not defining anything twice, anymore. The error itself is nothing to do with the fact you're using a dynamic library, although that may have made it harder to detect.

It would be better to define this in example.c and provide a constructor function, there's no need for main() to be able to access it directly. But if you must do this, then define it in example.c and just declare an extern identifier in the header file to tell main.c that the object is defined somewhere else.

Upvotes: 5

Related Questions