illegal instruction (core dumped)

[damnednforsaken]

Ok, so new to this forum posting thing(long time listener first time caller)...

I have been trying to setup sfml 2.0 on a Oracle Vm running, Ubuntu 12.04.
Clean installation. I follow the example perfectly,
http://www.sfml-dev.org/tutorials/2.0/start-linux.php
compiles correctly/link good. with g++/emacs
But when I try to run it from the terminal I get, illegal instruction (core dumped).

So that is the problem, I'm not sure what it means... stackframe something messed up?

I first tried this as well with the same above but with Ubuntu sever 13ish.
But failed to load the sample project.. after compiling and linking with libs fine, but when trying
to run... resulted in a seg fault...

My rig is a y410p Lenevo i7 4th, nvida 755mm, Win7.

[Jesper Juhl]

One way to get a "illegal instruction" crash is if you tell the compiler to target a CPU that is newer/different than what you actually have and it then chooses to emit instructions that your CPU can't execute. For example if you build with "g++ -march=core2" and then try to run the program on a i686 CPU.
I recently ran into this since I had built my code with "-march=corei7-avx" (which is what I have) but then ran the program in a Virtualbox VM and discovered the hard way that the virtual CPU that Virtualbox gave me was a plain i7 (without the AVX instructions). Rebuilding for a plain "corei7" and my program ran fine in the VM. So make sure your compiler is not targeting a CPU with instructions that your actual hardware (or virtual hardware) does not implement.

[eXpl0it3r]

Can you provide the call stack?

Make sure you have graphics acceleration (and maybe a few other options) activated.

[damnednforsaken]

Ok, thanks for the help foremost... Yeah, cus I have no idea what is happening.
@Jesper, Ok I am looking into the how my Oracle VM emulates my processor. Thanks for that intuition.
@ exploiter, Ok messing around with the VM's settings to see if I can get it to do something... nothing yet.
(I should just reinstall linux on my spare drive.. to see if I can get it to work on that in the mean time)

Um as far as providing the call stack, well I will try, Never done this or anything like it before, So should I use strace,lsof,or ltrace and copy paste...

Been long time since wrote on a forum, so don't remember how separate code etc.. and didn't want to elongate thread so here is my attempt at getting my call stack.. attached, using strace.

[eXpl0it3r]

Uhm at best you run your application through GDB and when it crashes you enter "trace" to get the call stack.

[Jesper Juhl]

You can get the back trace from the core dump:

$ gdb app core
Then enter "bt" and press enter

If the process was still alive then you could use the "pstack" utility to get a back trace or attach gdb to the running process and get it that way.

[Jesper Juhl]

Try these things (only changing one thing at a time initially):

- Build your code for the lowest common (or close) denominator CPU that your machine can run (for 64bit try "-march=core2", for 32bit try "-march=i686"). Does that work?

