Problem with disassembler and SIGILL signal

mrjj

@Amaury
So app should be compiled in debug mode and hence have debug information?
You are seeing assembly as source is not there.
That is often due to debugging a released version.

To verify your debugger is working set a break point in your source and see it stop.

Amaury

well when I'm using abreak point in my main.cpp I see my app stopping when clicking on the play buton with the bug ( i'm on QT creator). I also see that my app is in debug and not in release mode.

mrjj

@Amaury

And in this case the/your code is shown ?

Amaury

Yes it's popping on the break point and not showing me the disassembler again.

mrjj

@Amaury

So it sounds like where ever it crashes its not in
your code and it shows assem as it have no source ?

Amaury

I don't know it sound like this yes , but it crashes at the starting point of my app, just showing my first window and then crashing.
But when I just run my app it's starting normally and then crashing after a couple of minutes without any explications .
That's why I need to debug, but if the problem is something out of the app I don't know how to deal with it.

mrjj

Hi
Dont you have idea in where in the app it could be ?
Or what action or processing that is going on when crashing.

When it crash, did the call stack showed more info on where it was?
http://doc.qt.io/qtcreator/creator-debug-mode.html
"Viewing Call Stack Trace"

Amaury

Alright after setting a break point as you recommended I was using F10 to check if there's some code that was walling the SIGILL signal , I think I found where my problem is .

That's my main :

int main(int argc, char *argv[])
{
    //QTextCodec::setCodecForCStrings(QTextCodec::codecForName("UTF-8"));
    //QTextCodec::setCodecForTr(QTextCodec::codecForName("UTF-8"));

    QApplication a(argc, argv);

    QTranslator qtTranslator;
       qtTranslator.load(
               "qt_" + QLocale::system().name(),
               QLibraryInfo::location(QLibraryInfo::TranslationsPath)
               );
       a.installTranslator(&qtTranslator);

    MainWindow w;
    w.show();

    MemTampon::Db.aff_Temperature();
    MemTampon::Db.aff_Humidite();
    MemTampon::Db.aff_Puissance();
    MemTampon::Db.aff_Nom_SD();


    return a.exec();

All of this is running nice except when I'm trying to run (with F11 or f10 key ) the return a.exec() which giving the SIGILL signal

Ps : I set the breakpoint first on w.show and then on the line bfore the return function.

mrjj

Hi
I dont like the look of
a.installTranslator(&qtTranslator);
Since you give it address of a local variable.
So if it thinks it owns the translator ( as expects a pointer) then it will be double deleted by
"a" and by running out of scope. (after .exe())

Could you try to new it and see if it still crashes?

update:
Hmm Docs dont say it owns it.

Amaury

I have to say that I found this piece of code and just add it to my program since I had some pop-ups written in english ( I'm french).

So is something like this that you mean by new it ? :

QTranslator *qtTranslator = new QTranslator;
      qtTranslator.load(
              "qt_" + QLocale::system().name(),
              QLibraryInfo::location(QLibraryInfo::TranslationsPath)
              );
      a.installTranslator(&qtTranslator);

   return a.exec();

because I can't even copile like this ...

mrjj

hi
yes
except now its pointer, u must get rid of &
a.installTranslator(qtTranslator);

Amaury

That's compiling but when I'm debugging it's still crashing at the same point ...

kshegunov

SIGILL is very unusual, it often means the binary is corrupt (it's the illegal instruction signal). What compiler are you using?
As for @mrjj's suggestion, you can still create on the stack, but do unregister the translator before returning from main(), e.g.:

int main()
{
    // ...
    QTranslator qtTranslator;
    qtTranslator.load("qt_" + QLocale::system().name(), QLibraryInfo::location(QLibraryInfo::TranslationsPath));
    a.installTranslator(&qtTranslator);

    int retcode = a.exec();
    a.removeTranslator(&qtTranslator);

    return retcode;
}

Amaury

I am using Gdb as debugger and Gcc as a compiler , I forget to precise that I was on a raspberry Pi 3.
I would try your way and come back again.

mrjj

@Amaury
Hi
Ok. it was not the translator it seems.

Do you have global object or anything else that might run out of scope and be deleted twice?
You should try putting break point in mainwindow destructor and see if it gets to that part.

Amaury

I have a .h and .cpp named global Where I put 2 global variables as extern. Maybe it's the problem I'm Setting a point break on the Main window and sending you my global.h and global .cpp

Global.h

#ifndef GLOBAL_H
#define GLOBAL_H

#include <QString>

QT_BEGIN_NAMESPACE
class QString;
QT_END_NAMESPACE

extern QString OnlinePath;
extern int Var;


#endif // GLOBAL_H

Global.cpp

`#include "global.h"
#include <QString>


QString OnlinePath= "http://192.168.1.242/app.php/api/smartdevice";
int Var = 0;


``

kshegunov

Are you sure that this compiler produces binaries for that particular instruction set? Look up the compatibility of your gcc version with the instruction set of that particular Pi.

mrjj

Hmm dont seems like it as just a Qstring.
Its more if you have a widget and assign parent.
Then both scope and parent might delete it and it might crash.

Dont the call stack give hint what it was doing ?

Amaury

@kshegunov Sorry I didn't understand anything I'm not really used with the debuggers.

@mrjj Hum I am associating widgets to a parent when using a QStackWidget for example I got my main window with some widgets in it. It the main ui of my application.

I am adding some widgets in a QStackedWidget on the MainWindow and calling them by using their names .

MainWindow

MainWindow::MainWindow(QWidget *parent) :
QMainWindow(parent),
    ui(new Ui::MainWindow)
{

    //this->setWindowFlags(Qt::FramelessWindowHint);

    ui->setupUi(this);
    this->move(this->x(),this->y());

    AccueilWindow = new Accueil(this,"AccueilWindow");
    ui->stackedWidget->addWidget(AccueilWindow);

ui->stackedWidget->setCurrentWidget(AccueilWindow);

connect(this,SIGNAL(changeInterface(QString)),this,SLOT(changeOnglet(QString)));
}

void MainWindow::changeOnglet(QString name)
{
    qDebug()<<name;
    if ((name == AccueilWindow->objectName())&&AccueilWindow)
    {
        ui->stackedWidget->setCurrentWidget(AccueilWindow);
        hide_full_ui();
        show_ui();
        return;
    }
    else if ((name == AlarmesWindow->objectName())&&AlarmesWindow)
    {
        ui->stackedWidget->setCurrentWidget(AlarmesWindow);
        show_ui();
        return;
    }
}

Mainwindow.h

private:
    
    Ui::MainWindow *ui;

    Accueil *AccueilWindow;
    Alarmes *AlarmesWindow;

The alarm.cpp

Alarmes::Alarmes(QWidget *parent,QString AlarmesWindow) :
    QWidget(parent),
    Alrm_ui(new Ui::Alarmes)
{
    Alrm_ui->setupUi(this);


    this->setObjectName(AlarmesWindow);
    connect(this,SIGNAL(changeInterface(QString)),qobject_cast<MainWindow *>(parent),SLOT(changeOnglet(QString)));
}

alarm.h

namespace Ui {
class Alarmes;
}

class Alarmes : public QWidget
{
    Q_OBJECT

public:
    explicit Alarmes(QWidget *parent ,QString AlarmesWindow);
    virtual ~Alarmes();

mrjj

Hi
Nothing springs to eye. Seems you let the Qt system handle it.

If you create a default Widgets project and run it on the pi.

Does that also crash at close?