Segmentation Fault before main() when using glut, and std::string?

Question

On 64-bit Ubuntu 14.04 LTS, I am trying to compile a simple OpenGL program that uses glut. I am getting a Segmentation Fault (SIGSEV) before any line of code is executed in

Answer 1

It's possible that your program and libGL are linked with, or using, two conflicting versions of a third library (maybe libc?). It's difficult to diagnose with the details you've provided. You could disable optimisations (-O0) and see if GDB gives up any further clues. You could see what dependencies both your program and libGL have by running ldd - this shows compile-time dependencies. Sorry I can only give suggestions - these types of runtime problems can occur for multiple reasons.

Answer 2

I met a similar problem, but LD_PRELOAD=/lib/x86_64-linux-gnu/libpthread.so.0 ./main not allways worked. This problem happened on NVIDIA GPU, OpenGL is linked to /usr/lib/nvidia-352/libGL.so.1,after tested on different computers, I find changing g++ version to g++-5 works, or linking to 'mesa/libGL.so', another OpenGL implementation, by g++ main.cpp -o main -Wl, --rpath /usr/lib/x86_64-linux-gnu/mesa -lGLU -lGL -lglut.

Answer 3

So you see in the LD_DEBUG output:

The last thing it prints out is: " 20863: symbol=__pthread_key_create; lookup in file=/usr/lib/x86_64-linux-gnu/libXdmcp.so.6 [0]

It means that ld.so id looking for __pthread_key_create since it is needed by one of your librarie [and you'd better find what library is needed this symbol, it possibly will answer what library need libpthread.so].

So __pthread_key_create must be in libpthread.so but you have no libpthread.so in your ldd output. As you can see below your program crashes possibly in using __pthread_key_create in init(). By the way you can try also

LD_PRELOAD=/lib64/libpthread.so.0 ./main

in order to make sure that pthread_key_create is loaded before other symbols.

So lgut is unlikely to be a problem. It just calls dlsym in initialization and it is absolutely correct behaviour. But the program crashes:

#0  0x0000000000000000 in ?? ()
#1  0x00007ffff3488291 in init () at dlerror.c:177
#2  0x00007ffff34886d7 in _dlerror_run (operate=operate@entry=0x7ffff3488130 <dlsym_doit>, args=args@entry=0x7fffffffddf0) at dlerror.c:129

This backtrace shows that a function with 0x00000000 address (my guess it is yet unresolved address of __pthread_key_create) was called and that is an error. What function was called? Look at sources:

This is dlerror.c:129 (frame #2):

int
internal_function
_dlerror_run (void (*operate) (void *), void *args)
{
  struct dl_action_result *result;

  /* If we have not yet initialized the buffer do it now.  */
  __libc_once (once, init);

(frame #1):

/* Initialize buffers for results.  */
static void
init (void)
{
  if (__libc_key_create (&key, free_key_mem))
    /* Creating the key failed.  This means something really went
       wrong.  In any case use a static buffer which is better than
       nothing.  */
    static_buf = &last_result;
}

It must be __libc_key_create that is a macro and it has in glibc different definitions. If you build for POSIX it is defined

/* Create thread-specific key.  */
#define __libc_key_create(KEY, DESTRUCTOR) \
  __libc_ptf_call (__pthread_key_create, (KEY, DESTRUCTOR), 1)

I asked you to build with:

g++ -pthread -Wall -g main.cpp -lpthread -lglut -lGL -lGLU -o main

In order to make sure that __libc_key_create in fact calls __pthread_key_create and lpthread is initialized before -lglut. But if you do not want use -pthread then possibly you need to analyze frame #1

#1  0x00007ffff3488291 in init () at dlerror.c:177

For example you can add disasemble for frame #1 to your question