- Raise your compilers warning level (GCC/Clang: -Wall -Wextra , MS VS: /W4). Fix (don't just work around) the things that the compiler complains about. Does it work now?

- Try building with/without optimization enabled (aka release/debug mode) also try different optimization levels. Does that make a difference?

- Try a different compiler; GCC, clang, the Intel compiler, Solaris studio, whatever. Does the new compiler point out new problems/warnings? If so, fix them. Does the build with the new compiler make it work?

- Run your program through valgrind and fix whatever it complains about (if anything). Does it work now?

- Build your code with "address sanitizer" (available in modern clang and GCC). Fix what it complains about. Does it work now?

- Run clang-analyzer over your code. Fix relevant/real bugs it finds (it does still have a fair amount of false positives unfortunately). Better now?

- Run your code through cppcheck and fix what it finds (again a false positive warning is in order). Found the problem yet?

- Step through the code in a debugger and see if you can spot the bug (sometimes reading through a disassembly of the code around the faulting instruction can be enlightening - what is the faulting instruction BTW?). Did you find the problem now?

The above is a short list of the things I would start with if it was my bug.
Looking forward to answers to the questions above

[damnednforsaken]

Damn I had posted the stack trace per ....Jesper Juhl, and Exploits suggestions... I will have to do it again on other os.

Ok, well.
I just verified my process of setting up sfml2.0, via a fresh install on ubuntu12.04 on clean drive.
Following the sfml, 2.0 setup from onlyakiss and adding the libudev-dev, and build-essential libraries does quickly enough.
Had found a forum thread saying (possible)problem about the glut 1.5 but can't seem to find it again.
Don't know that I needed to but, Installed freeglut3-dev too.

Now to get the stack trace...

[damnednforsaken]

(gdb) trace
Tracepoint 1 at 0xb48201a3

(gdb) bt
#0  0xb48201a3 in ?? ()
#1  0x083602c4 in ?? ()
(gdb) trace
Tracepoint 1 at 0xb48201a3

Ok here is what I was pretty much getting earlier when I tried to do start this -this morning.
I had found a way to get the cores via some core-generate command,
that I couldn't remember now but it had the same info as these...

not really sure what it means now that I have found out that it is this/these stack references?

(gdb) bt full
#0  0xb48201a3 in ?? ()
No symbol table info available.
#1  0x083602c4 in ?? ()
No symbol table info available.
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

(gdb) info threads
  Id   Target Id         Frame
* 1    Thread 0xb78d2700 (LWP 2170) "sfml-app" 0xb48201a3 in ?? ()


Yes thank you Jepsper Juhl and Exploiter for help so far.
@Jesper thank you for the laundry list of stuff to check :p
Seriously I'm sure I will have to use he advice it in more than this endeavour.

[yhoyhoj]

First sorry for my bad English and for the big post.
English is not my main language and I have not found a "spoiler" or similar function

I have the same problem here with an Archlinux guest on Oracle Virtuablox VM. I'm using SFML 2.0
I have to report a weird thing : my program works well on another PC with the same VM (imported from my main PC) provided that 3D acceleration is disabled.
The problem is so strange that it may be out of the SFML scope but I will provide everyhting I have.

I will stick to the fact to I won't be able to us 3D acceleration, so everything that follows is without that.

Here is the exact error, on any SFML app (mine as well as examples one) without 3D acceleration:

libGL error: pci id for fd 4: 80ee:beef, driver (null)
OpenGL Warning: Failed to connect to host. Make sure 3D acceleration is enabled for this VM.
libGL error: core dri or dri2 extension not found
libGL error: failed to load driver: vboxvideo
Illegal instruction (core dumped)
 

So i tried GDB, but it didn't help :

(gdb) run
...
libGL error: pci id for fd 4: 80ee:beef, driver (null)
OpenGL Warning: Failed to connect to host. Make sure 3D acceleration is enabled for this VM.
libGL error: core dri or dri2 extension not found
libGL error: failed to load driver: vboxvideo
Program received signal SIGILL, Illegal instruction.
0xb40a10a4 in ?? ()
(gdb) bt
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x48:
#0  0xb40a10a4 in ?? ()
Cannot access memory at address 0x48
(gdb) frame 0
#0  0xb40a10a4 in ?? ()
(gdb) info frame
Stack level 0, frame at 0x4c:
 eip = 0xb40a10a4; saved eip = <error: Cannot access memory at address 0x48> called by frame at frame.c:472: internal-error: get_frame_id: Assertion `fi->this_id.p' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) n
 

Then I tried valgrind and after a memory error report, the SFML window opens and displays everything correctly. No more Illegal Instruction error. I don't know how valgrind works so I can't tell if it's normal or not.
Here is the memory error reported by valgrind :

> valgrind ./game
==372== Memcheck, a memory error detector
==372== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==372== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info
==372== Command: ./game
==372==
libGL error: pci id for fd 4: 80ee:beef, driver (null)
==372== Conditional jump or move depends on uninitialised value(s)
==372==    at 0x4FBCD10: crGetProcName (in /usr/lib/VBoxOGLcrutil.so)
==372==    by 0x4EC7964: ??? (in /usr/lib/VBoxOGL.so)
==372==    by 0x4EC7EC4: ??? (in /usr/lib/VBoxOGL.so)
==372==    by 0x4EB86EB: ??? (in /usr/lib/VBoxOGL.so)
==372==    by 0x400ECBD: call_init.part.0 (in /usr/lib/ld-2.19.so)
==372==    by 0x400EDB3: _dl_init (in /usr/lib/ld-2.19.so)
==372==    by 0x4012DBD: dl_open_worker (in /usr/lib/ld-2.19.so)
==372==    by 0x400EB65: _dl_catch_error (in /usr/lib/ld-2.19.so)
==372==    by 0x40125B3: _dl_open (in /usr/lib/ld-2.19.so)
==372==    by 0x4855CBB: ??? (in /usr/lib/libdl-2.19.so)
==372==    by 0x400EB65: _dl_catch_error (in /usr/lib/ld-2.19.so)
==372==    by 0x485637B: ??? (in /usr/lib/libdl-2.19.so)
==372==
OpenGL Warning: Failed to connect to host. Make sure 3D acceleration is enabled for this VM.
libGL error: core dri or dri2 extension not found
libGL error: failed to load driver: vboxvideo
 

I have done some tests with 3D acceleration enabled but had not enough time to finish, I have the same errors on my second PC. I did try valgrind earlier but I don't remember it helped.

libGL error: pci id for fd 4: 80ee:beef, driver (null)
OpenGL Warning: glFlushVertexArrayRangeNV not found in mesa table
OpenGL Warning: glVertexArrayRangeNV not found in mesa table
OpenGL Warning: glCombinerInputNV not found in mesa table
OpenGL Warning: glCombinerOutputNV not found in mesa table
OpenGL Warning: glCombinerParameterfNV not found in mesa table
OpenGL Warning: glCombinerParameterfvNV not found in mesa table
OpenGL Warning: glCombinerParameteriNV not found in mesa table
OpenGL Warning: glCombinerParameterivNV not found in mesa table
OpenGL Warning: glFinalCombinerInputNV not found in mesa table
OpenGL Warning: glGetCombinerInputParameterfvNV not found in mesa table
OpenGL Warning: glGetCombinerInputParameterivNV not found in mesa table
OpenGL Warning: glGetCombinerOutputParameterfvNV not found in mesa table
OpenGL Warning: glGetCombinerOutputParameterivNV not found in mesa table
OpenGL Warning: glGetFinalCombinerInputParameterfvNV not found in mesa table
OpenGL Warning: glGetFinalCombinerInputParameterivNV not found in mesa table
OpenGL Warning: glDeleteFencesNV not found in mesa table
OpenGL Warning: glFinishFenceNV not found in mesa table
OpenGL Warning: glGenFencesNV not found in mesa table
OpenGL Warning: glGetFenceivNV not found in mesa table
OpenGL Warning: glIsFenceNV not found in mesa table
OpenGL Warning: glSetFenceNV not found in mesa table
OpenGL Warning: glTestFenceNV not found in mesa table
libGL error: core dri or dri2 extension not found
libGL error: failed to load driver: vboxvideo
Segmentation fault (core dumped)
 

GDB:

>gdb game
(gdb) run
...
Program received signal SIGSEGV, Segmentation fault.
0xb7cc22f1 in __printf_fp () from /usr/lib/libc.so.6
(gdb) bt
#0  0xb7cc22f1 in __printf_fp () from /usr/lib/libc.so.6
#1  0xb7cbc0a7 in vfprintf () from /usr/lib/libc.so.6
#2  0xb7cde812 in vsprintf () from /usr/lib/libc.so.6
#3  0xb7cc517f in sprintf () from /usr/lib/libc.so.6
#4  0xb7203b09 in ?? () from /usr/lib/VBoxOGLpackspu.so
#5  0xb74c5e74 in ?? () from /usr/lib/xorg/modules/dri/vboxvideo_dri.so
#6  0xb7f76100 in ?? () from /usr/lib/libsfml-window.so.2
#7  0xb7f765d6 in sf::GlResource::GlResource() ()
   from /usr/lib/libsfml-window.so.2
   #8  0xb7f77c2d in sf::Window::Window() () from /usr/lib/libsfml-window.so.2
   #9  0xb7fb6531 in sf::RenderWindow::RenderWindow(sf::VideoMode, sf::String const&, unsigned int, sf::ContextSettings const&) () from /usr/lib/libsfml-graphics.so.2
   #10 0x08049978 in __cxx_global_var_init3 () at main.cpp:7
   #11 0x08049a2a in global constructors keyed to a () at main.cpp:41
   #12 0x0804dec2 in __libc_csu_init ()
   #13 0xb7c9192a in __libc_start_main () from /usr/lib/libc.so.6
   #14 0x08049a50 in _start ()
(gdb)
 

That's all. I hope this can help.