C++ basic program segmentation fault - c++

here is my CPP program
#include <iostream>
int main(int argc, char *argv[]){
return 0;
}
compiling and executing this, causes a seg fault:
[18:08 ~] > g++ test.cpp
[18:09 ~] > ./a.out
Segmentation fault
Does anybody have an idea about this issue please?
Thanks a lot for your help.
Here are some details that might be useful:
[18:13 ~] > ldd a.out
linux-vdso.so.1 => (0x00007fff3fdff000)
libstdc++.so.6 => /usr/lib/gcc/x86_64-redhat-linux/3.4.6/libstdc++.so.6 (0x00007fc8f4a53000)
libm.so.6 => /lib64/libm.so.6 (0x00007fc8f47ce000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fc8f45b8000)
libc.so.6 => /lib64/libc.so.6 (0x00007fc8f4225000)
/lib64/ld-linux-x86-64.so.2 (0x00007fc8f4ca5000)
and also gdb:
[18:15 ~] > gdb ./a.out
GNU gdb (GDB) Red Hat Enterprise Linux (7.2-60.el6)
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from ...done.
(gdb) run
Starting program: a.out
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7bd48ec in std::ios_base::Init::Init() () from /usr/lib/gcc/x86_64-redhat-linux/3.4.6/libstdc++.so.6
Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.107.el6.x86_64 libgcc-4.4.7-3.el6.x86_64
(gdb) bt
#0 0x00007ffff7bd48ec in std::ios_base::Init::Init() () from /usr/lib/gcc/x86_64-redhat-linux/3.4.6/libstdc++.so.6
#1 0x0000000000400831 in __static_initialization_and_destruction_0 (__initialize_p=1, __priority=65535) at /usr/lib/gcc/x86_64-redhat-linux/3.4.6/../../../../include/c++/3.4.6/iostream:77
#2 0x0000000000400873 in global constructors keyed to main() () at test.cpp:7
#3 0x0000000000400976 in __do_global_ctors_aux ()
#4 0x00000000004005a3 in _init ()
#5 0x00007fffffffe448 in ?? ()
#6 0x0000000000400905 in __libc_csu_init ()
#7 0x00007ffff7385c70 in __libc_start_main () from /lib64/libc.so.6
#8 0x0000000000400659 in _start ()
(gdb)
g++
[10:14 ~] > g++ -v
Reading specs from /usr/lib/gcc/x86_64-redhat-linux/3.4.6/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-languages=c,c++,f77 --disable-libgcj --host=x86_64-redhat-linux
Thread model: posix
gcc version 3.4.6 20060404 (Red Hat 3.4.6-19.el6)
and last thing
[10:25 ~] > ls /usr/lib/gcc/x86_64-redhat-linux
3.4.6
Thank you.

So apparently your problem is that your g++ installation is broken. I see from the messages that you have RHEL6, but somehow have version 3.4.6 of libstdc++.
My RHEL6 system has version 4.4.6 of gcc, libstdc++, etc. I assume that this older version of libstdc++ is related to your problem.
What versions do you have installed of gcc, g++, and libstdc++? From the other messages, it looks like you have 4.4.7, but do you happen to have multiple versions or mixed versions?
rpm -q gcc g++ libstdc++
Also, what other directories do you have under /usr/lib/gcc/x86_64-redhat-linux?
ls /usr/lib/gcc/x86_64-redhat-linux

i think that you miss something while installing g++
Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.107.el6.x86_64 libgcc-4.4.7-3.el6.x86_64

Related

Why gdb is not working for this simple hello world program?

