Qtcreator fails to run and generates core (SIGILL)



  • Hi,

    I have tried to install the QT5.2.1 software using the "qt-opensource-linux-x86-5.2.1.run" package onto Fedora 20 on two separate machines (both reasonably old, but all the apps in KDE work ok).

    In both cases, the package seems to install correctly (I tried a full install and also the default install without the src stuff). However, when I launch qtcreator, after a few seconds it fails and dumps core.

    I then ran qtcreator under gdb and got the following:-

    =============================================

    gdb /usr/bin/Qt5.2.1/Tools/QtCreator/bin/qtcreator
    GNU gdb (GDB) Fedora 7.6.50.20130731-19.fc20
    Copyright (C) 2013 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-redhat-linux-gnu".
    Type "show configuration" for configuration details.
    For bug reporting instructions, please see:
    http://www.gnu.org/software/gdb/bugs/.
    Find the GDB manual and other documentation resources online at:
    http://www.gnu.org/software/gdb/documentation/.
    For help, type "help".
    Type "apropos word" to search for commands related to "word".
    ..
    Reading symbols from /usr/bin/Qt5.2.1/Tools/QtCreator/bin/qtcreator...(no debugging symbols found)...done.
    (gdb) run
    Starting program: /usr/bin/Qt5.2.1/Tools/QtCreator/bin/qtcreator
    [Thread debugging using libthread_db enabled]
    Using host libthread_db library "/lib/libthread_db.so.1".
    Traceback (most recent call last):
    File "/usr/share/gdb/auto-load/usr/lib/libgobject-2.0.so.0.3800.2-gdb.py", line 9, in <module>
    from gobject import register
    File "/usr/share/glib-2.0/gdb/gobject.py", line 3, in <module>
    import gdb.backtrace
    ImportError: No module named backtrace
    [New Thread 0xb7ac6b40 (LWP 8277)]
    [New Thread 0xb1186b40 (LWP 8278)]
    Detaching after fork from child process 8279.
    Detaching after fork from child process 8281.
    Detaching after fork from child process 8283.
    Detaching after fork from child process 8284.
    [New Thread 0xb07ffb40 (LWP 8285)]
    [New Thread 0xafffeb40 (LWP 8286)]
    [New Thread 0xad980b40 (LWP 8287)]

    Program received signal SIGILL, Illegal instruction.
    0xb5c7c0b5 in QV4::ExecutionEngine::ExecutionEngine(QQmlJS::EvalISelFactory*) ()
    from /usr/bin/Qt5.2.1/Tools/QtCreator/lib/qtcreator/plugins/QtProject/../../libQt5Qml.so.5
    (gdb) bt
    #0 0xb5c7c0b5 in QV4::ExecutionEngine::ExecutionEngine(QQmlJS::EvalISelFactory*) ()
    from /usr/bin/Qt5.2.1/Tools/QtCreator/lib/qtcreator/plugins/QtProject/../../libQt5Qml.so.5
    #1 0xb5df1b52 in QV8Engine::QV8Engine(QJSEngine*) () from /usr/bin/Qt5.2.1/Tools/QtCreator/lib/qtcreator/plugins/QtProject/../../libQt5Qml.so.5
    #2 0xb5c767dc in QJSEngine::QJSEngine(QJSEnginePrivate&, QObject*) ()
    from /usr/bin/Qt5.2.1/Tools/QtCreator/lib/qtcreator/plugins/QtProject/../../libQt5Qml.so.5
    #3 0xb5d23cb7 in QQmlEngine::QQmlEngine(QObject*) () from /usr/bin/Qt5.2.1/Tools/QtCreator/lib/qtcreator/plugins/QtProject/../../libQt5Qml.so.5
    #4 0xb5463883 in ?? () from /usr/bin/Qt5.2.1/Tools/QtCreator/lib/qtcreator/plugins/QtProject/../../libQt5Quick.so.5
    #5 0xb11dc4f0 in ?? () from /usr/bin/Qt5.2.1/Tools/QtCreator/lib/qtcreator/plugins/QtProject/libWelcome.so
    #6 0xb11dca64 in ?? () from /usr/bin/Qt5.2.1/Tools/QtCreator/lib/qtcreator/plugins/QtProject/libWelcome.so
    #7 0x4f929074 in ExtensionSystem::Internal::PluginSpecPrivate::initializePlugin() ()
    from /usr/bin/Qt5.2.1/Tools/QtCreator/bin/../lib/qtcreator/libExtensionSystem.so.1
    #8 0x4f923662 in ExtensionSystem::Internal::PluginManagerPrivate::loadPlugin(ExtensionSystem::PluginSpec*, ExtensionSystem::PluginSpec::State) ()
    from /usr/bin/Qt5.2.1/Tools/QtCreator/bin/../lib/qtcreator/libExtensionSystem.so.1
    #9 0x4f923994 in ExtensionSystem::Internal::PluginManagerPrivate::loadPlugins() ()
    from /usr/bin/Qt5.2.1/Tools/QtCreator/bin/../lib/qtcreator/libExtensionSystem.so.1
    #10 0x4f923b3d in ExtensionSystem::PluginManager::loadPlugins() () from /usr/bin/Qt5.2.1/Tools/QtCreator/bin/../lib/qtcreator/libExtensionSystem.so.1
    #11 0x08050648 in ?? ()
    #12 0x43c28b73 in __libc_start_main (main=0x804d060, argc=1, argv=0xbfffef84, init=0x80566b0, fini=0x8056720, rtld_fini=0x43bfa8c0 <_dl_fini>,
    stack_end=0xbfffef7c) at libc-start.c:285
    #13 0x08051519 in ?? ()
    (gdb)

    I can't find anything online so far to explain why this is happening. Is it an issue with the age of my machines or some installation/config issue?

    Is there some more information I can supply to help the investigation?

    BR

    Mick



  • A guess: since you have an old machine and if it has an nvidia graphics card, try to upgrade the driver for it.

    One more guess: perhaps you need some more python stuff installed, try this:
    @sudo yum install numpy scipy python-matplotlib ipython python-pandas sympy python-nose@
    (found this while googling :-)



  • Here's the video cards:-

    01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RV100/M6 [Rage/Radeon Mobility Series]

    01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] R350 [Radeon 9800 Series]

    So, not nvidia. Anyway, the machines are running bang up to date Fedora 20, so the have all the latest and greatest versions of everything already.

    I don't see how the python stuff matters (although a couple of your suggestions are installed by default). My main machine (x86-64) has the same software mix and is running the equivalent Qt5.2.1 for the 64 bit release without trouble.

    BR

    M



  • Well I just googled that python error message you got:
    @File “/usr/share/gdb/auto-load/usr/lib/libgobject-2.0.so.0.3800.2-gdb.py”, line 9, in <module> from gobject import register File “/usr/share/glib-2.0/gdb/gobject.py”, line 3, in <module> import gdb.backtrace
    ImportError: No module named backtrace@
    (it seems fairly common and exists on Fedora).

    Sorry don't know that much about Fedora, closest I've come is probably Arch Linux on my Raspberry Pi.

    About your main machine where things work fine, is that newer hardware? If so, maybe try to upgrade your AMD driver on the old machines.



  • Yeah, but I think THAT problem is in gdb itself, before it gets to looking at the qtcreator execution. Note the files both have "...../gdb/...." in their path and the missing module is "gdb.backtrace".

    The main machine is indeed newer, but I don't understand what you mean by "upgrade your AMD driver".

    One machine indeed has an AMD chip but the other is Intel.

    ===========================

    cat /proc/cpuinfo
    processor : 0
    vendor_id : GenuineIntel
    cpu family : 6
    model : 11
    model name : Mobile Intel(R) Pentium(R) III CPU - M 1000MHz
    stepping : 4
    microcode : 0x2
    cpu MHz : 997.500
    cache size : 512 KB
    physical id : 0
    siblings : 1
    core id : 0
    cpu cores : 1
    apicid : 0
    initial apicid : 0
    fdiv_bug : no
    f00f_bug : no
    coma_bug : no
    fpu : yes
    fpu_exception : yes
    cpuid level : 2
    wp : yes
    flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pse36 mmx fxsr sse
    bogomips : 1993.23
    clflush size : 32
    cache_alignment : 32
    address sizes : 36 bits physical, 32 bits virtual
    power management:

    ========================================

    cat /proc/cpuinfo
    processor : 0
    vendor_id : AuthenticAMD
    cpu family : 6
    model : 6
    model name : AMD Athlon(tm)
    stepping : 2
    cpu MHz : 1249.976
    cache size : 256 KB
    physical id : 0
    siblings : 1
    core id : 0
    cpu cores : 1
    apicid : 0
    initial apicid : 0
    fdiv_bug : no
    f00f_bug : no
    coma_bug : no
    fpu : yes
    fpu_exception : yes
    cpuid level : 1
    wp : yes
    flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow
    bogomips : 2499.95
    clflush size : 32
    cache_alignment : 32
    address sizes : 34 bits physical, 32 bits virtual
    power management: ts



  • Yeah you're right that python msg surely is a sidetrack and irrelevant (sorry), indeed it seems that it is Qt's QML dll that goes south: ibQt5Qml.so.5.

    You should be able to debug it better if you compile a debug version of QtCreator 3.01 from its sources and sprinkle some qDebug() statements in there. You can download the sources as a zip, and it has a .pro file to get you going :-)

    (I built QtCreator in Debian the other day, takes about 35 minutes on a Core I3.)



  • 8^( not nice. It'll take a long time on either of these steam machines.

    OK, I'll look at doing that tomorrow (too tired tonight).

    I did install all that python stuff on one machine but no improvement.

    I've not tried to compile any Qt stuff outside the qtcreator IDE. If I need qtcreator to do it, it's chicken and egg!

    Can I compile it on my x86-64 machine? I mean, what do I need to do to ensure it is i686 compatible? It shouldn't take too long on that machine as it is a recent chip and has an SSD/plenty of RAM.



  • For a second there I thought you wrote SteamOS machines (freudian slip).

    Re. getting a debug version of QtCreator, you should be able to compile a 32-bits version on your 64-bits machine, hmmm. Out of my depths a bit...

    On the other hand, I've seen a couple of places where you can download a debug-flavored QtCreator executable (to save you that half-hour).

    Finally, I see that Fedora has a package called "qt-creator-debuginfo".
    "Current version 3.01 for Fedora 20 :-)":http://rpm.pbone.net/index.php3/stat/4/idpl/25682076/dir/fedora_20/com/qt-creator-debuginfo-3.0.1-1.fc20.x86_64.rpm.html

    If you install that, gdb might be more eloquent...



  • Hello had a morning walk and started thinking about your QtCreator failure, if you read carefully at that gdb dump (and not stop at python messages as I did yesterday!), you'll see that it's most likely the welcome screen that crashes. One of the differences between 5.1 and 5.2 is that they really spiffed up the welcome screen with videos etc. Maybe your old machine stumbles there.

    And I found an easy way to test this theory: go into the QtCreator bin directory (on the "steam" machines I mean) and look for the qt.conf file.
    On my Debian it's /home/henry/Qt/Tools/QtCreator/bin. Open it with gedit, see that last line:
    @Qml2Imports=qml@

    Now change the directory to something invalid (in order to break the welcoming screen), for example:
    @Qml2Imports=xyzzy@

    Now try to launch QtCreator, on my Debian it launches anyway but without that spiffyness (ie. just shows a white form). With a bit of luck you'll see the same :-)



  • Just saw this during a tea break. I work from home, so I whizzed across to my home machine and tried it. Doh! Still no go.

    I'll look at playing with compilation this weekend. I might bite the bullet and try a full installation instead of using the *.run package. I'll report back when I've finished.



  • Interesting goose chase, it should be possible to narrow down. One way to fix a working 32-bit flavoured Qt is if you install VirtualBox on your 64-bit modern PC, and in that VirtualBox install a 32-bit Fedora and 32-bit Qt 5.2.1. That should enable you to compile and copy executable files into the "steam" machine.

    Also you can try another (simple :-) test to conquer that welcome screen: if you have an SSH server installed on the old machine, you could try ssh:ing in with the -X switch to remotely run QtCreator.


  • Lifetime Qt Champion

    Hi,

    You can also try to disable the welcome plugin (in About plugins)

    Hope it helps



  • @hskoglund

    I'll try the Virtualbox thing as a first step. I'll install Fedora 20 i686 and then the qt-opensource-linux-x86-5.2.1.run package so I have the same situation as on the old machines. If it works on the virtual machine, it must be h/w related.

    @SGaist

    How do i disable the welcome plugin?


  • Lifetime Qt Champion

    Go to "About Plugins" in the help menu IIRC, look for the welcome plugin (around the end of the list) and there you can disable it



  • Errrm... to get to the help menu, won't I need to fire up qtcreator? If I can't disable it off-line, I will never get to the help menu (or anything else).

    Or.... am I missing something?



  • Disabling the welcome plugin is an excellent idea (I tried by removing the help DLL, QtCreator wasn't pleased). But in this case, when QtCreator dies after 2 seconds I think, you have to be world's fastest mouse clicker to be able to reach the help menu :-)

    Anyway, disabling the welcome plugin should change a .conf file for QtCreator somewhere. So another way of disabling the plugin is to edit the .conf file.



  • Found it, on my Debian it's in /home/henry/.config/QtProject/QtCreator.ini.
    Locate the [plugins] section, change
    @Ignored=@Invalid()@

    to
    @Ignored=Welcome@

    BTW, this is a very good thing to do for WinXP and Win2k3 users running QtCreator 5.2.1, because on those systems the welcome screen doesn't refresh properly (leaving artifacts on the screen).

    (Perhaps QtCreator needs a command line switch for this, i.e. start in "safe" mode, or allow you to specify what plugins are to be ignored.)


  • Lifetime Qt Champion

    That one is already available:
    -noload <plugin>

    The rest of the list can be found "here":http://doc-snapshot.qt-project.org/qtcreator-3.0/creator-cli.html



  • Aha, thanks! Of course, should've guessed there is a --noload option already in there. (Great minds think alike :-)

    Looking at the list now and discovered a gem: -lastsession
    This is basically the only thing I've missed when using QtCreator, e.g. when I want to exit QtCreator, sync with GitHub and resume coding, that switch is perfect.

    I've just recently discovered Qt (a couple of months) since spending more than 20 years with Visual Studio, but I'm already regretting why I didn't switch sooner!



  • Well, when I got my Virtualbox machine configured, it works!!!

    The difference I can see is the cpuinfo

    ==================================

    cat /proc/cpuinfo
    processor : 0
    vendor_id : GenuineIntel
    cpu family : 6
    model : 45
    model name : Intel(R) Core(TM) i7-3820 CPU @ 3.60GHz
    stepping : 7
    cpu MHz : 3563.966
    cache size : 6144 KB
    physical id : 0
    siblings : 1
    core id : 0
    cpu cores : 1
    apicid : 0
    initial apicid : 0
    fdiv_bug : no
    f00f_bug : no
    coma_bug : no
    fpu : yes
    fpu_exception : yes
    cpuid level : 5
    wp : yes
    flags : fpu vme de pse tsc msr mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 rdtscp constant_tsc pni monitor ssse3
    bogomips : 7127.93
    clflush size : 64
    cache_alignment : 64
    address sizes : 46 bits physical, 48 bits virtual
    power management:

    ==================================

    So my virtual machine has lots of extra goodies such as sse2 &sse3, so it could be one those that are illegal on the older chips.

    I can't be bothered to try and compile from scratcha dn debug. I'll just continue using the 32 bit virtual machine to play....

    Thanks anyway.



  • Glad to hear!

    BTW, just out of curiosity: we now know that the welcome plugin was the culprit. But I'm thinking, that plugin couldn't be the only part of QtCreator using SSE2 and 3? Maybe it's the video after all (but not python :-)
    If you have the time, test for example a youtube video in the virtual machine, if the VM survives that or not...



  • Hi,

    The two old machines work fine for all other apps that I can test, including YouTube.

    I was using them because they have serial ports and I wanted to develop a serial application. I can't bear the pain of trying to get them to work, so I have purchased a cheap PCI express card for my main machine with 2 x serial and 1 x parallel ports. At £25/30€ it's worth being able to use the infinitely more powerful 64-bit machine.

    Also, this one is in my front room and the others are in the attic 8^)

    Thanks for the help anyway.


Log in to reply
 

Looks like your connection to Qt Forum was lost, please wait while we try to reconnect.