QSharedPointer, qRegisterMetaType, GDB and slots

kshegunov

Usually one puts this (note that the typedefed name is used as string argument):

qRegisterMetaType< QSharedPointer<TestClass> >("SharedTestClass");

in main() not as a global variable.

Also, this Q_DECLARE_METATYPE(SharedTestClass) shouldn't be needed.

That said, your stack trace is really strange:

_dl_debug_initialize (ldbase=4294967292, ns=1095236752) at dl-debug.c:55

This looks like some loader initialization mismatch, check debug vs release builds of your application and libraries that are used.

julio.cruz

Hi kshegunov,

Thanks for your suggestion and feedback.

After implementing your suggestions the application is debugging as expected.

Please, can you refer me some additional keywords or topics (URL) to research more about the loader initialization mismatch that you refer?

Thanks

Julio

As reference the example tested on cross environment using GDB:

class MyData
{
public:
    //const static int m_nTypeId;
    MyData();
    ~MyData();
    int m_nIteration;
};
typedef QSharedPointer<MyData> SharedMyData;

MyData::MyData() :
    m_nIteration(-1)
{
    qDebug() << Q_FUNC_INFO;
}
MyData::~MyData()
{
    qDebug() << Q_FUNC_INFO;
}

int main(int argc, char *argv[])
{
    qRegisterMetaType< QSharedPointer<MyData> >("SharedMyData");
    ....
}

