Site navigation

HelloWorld crash on Ubuntu 12.04

Linux
#1

Hi,
I am familiar with Juce on Windows, but not on Linux. I am compiling and running the HelloWorld app (from extras/example projects) on Ubuntu 12.04 installed on virtualbox. The app crashes with a “Illegal instruction (core dumped)” meassge as soon as the mouse is moved on top of the app area. The same crash (in the same line in the code) happens also with the Introjucer app. I didn’t try other Juce-based apps yet.

Some more info:

Linux ver:

gdb stacktrace:

[code]Reading symbols from /home/itamark/juce/JUCE/extras/example projects/Builds/Linux/build/HelloWorld…done.
(gdb) run
Starting program: /home/itamark/juce/JUCE/extras/example projects/Builds/Linux/build/HelloWorld
[Thread debugging using libthread_db enabled]
Using host libthread_db library “/lib/i386-linux-gnu/libthread_db.so.1”.
JUCE v2.1.1
[New Thread 0xb7fe7b40 (LWP 21413)]

Program received signal SIGILL, Illegal instruction.
juce::LinuxComponentPeer::getEventTime (t=6762279) at …/…/…/…/modules/juce_gui_basics/native/juce_linux_Windowing.cpp:2290
2290 const int64 thisMessageTime = t;
(gdb) bt
#0 juce::LinuxComponentPeer::getEventTime (t=6762279) at …/…/…/…/modules/juce_gui_basics/native/juce_linux_Windowing.cpp:2290
#1 0x082499c0 in juce::LinuxComponentPeer::getEventTime (t=…)
at …/…/…/…/modules/juce_gui_basics/native/juce_linux_Windowing.cpp:2284
#2 0x0822c2ea in juce::LinuxComponentPeer::handleEnterNotifyEvent (this=0x8392a28, enterEvent=…)
at …/…/…/…/modules/juce_gui_basics/native/juce_linux_Windowing.cpp:1556
#3 0x0822b6b9 in juce::LinuxComponentPeer::handleWindowMessage (this=0x8392a28, event=…)
at …/…/…/…/modules/juce_gui_basics/native/juce_linux_Windowing.cpp:1291
#4 0x0822a0af in juce::LinuxComponentPeer::windowMessageReceive (event=…)
at …/…/…/…/modules/juce_gui_basics/native/juce_linux_Windowing.cpp:846
#5 0x080bf78f in juce::InternalMessageQueue::dispatchNextXEvent ()
at …/…/…/…/modules/juce_events/native/juce_linux_Messaging.cpp:174
#6 0x080bf3f7 in juce::InternalMessageQueue::dispatchNextEvent (this=0x8386840)
at …/…/…/…/modules/juce_events/native/juce_linux_Messaging.cpp:93
#7 0x080bdeb0 in juce::MessageManager::dispatchNextMessageOnSystemQueue (returnIfNoPendingMessages=false)
at …/…/…/…/modules/juce_events/native/juce_linux_Messaging.cpp:388
#8 0x080badab in juce::MessageManager::runDispatchLoopUntil (this=0x83867a8, millisecondsToRunFor=-1)
at …/…/…/…/modules/juce_events/messages/juce_MessageManager.cpp:115
#9 0x080bad01 in juce::MessageManager::runDispatchLoop (this=0x83867a8)
at …/…/…/…/modules/juce_events/messages/juce_MessageManager.cpp:96
#10 0x081f90b6 in juce::JUCEApplication::main () at …/…/…/…/modules/juce_gui_basics/application/juce_Application.cpp:241
#11 0x081f92a3 in juce::JUCEApplication::main (argc=1, argv=0xbffff364)
at …/…/…/…/modules/juce_gui_basics/application/juce_Application.cpp:296
#12 0x0804ce54 in main (argc=1, argv=0xbffff364) at …/…/Source/Main.cpp:116
(gdb) [/code]

Any ideas?

Thanks.

#2

Well that’s one’s pretty bizarre! I also use a similar distro, and have never had a problem. And nobody else has reported anything like this… Looking at that code, I can’t see anything at all fishy, especially at the line where it’s crashing - that’s just a straightforward value copy (??)

#3

If it helps, when I run the Introjucer, I get the following error:

[quote]ERROR: X returned BadMatch (invalid parameter attributes) for operation X_ConfigureWindow
ERROR: X returned BadMatch (invalid parameter attributes) for operation X_ConfigureWindow
Illegal instruction (core dumped)[/quote]
(the gdb stack is the same)

Can it have something to do with virtualization in the BIOS (the Linux machine is a virtualbox guest)?
I am asking because when I try to launch a 64bit Linux machine, I get the following message from virtualbox:

[quote]VT-x/AMD-V hardware acceleration has been enabled, but is not operational. Your 64-bit guest will fail to detect a 64-bit CPU and will not be able to boot.
Please ensure that you have enabled VT-x/AMD-V properly in the BIOS of your host computer.[/quote]

However, the 32bit machine (where the JUCE issue is happening) runs ok.

(btw, JUCE is great!)

#4

No - I use Parallels myself, and used to use VirtualBox.

I’m really stumped by this, I just can’t think what it could do doing!

#5

You likely compiled the code for an architecture your guest is not able to emulate.
SIGILL means illegal instruction. This means that your compiler emitted an instruction your virtual host can not execute.
Try to compile with -m32 (for example), or -march=.

Also, if I were you, I would check your kernel as SIGILL is usually emulated by the kernel if the CPU does not support it, if your does not, then you need to set the right configure option for that in your kernel.

#6

Ok, thank you for the replies.

I’ve compiled the same apps on a different machine but with same config - win 7 host and Ubuntu 12.04 guest, and it works just fine. So I guess it’s a problem specific to the first machine.

I will try and report.

#7

I am far from being an assembly/architechture guru, so forgive me for any inaccuracies.

Indeed, as suggested by X-Ryl669, the reason seems to be instructions not supported by the CPU or more correctly, by the CPU/Virtualbox combination.
Both machines run Ubuntu 32bit guest on Windows 7 host. On the PC where the problem occurs, the CPU is Intel i5-3470, and line 2290 from file modules\juce_gui_basics\native\juce_linux_Windowing.cpp,

is translated to 2 instructions vmovd and vmovq. On the PC where the problem does not occur, the CPU is Intel i5-3210M, and the same line is translated to different instructions movd and movq.
The problem is solved if I manually change the compiler flag “march” from “native” to “core2”.

I am not sure if the cause is the difference in the CPU (I find it unlikely), or the virtualizaion issue I mentioned in former message - so any other insight is welcomed.

#8

Very odd. I’m no expert on gcc’s architecture flag, but the idea that setting arch=native would create instructions that won’t run on the native processor is pretty disturbing!

#9

I found that the best way (especially in virtual machines) is not to set that flag at all for debugging and let GCC decide.

Also the default flag that’s set by introjucer is for 32bits only (i think it was pentium pro?) and it doesn’t work on x64 systems, this is the Codeblocks exporter that I use on Linux, there is a lot more wrong with that exporter on linux (since it’s main target is MINGW) but that one is a big one.

#10

My second point still apply, you should have set the config option in your kernel so it emulates the instruction when it encounter it, instead of sending a SIGILL signal.

The reason why gcc f*cks up here is due to the virtual box not implementing what it adverts. There is nothing you can do about it, except improving virtual box’s code. gcc base itself on the /proc/cpuinfo when you use native, and if the reported CPU says it support vectorial move but does not actually, then it’s an error from the VM not the compiler.