Code (m1.cpp):
#include <iostream>
using namespace std;
int main (int argc, char *argv[])
{
cout << "running m1" << endl;
return 0;
}
GDB Version: GNU gdb (GDB) 7.6.2
Built using: g++ -g m1.cpp
Command line history:
(gdb) b main
Breakpoint 1 at 0x40087b: file m1.cpp, line 6.
(gdb) r
Starting program: .../a.out
Program received signal SIGSEGV, Segmentation fault.
0x00002aaaaaac16a0 in strcmp () from /lib64/ld-linux-x86-64.so.2
(gdb) c
Continuing.
Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists.
(gdb)
When I run without setting any breakpoints, it runs without errors.
As requested:
(gdb) bt
#0 strcmp () from /lib64/ld-linux-x86-64.so.2
#1 in check_match.12104 () from /lib64/ld-linux-x86-64.so.2
#2 in do_lookup_x () from /lib64/ld-linux-x86-64.so.2
#3 in _dl_lookup_symbol_x () from /lib64/ld-linux-x86-64.so.2
#4 in _dl_relocate_object () from /lib64/ld-linux-x86-64.so.2
#5 in dl_main () from /lib64/ld-linux-x86-64.so.2
#6 in _dl_sysdep_start () from /lib64/ld-linux-x86-64.so.2
#7 in _dl_start () from /lib64/ld-linux-x86-64.so.2
#8 in _start () from /lib64/ld-linux-x86-64.so.2
#9 in ?? ()
I was able to replicate the OP's observed behavior (using the same compile and getting the same backtrace). The behavior was persistent across a range GDBs and GCCs. I noticed that the symptom goes away when I unset SHELL. In my normal environment I use tcsh (version 1.15.00). If SHELL is set, then (I believe) gdb launches using tcsh. If I unset SHELL, gdb launches using sh. This is enough for me to make forward progress. I don't have a crisp explanation for what would be different in tcsh to manifest the issue but if others have the same behavior, it may shed more light on the issue.
I checked that in my GNU gdb version 7.11.1. It worked really fine in it.
I first compiled the same program and built it using:
g++ -g m1.cpp
Then, ran the executable in the gdb as follows:
gdb -q ./a.out
And did the same things you mentioned. It worked fine.
Update your gdb, and check that again and let know.

log4cxx: Segmentation fault in apr_pool_create_ex

