0

While setting up a new project (using CMake, compiler is gcc version 5.2.1, ubuntu (15.10)), I wanted to use a shared_ptr.

This simple main.cpp works fine:

#include <iostream>
#include <memory>    
using namespace std;

int main()
{    
    cout<<"Hi there!"<<endl;
    return 0;
}

But just defining a shared_ptr will cause the program to crash with segfault before even writing "Hi there!".

#include <iostream>
#include <memory>    
using namespace std;

int main()
{    
    cout<<"Hi there!"<<endl;
    shared_ptr<double> test;  // <- new line
    return 0;
}

I added

set(CMAKE_CXX_FLAGS "-std=c++11")

to the CMakeLists.txt. Is there something I'm missing here. I could not find any answers that explain the segfault just because of the definition of a shared_ptr.

The GDB output is not helpful at all:

Program received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()

EDIT: Compiling by hand using

g++ -std=c++11 -o testx main.cpp

produces a runable executable for both cases so it has to be a CMake issue i guess. So here is the CMake file for the project:

project(yorld3)
cmake_minimum_required(VERSION 2.8)

set(CMAKE_CXX_FLAGS "-std=c++11")

find_package(OpenGL REQUIRED)
include_directories(${OpenGL_INCLUDE_DIRS})
set(LIBS ${LIBS} ${OpenGL_LIBRARIES})

find_package(GLUT REQUIRED)
include_directories(${GLUT_INCLUDE_DIRS})
set(LIBS ${LIBS} ${GLUT_LIBRARIES})

find_package(Bullet REQUIRED)
include_directories(${Bullet_INCLUDE_DIRS})
set(LIBS ${LIBS} ${Bullet_LIBRARIES})

link_directories(${SRC_BINARY_DIR}/src)

add_subdirectory(src)
INCLUDE_DIRECTORIES(src)
INCLUDE_DIRECTORIES(src/core)
add_executable(test main.cpp )
target_link_libraries(test mycorelib GLU GL glut)

EDIT2: After a lot of testing I manually compiled the program again not linking my lib:

g++ -std=c++11 -g -Wall -I src/core/app -o testx main.cpp src/core/app/yorld_window.cpp -lGL -lGLU -lglut

That way I can reproduce the segfault without using CMake.

yonarw
  • 121
  • 7
  • 1
    In the resulting binary, in the compiler or in cmake? – Mats Petersson Nov 22 '15 at 14:03
  • 3
    What's the compiler and its version? What OS are you using? It's hard to find the problem by your provided information. – masoud Nov 22 '15 at 14:03
  • Manually compiling this works in g++ 4.9.2 and clang++ 3.8. – Mats Petersson Nov 22 '15 at 14:05
  • Works as well in MSVC++14.0 and GCC 5.2 –  Nov 22 '15 at 14:06
  • Compiler is gcc version 5.2.1, im running ubuntu (15.10). Sorry for not mentioning: The segfault occurs when running the program. – yonarw Nov 22 '15 at 14:07
  • I just double checked both codes just compiling by hand not through CMake and they both work fine. So it has to be a CMake problem! – yonarw Nov 22 '15 at 14:15
  • Have you tried building with `make VERBOSE=1`? – Mats Petersson Nov 22 '15 at 14:24
  • You probably run wrong executable, not one that was compiled from this source code. Also try to remove `target_link_libraries(test mycorelib GLU GL glut)`. Does this fix the segfault? – Ivan Aksamentov - Drop Nov 22 '15 at 14:27
  • @MatsPetersson that worked just fine but did not tell me anything strange – yonarw Nov 22 '15 at 14:31
  • @Drop Strange if i remove this line it works! But since i want to call stuff from mycorelib i have to link it somehow. – yonarw Nov 22 '15 at 14:33
  • Are you sure it's not a side-effect somewhere that is causing the problem? – Mats Petersson Nov 22 '15 at 14:38
  • Also, debugging by adding one library at a time may help. Does it crash in main or before? – Mats Petersson Nov 22 '15 at 14:41
  • @MatsPetersson it could be a side-effect from something else. It seems linking mycorelib is the problem. As soon as I call any function from that lib (while using shared_ptr) I get a segfault. When i dont use shared_ptr I can call whatever I want from mycorelib and it won't crash... – yonarw Nov 22 '15 at 14:44
  • @MatsPetersson also as I said in my question: the crash happens before any code will be executed by the program it seems. – yonarw Nov 22 '15 at 14:48
  • 1
    So, presumably some global constructor? Order of constructors in global context is unspecified between translation units, so may be part of the problem. – Mats Petersson Nov 22 '15 at 14:49
  • @MatsPetersson I tried a lot more combinations now. Seems that as soon as my lib makes any calls to external functions (glutMainLoop() or even chrono::high_resolution_clock::now() ) the program will crash. No compiler warnings. No gdb trace. Nothing – yonarw Nov 22 '15 at 15:19
  • The problem is obviously in `mycorelib` but we have no idea what it does, so we could not possibly help. Guesses: static order fiasco, uninitialized glut, undefined behavior, compiler/standard library version/flags mismatch etc. Try to tear of components from the lib one by one, recompile it and link application each time. After you get app working, the last component removed is probably responsible for the crash. Also you might try to come up with [mcve](http://stackoverflow.com/help/mcve) – Ivan Aksamentov - Drop Nov 22 '15 at 16:21
  • I tracked the problem down to glutInit(...), i set up a little example that will show how the problem can be reproduced but I'm not sure if this question is the right place to post. Should I start a new question for this and link to that question later? – yonarw Nov 22 '15 at 16:28

1 Answers1

0

After a lot more code digging I found out the problem was not related to CMake. A comment to an other question was the solution!

Turns out you have to link to pthread

-lpthread

or just

target_link_libraries(test ... pthread)

That way shared pointers work with glut. I still find it strange that this is in no way detected by the linker!

Community
  • 1
  • 1
yonarw
  • 121
  • 7