class MainWindow : public QMainWindow
{
public slots:
    void plotData(SharedMyData pData);
    .....

MainWindow::MainWindow(QWidget *parent) 
{
    QObject::connect(&m_thread, SIGNAL(sendData(SharedMyData)),
                     this, SLOT(plotData(SharedMyData)), Qt::QueuedConnection);
    m_thread.start();
}

void MainWindow::plotData(SharedMyData data)
{
    qDebug() << Q_FUNC_INFO << data->m_nIteration;
    if(data->m_nIteration == 0) {
        qDebug() << "closing";
        m_thread.quit();
        m_thread.wait();
        close();
    }
}

void MyThread::run()
{
    while(m_nIterations--) {
        qDebug() << Q_FUNC_INFO << m_nIterations;
        SharedMyData pData = SharedMyData(new MyData());
        pData->m_nIteration = m_nIterations;
        emit sendData(pData);
        QThread::sleep(1);
    }
    this->exit();
}

The whole project is at https://github.com/jcsistemas2001/testQtPointer

kshegunov

@julio.cruz

Please, can you refer me some additional keywords or topics (URL) to research more about the loader initialization mismatch that you refer?

What I meant is this line from the stack trace:

_dl_debug_initialize (ldbase=4294967292, ns=1095236752) at dl-debug.c:55

points that the loader (dynamic linker) initialization in debug mode is failing, so that's where I assumed the error is happening. Fixing that should have (and it did) fix your program. Now as to why it happened:

You run qRegisterMetaType when the loader initialization is happening (because you have a non-trivial int assignment in global scope)
You use incorrect argument for the said function

If I had to guess what exactly caused the crash, I'd say it's the order of initialization of static variables which is undefined. This is a very extensive topic and is mostly an implementation detail, but Qt has statics of it's own. So my best guess it that something is referred to in Qt before being initialized because you call qRegisterMetaType at the global scope and that is executed before Qt's globals were initialized. This is the reason I preach around this forum to never use global/static variables unless there is a really a good reason for it, and even then, to be extra careful.

check debug vs release builds of your application and libraries that are used.

This I mentioned because if on windows, you can be linking to a debug build of a library in another library and if your application links against a release build of that same library you can end up having two different instances of the same variable (strange but yes, on windows release and debug builds are different libraries). So not knowing your exact circumstances I just pointed it out for completeness.

Kind regards.

julio.cruz

Hi kshegunov, thanks for your feedback, appreciated.

jeffdag

I am getting the exact same stack. My setup is created by Yocto (Jethro branch) and the meta-qt5 layer. The target machine is i.mx6 based. I get the segfault when I mention QGraphicsScene in my form. If I comment out the "ui->setupui()" call, the segfault goes away. I'm guessing when I take that part out, many symbols get omitted from the link.

Does anyone have any clue where to dig next? When I ssh into the target and do a simple terminal gdb I get the same segfault which narrows it down quite a bit. The rootfs of the target is built with all the dev IMAGE_FEATURES (source, debug symbols, toolchain, etc.).

kshegunov

@jeffdag
Hello,

My setup is created by Yocto (Jethro branch) and the meta-qt5 layer.

I don't have a clue what that is, but I'm going to assume it some sort of embedded linux thing.

I get the segfault when I mention QGraphicsScene in my form. If I comment out the "ui->setupui()" call, the segfault goes away. I'm guessing when I take that part out, many symbols get omitted from the link.

Do you gave global/static variables or singletons (they could be crashing on initialization as was the case of Julio's)? Can you share some relevant bits of code?

Kind regards.

julio.cruz

@jeffdag,
By chance I just saw the new messages in this post. My setup is similar to yours.
Did you solve your issue?
I suggest to create a empty project and add the QGraphicsScene to find the cause. Fortunately, you get same results at remote with ssh.
Right now, I'm dealing with another issue. Debugging with QT Creator the GDB show a SEG FAULT (without any reference to source code), and using the same program, the GDB at remote (using ssh or serial console) don't show SEG-FAULT.

kshegunov

@julio.cruz said:

By chance I just saw the new messages in this post.

You could subscribe to your posts (there's an option at the profile page somewhere) so you get notifications on new messages.

Debugging with QT Creator the GDB show a SEG FAULT (without any reference to source code)

You should at least get a stack trace, no?

julio.cruz

Hi kshegunov,

Done about the notifications. Thanks for the suggestion.
About the segmentation fault, I described the stack trace below. Maybe new suggestions could arise.
Appreciated your feedback.
Thanks

Custom application (GDB remote)
The stack trace of the custom application is:

Level Function File Line
1        ??
2        ??

Screenshot of QT Creator during the SIGSEG: http://postimg.org/image/a62dxnrkh/
Debugger log (left) : https://justpaste.it/tblo
Debugger log (right): https://justpaste.it/tbln

Empty application (GDB remote)
If a new application is created (i.e. Application with a QWidget), the debugger run fine. Below the debug log:

Debugger log (left) : https://justpaste.it/tbm0
Debugger log (right): https://justpaste.it/tblz

Differences (GDB log)

Comparing both logs there are the following differences: https://www.diffchecker.com/zdvjxhzr

Line 746 : Empty application have: >1571^done >&"Function "QMessageLogger::fatal" not defined.\n"
Line 753: Custom application have it with different order: Process /usr/sbin/emonitor created; pid = 9606
Line 769: Custom application receive segmentation

About the left side (in the QT Creator Debugger log), there is not difference (until process is running): https://www.diffchecker.com/1f2xllvu

Custom application (GDB local)
If the custom application is running with local GDB (through console or ssh) there is not segmentation fault:

...
(gdb) run
Starting program: /usr/sbin/emonitor
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/libthread_db.so.1". 
[Julio: The application at this point run without problem]

Completed local GDB log here: https://justpaste.it/tbm9

kshegunov

@julio.cruz
Hello,
To be completely candid, I haven't used GDB remotely and I'm certainly not so intimate with it for the log to speak to me much. However, it does appear (at least to me) that you're trying to debug a release build of the application. Although I'm used to x86 assembly and jne instead of bne, it looks like there's no debug information in your program, hence the calls are optimized out and there's no "good" stack trace.
I suggest, building for your device in debug and trying to find out what the error might be. At least to obtain a sensible view of the stack frame. It'd be hell trying to trace it through the asm ...

Line 769: Custom application receive segmentation

This does point to a segmentation fault, but that error is so broadly raised it's almost meaningless without context. It can vary from dereferencing NULL pointers to out of bounds buffer overflows, so it's hard to tell what's going on.

Kind regards.

julio.cruz

Hi @kshegunov ,

Thanks for your quick feedback.

The application was build in Debug mode. However, the file system was build without the debug symbols as you mentioned. So, a new file system was created including the debug symbol for all installed packages.

With this new system, I still receive the same segmentation fault from GDB/Qt Creator. In other hand, the local GDB still working with some additional messages (that not show before):

Starting program: /usr/sbin/emonitor
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/libthread_db.so.1".
warning: File "/usr/lib/libstdc++.so.6.0.21-gdb.py" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load".
To enable execution of this file add
        add-auto-load-safe-path /usr/lib/libstdc++.so.6.0.21-gdb.py
line to your configuration file "/home/root/.gdbinit".
To completely disable this security protection add
        set auto-load safe-path /
line to your configuration file "/home/root/.gdbinit".
For more information about this security protection see the
"Auto-loading safe path" section in the GDB manual.  E.g., run from the shell:
        info "(gdb)Auto-loading safe path"

This time, the local GDB take more time to run the application.

kshegunov

@julio.cruz
Hello Julio,

With this new system, I still receive the same segmentation fault from GDB/Qt Creator.

This'd be something to track, but I think it's more important to fix the debugging first.

In other hand, the local GDB still working with some additional messages (that not show before)

If I'm not mistaken, this python file(s) should contain some debugging helpers for gdb. Since you're developing (not to mention it's your own application), I'd suggest to just disable whatever security nonsense is in place, i.e. to add: set auto-load safe-path to ~/,gdbinit. Note however that it's not a good idea in general to operate with the super user account (I'm inferring this from ~ being equal to /home/root).

Kind regards.

Larswad

Hi!

I see the very same SIGSEGV in gdb, imx, Jethro (yocto), qt5.1.1.

Did this issue ever get solved, Juilio? If so, what was the reason?
I can create a simple console app, and debugging works. But our real application will cause this crash when debugging.
Best Regards,
Lars

julio.cruz

Hi @Larswad,
The issue get solved partially. After included new code, we got similar issues during debug session. That's could depend in many variables as suggested by @kshegunov previously.
In any case, I suggest you to try upgrading to Krogoth. After the upgrade, I was able to debug the latest application without issues.
Best regards
Julio

kshegunov

@Larswad said in QSharedPointer, qRegisterMetaType, GDB and slots:
Hello,

As for the loading warning (assuming you also get it), you could peak here:
https://sourceware.org/gdb/onlinedocs/gdb/Auto_002dloading-safe-path.html

Kind regards.

Larswad

Thanks Julio for your answers!

Stepping up from Jethro may be (at least in the in the near time) too much work for us. But maybe something can be backported from Krogoth instead and patched.

Lars

Greg Hwang

Hello,

Was this issue ever resolved? I have a very similar setup to Larswad, and I'm seeing the same issue.

Greg Hwang

Just an update. I upgraded my version of gdb from 7.9.1 to 7.10.1 on my embedded system, and I was able to get past this point. Just putting this out there in case anyone else runs into this issue.