I need to use log4cxx for a C++ project. However I fail to understand the basic setup of this library. Here is my minimal attempt:
$ cat logger.cpp
#include <log4cxx/logger.h>
#include <log4cxx/propertyconfigurator.h>
#include <log4cxx/helpers/properties.h>
static log4cxx::LoggerPtr ptr;
int main()
{
log4cxx::helpers::Properties prop;
prop.setProperty("log4j.rootLogger","DEBUG, A1");
prop.setProperty("log4j.appender.A1","org.apache.log4j.ConsoleAppender");
prop.setProperty("log4j.appender.A1.layout","org.apache.log4j.PatternLayout");
prop.setProperty("log4j.appender.A1.layout.ConversionPattern","%d{ABSOLUTE} %-5p [%c] %m%n");
log4cxx::PropertyConfigurator::configure(prop);
ptr = log4cxx::Logger::getLogger("API");
LOG4CXX_INFO(ptr , "test_info");
return 0;
}
I then compile it using:
$ g++ -g -o logger logger.cpp -llog4cxx
It fails with:
$ gdb ./logger
[...]
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff5f69dc9 in apr_pool_create_ex () from /lib64/libapr-1.so.0
Missing separate debuginfos, use: debuginfo-install apr-1.5.1-3.fc21.x86_64 apr-util-1.5.4-1.fc21.x86_64 cyrus-sasl-lib-2.1.26-19.fc21.x86_64 expat-2.1.0-10.fc21.x86_64 libdb-5.3.28-9.fc21.x86_64 libgcc-4.9.2-6.fc21.x86_64 libstdc++-4.9.2-6.fc21.x86_64 libuuid-2.25.2-3.fc21.x86_64 log4cxx-0.10.0-17.fc21.x86_64 nspr-4.10.8-1.fc21.x86_64 nss-3.19.1-1.0.fc21.x86_64 nss-softokn-freebl-3.19.1-1.0.fc21.x86_64 nss-util-3.19.1-1.0.fc21.x86_64 openldap-2.4.40-3.fc21.x86_64 zlib-1.2.8-7.fc21.x86_64
(gdb) bt
#0 0x00007ffff5f69dc9 in apr_pool_create_ex () from /lib64/libapr-1.so.0
#1 0x00007ffff7b26b58 in log4cxx::helpers::Pool::Pool() () from /lib64/liblog4cxx.so.10
#2 0x00007ffff7ae06ea in log4cxx::helpers::MutexException::formatMessage(int) () from /lib64/liblog4cxx.so.10
#3 0x00007ffff7ae0786 in log4cxx::helpers::MutexException::MutexException(int) () from /lib64/liblog4cxx.so.10
#4 0x00007ffff7b4a310 in log4cxx::helpers::synchronized::synchronized(log4cxx::helpers::Mutex const&) () from /lib64/liblog4cxx.so.10
#5 0x00007ffff7b5d9c8 in log4cxx::WriterAppender::close() () from /lib64/liblog4cxx.so.10
#6 0x00007ffff7ac979c in log4cxx::ConsoleAppender::~ConsoleAppender() () from /lib64/liblog4cxx.so.10
#7 0x00007ffff7ac98b9 in log4cxx::ConsoleAppender::~ConsoleAppender() () from /lib64/liblog4cxx.so.10
#8 0x00007ffff7aba247 in log4cxx::helpers::AppenderAttachableImpl::~AppenderAttachableImpl() () from /lib64/liblog4cxx.so.10
#9 0x00007ffff7b0494c in log4cxx::Logger::~Logger() () from /lib64/liblog4cxx.so.10
#10 0x00007ffff7b388b4 in log4cxx::spi::RootLogger::~RootLogger() () from /lib64/liblog4cxx.so.10
#11 0x00007ffff7b0429a in log4cxx::Logger::~Logger() () from /lib64/liblog4cxx.so.10
#12 0x00007ffff7b04429 in log4cxx::Logger::~Logger() () from /lib64/liblog4cxx.so.10
#13 0x0000000000401d6e in log4cxx::helpers::ObjectPtrT<log4cxx::Logger>::~ObjectPtrT (this=0x6031a0 <ptr>, __in_chrg=<optimized out>) at /usr/include/log4cxx/helpers/objectptr.h:100
#14 0x00007ffff6e38392 in __run_exit_handlers () from /lib64/libc.so.6
#15 0x00007ffff6e383e5 in exit () from /lib64/libc.so.6
#16 0x00007ffff6e1efe7 in __libc_start_main () from /lib64/libc.so.6
#17 0x0000000000401599 in _start ()
What is so fundamentally wrong to using a global variable for the logger ? It does make sense to me to have a singleton pattern here.
System is: Fedora 21 with:
$ rpm -qv log4cxx
log4cxx-0.10.0-17.fc21.x86_64
and:
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.9.2/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --enable-plugin --enable-initfini-array --disable-libgcj --with-isl=/builddir/build/BUILD/gcc-4.9.2-20150212/obj-x86_64-redhat-linux/isl-install --with-cloog=/builddir/build/BUILD/gcc-4.9.2-20150212/obj-x86_64-redhat-linux/cloog-install --enable-gnu-indirect-function --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 4.9.2 20150212 (Red Hat 4.9.2-6) (GCC)
An even more minimal attempt will crash in exactly the same way:
#include <log4cxx/logger.h>
#include <log4cxx/basicconfigurator.h>
static log4cxx::LoggerPtr ptr;
int main()
{
log4cxx::BasicConfigurator::configure();
ptr = log4cxx::Logger::getLogger("API");
return 0;
}
The ultimate reasons for this silly debacle are very deep-seated, having to do with fundamental design flaws in log4cxx (starting with the misguided attempt - and philosophy - to make C++ code "look and feel and work like Java").
The proximate reason is that the destructor of the Logger held by the global LoggerPtr ptr is invoked too late. By that time, the APR library (on which the log4cxx codebase depends) will have been dismissed, and consequently the synchronized::synchronized constructor call (#4 in the stack trace) will necessarily fail - after which some kind of crash becomes inevitable. Why the code has to jump through such hoops to release resources is a saga unto itself, and not worth going into here.
The problem, as such, has to do with the order of static de-initializations: The APR library is dismissed "too early" because it's actually initialized, through a static singleton, too late (in the example code, when the LoggerPtr is actually given a Logger to hold).
The example code can be "fixed" by adding this statement before exiting main() (e.g. before the return 0;):
ptr = 0;
This will have the effect of invoking the complex resource release sequence while the APR library is still "alive".
A more general "solution" would involve controlling the lifetime of the APR library appropriately. The log4cxx codebase has static Meyers singletons scattered all over, including one to wrap calls to apr_initialize() and apr_terminate() for the APR library, but the well known "static initialization order fiasco" makes it difficult to arrange that particular singleton to be the "oldest". (It would have to be invoked from the constructors of every other singleton.) The practical "answer", therefore, is to keep the APR library alive forever, by an extra call to apr_initialize() - say, early in main() - not balanced with a matching apr_terminate(), and leaking that particular resource at program termination.
Note that the bug can be triggered in other ways. And, in fact, this bug became a show-stopper for subsequent releases, and that may be why the entire log4cxx project basically died a decade ago.

GCC __static_initialization_and_destruction_0 (__initialize_p=1, __priority=65535)

Pursuant to the post, Standalone functions/data in C++, I proceeded to put my "common data" in an anonymous namespace as below and everything worked great on Windows (Vista 64 bit) on VS 2005/2008/2010
namespace {
...
static std::string mystrings[] = {
str1,
str2,
...,
strN
};
...
}
namespace mynamesp {
...
use mystrings[] here..
...
}
But on Linux (so far tested RHEL5 built with GCC-4.1.2) I promptly got a segmentation fault.
$>myprog
Segmentation fault
$>gdb myprog
GNU gdb Fedora (6.8-27.el5)
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu"...
(gdb) r
Starting program: <path/to>/myprog
[Thread debugging using libthread_db enabled]
[New Thread 0x2b8901a9da60 (LWP 32710)]
Program received signal SIGSEGV, Segmentation fault.
0x0000003e4ce9c928 in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string ()
from /usr/lib64/libstdc++.so.6
(gdb) bt
#0 0x0000003e4ce9c928 in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string ()
from /usr/lib64/libstdc++.so.6
#1 0x00002b88ffde482b in __static_initialization_and_destruction_0 (__initialize_p=1, __priority=65535)
at <path/to>/mysource.cpp:140
#2 0x00002b88ffde4d65 in global constructors keyed to _ZN91_GLOBAL__N__underscore_separated_path_to_mysource.cpp_00000000_6994A7DA2_1E () at <path/to>/mysource.cpp:12139
#3 0x00002b890011a296 in __do_global_ctors_aux ()
from <path/to/libs>/debug/libmylibd.so
#4 0x00002b88ffcd7f33 in _init () from <path/to/libs>/debug/libmylibd.so
#5 0x00002b8901672e40 in ?? ()
#6 0x000000326940d22b in call_init () from /lib64/ld-linux-x86-64.so.2
#7 0x000000326940d335 in _dl_init_internal () from /lib64/ld-linux-x86-64.so.2
#8 0x0000003269400aaa in _dl_start_user () from /lib64/ld-linux-x86-64.so.2
#9 0x0000000000000001 in ?? ()
#10 0x0000000000000000 in ?? ()
(gdb)
Line 140 in the backtrace call stack item #1 basically points to the end of my array of strings definition. I've seen some others get this error; but no obvious fixes. Appreciate any thoughts/ideas/corrections as always. Thanks!
Your problem could be releated to a static initialization order fiasco.
This happens when you initialize a static variable using another static variable. When the latter one has not been initialized yet, then the first one is using a non-initialized variable for its initialization.
The root cause is that the order, in which static variables are initialized, is undefined.
Further reading:
https://isocpp.org/wiki/faq/ctors#static-init-order
A typical workaround would be to wrap the static variables inside a function. Example:
T& GetStaticA() {
T static_var_A; // <--initialization here
return A;
}
T static_var_B = GetStaticA(); // <-- static_var_A is guaranteed to be initialized
I had this problem and it turned out that in my compiling line I had missed the final output file in the linking.
g++ main.o logger.o timer.o keyboard.o -o main -lSDL -lSDL_image -lSDL_ttf -Wall
should have been
g++ main.o logger.o timer.o keyboard.o drawer.o -o main -lSDL -lSDL_image -lSDL_ttf -Wall
(Notice the now inclusion of drawer.o?)
It was easy to miss because my actual bash compilation script had many more lines to it.

GDB Core dump: Recover argc argv values after crash

Is possible to recover the exact values of argv and argc parameters of a main after the application crashed?
I need to use only the application core-dump and gdb debugger on Linux.
Yes, if application was compiled with debug info. Open core dump in gdb and find frame containing main function. Then go to this frame and print values of argv and argc. Here is sample gdb session.
[root#localhost ~]# gdb ./a.out core.2020
GNU gdb (GDB) 7.2
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /root/a.out...done.
[New Thread 2020]
warning: Can't read pathname for load map: Input/output error.
Reading symbols from /usr/lib/libstdc++.so.6...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libstdc++.so.6
Reading symbols from /lib/libm.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/libm.so.6
Reading symbols from /lib/libgcc_s.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/libgcc_s.so.1
Reading symbols from /lib/libc.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/ld-linux.so.2
Core was generated by `./a.out'.
Program terminated with signal 6, Aborted.
#0 0x0027b424 in __kernel_vsyscall ()
(gdb) bt
#0 0x0027b424 in __kernel_vsyscall ()
#1 0x00b28b91 in raise () from /lib/libc.so.6
#2 0x00b2a46a in abort () from /lib/libc.so.6
#3 0x007d3397 in __gnu_cxx::__verbose_terminate_handler() () from /usr/lib/libstdc++.so.6
#4 0x007d1226 in ?? () from /usr/lib/libstdc++.so.6
#5 0x007d1263 in std::terminate() () from /usr/lib/libstdc++.so.6
#6 0x007d13a2 in __cxa_throw () from /usr/lib/libstdc++.so.6
#7 0x08048940 in main (argv=1, argc=0xbfcf1754) at test.cpp:14
(gdb) f 7
#7 0x08048940 in main (argv=1, argc=0xbfcf1754) at test.cpp:14
14 throw std::runtime_error("123");
(gdb) p argv
$1 = 1
(gdb) p argc
$2 = (char **) 0xbfcf1754
(gdb)
Looks like you need to start from the basics..!!
compiler your application code with -g flag, make sure you dont strip it.
Say if I wanted to compile hello.c
gcc -c -g hello.c -o hello.o
gcc hello.o -o hello
now if you dont want to debug
ulimit -c unlimited
./hello
when the application crashes a core file wiil be generated.
To examine the core file
"gdb ./hello core.$$$" this will list you your stack.
you can also choose to debug the image
gdb hello
There are a lot of stuffs over the internet about GDB, do go through them.

c++ Segmentation fault occurs when executing simple opengl tutorial

I am trying to use opengl to render objects. Although the simple tutorial example http://www.videotutorialsrock.com/opengl_tutorial/get_opengl_setup_linux/text.phpcompiles without error when I attempt to execute the program it crashes i.e. the dreaded segmentation fault.
System
Suse Linux 11.2 64 bit
g++ (SUSE Linux) 4.4.1 [gcc-4_4-branch revision 150839]
Eclipse IDE Build id: 20100218-1602
according to yast 64bit freeglut and freeglut-devel are installed:
090301-3.1
libglut.so.3()(64bit)
mesaglut
freeglut = 090301-3.1
freeglut(x86-64) = 090301-3.1
Is this a 64 bit vs 32 bit issue? I have had the same example program working under suse 11.1 32bit.
Any help would be appreciated
Okay .Car has been pushed back up the hill and loose nut tightened.
Below is output from gdb:
~/workspaceNew/cubetest/Default> gdb
GNU gdb (GDB) SUSE (6.8.91.20090930-2.4)
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-suse-linux".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
(gdb) run ./cubetest
Starting program: /home/mark/workspaceNew/cubetest/Default/cubetest ./cubetest
Missing separate debuginfo for /lib64/ld-linux-x86-64.so.2
Try: zypper install -C "debuginfo(build-id)=591af1afa33f255704fb6a60859b93d00e205302"
Missing separate debuginfo for /usr/lib64/libglut.so.3
Try: zypper install -C "debuginfo(build-id)=768ca903dcb7f43b3a9f4cdc368d9469e44c14f7"
Missing separate debuginfo for /usr/lib64/libGLU.so.1
Try: zypper install -C "debuginfo(build-id)=a76155345771ffa204fc8a1cf63b3eca7ce1ae86"
Missing separate debuginfo for /usr/lib64/libstdc++.so.6
Try: zypper install -C "debuginfo(build-id)=62220ad5c8941afb5d332c0c47d32f8beec8ac50"
Missing separate debuginfo for /lib64/libm.so.6
Try: zypper install -C "debuginfo(build-id)=57fc1891d8d9f419fb8c7fc06a8285563b53a47e"
Missing separate debuginfo for /lib64/libgcc_s.so.1
Try: zypper install -C "debuginfo(build-id)=0206e11fa8ca0db0633073adcbf1349a7871e1dc"
Missing separate debuginfo for /lib64/libc.so.6
Try: zypper install -C "debuginfo(build-id)=b5ded0f18b9b11c5cd6b26387426ead562c332f8"
Missing separate debuginfo for /usr/lib64/libGL.so.1
Try: zypper install -C "debuginfo(build-id)=cb5a2f35ed226cb1c92f063d03b204ec24b100a6"
Missing separate debuginfo for /usr/lib64/libX11.so.6
Try: zypper install -C "debuginfo(build-id)=5fa84adc30db95abcbaea20ed7ec1c8dd94dfff2"
Missing separate debuginfo for /usr/lib64/libXxf86vm.so.1
Try: zypper install -C "debuginfo(build-id)=4ffef26febce96a31b2d5df10538bb6dba112e3b"
Missing separate debuginfo for /usr/lib64/libXext.so.6
Try: zypper install -C "debuginfo(build-id)=79d5f89d13f43ff26518ec8dd46fecfad911f968"
Missing separate debuginfo for /usr/lib64/libXdamage.so.1
Try: zypper install -C "debuginfo(build-id)=650d88fdf900daadd8ba1c9134c21b4e68b560bc"
Missing separate debuginfo for /usr/lib64/libXfixes.so.3
Try: zypper install -C "debuginfo(build-id)=6495446f04c2f9a4fa3021f7322d6f12c4017305"
Missing separate debuginfo for /usr/lib64/libdrm.so.2
Try: zypper install -C "debuginfo(build-id)=dc7d692fb4a36fa25fc513b2e36a614f5e4efc48"
Missing separate debuginfo for /lib64/libpthread.so.0
Try: zypper install -C "debuginfo(build-id)=7bcbabc9da24424f1f5ef7be77b575fd3d796288"
[Thread debugging using libthread_db enabled]
Missing separate debuginfo for /lib64/libdl.so.2
Try: zypper install -C "debuginfo(build-id)=44e66ebae672563bd496f290e08d316bc3bf0ac7"
Missing separate debuginfo for /usr/lib64/libxcb.so.1
Try: zypper install -C "debuginfo(build-id)=54a77c10d44b40080d6d8e65d277ccb7ab2a5b4a"
Missing separate debuginfo for /lib64/librt.so.1
Try: zypper install -C "debuginfo(build-id)=c663e79551b37d4c0c9bc93b252b917bfdedb150"
Missing separate debuginfo for /usr/lib64/libXau.so.
Try: zypper install -C "debuginfo(build-id)=72341bb9d8a1ad2ca2bbced007f3a785121aac28"
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7bbeaf7 in fgOpenWindow () from /usr/lib64/libglut.so.3
(gdb) bt
#0 0x00007ffff7bbeaf7 in fgOpenWindow () from /usr/lib64/libglut.so.3
#1 0x00007ffff7bbd0fc in fgCreateWindow () from /usr/lib64/libglut.so.3
#2 0x00007ffff7bbe3d2 in glutCreateWindow () from /usr/lib64/libglut.so.3
#3 0x0000000000402c45 in main (argc=2, argv=<value optimized out>) at ../cube/main.cpp:191
Well, all I can say is that the example compiles and runs on Ubuntu 10.04 x64. I did have to add -lGLU to LIBS in the makefile, but since it already compiles for you, I guess that's not very helpful.
Your debug info does not provide a lot of insight; try installing -dbg packages for the relevant libraries.