Destruction problem with Qt 4.8.0 on MacOSX Lion

[jmesquita]

I am not sure how to even start tracking this problem down. It might be me coding it wrong but I am getting an ASSERT every time the application quits.

By the looks of it, it seems to be caused by the destruction of PollingZMQContext.

The assert is on: ASSERT: "staticMetaObject.cast(_o)" in file moc_nzmqt.cpp, line 294

The offending code seems to be on line 415 of nzmqt.hpp:

 // Deleting children is necessary, because otherwise the children are deleted after the context
 // which results in a blocking state. So we delete the children before the zmq::context_t
 // destructor implementation is called.
        inline ~ZMQContext()
        {
            QObjectList children_ = children();
            foreach (QObject* child, children_)
                delete child;
        }

It is important to say that the problem only started to occur when I upgraded the Qt libs to 4.8.0. On 4.7.4, the problem was not being caused.

I am available at any time for debugging if necessary.

Thank you

[jonnydee]

First of all, thank you for your feedback. I haven't tried 'nzmqt' with Qt 4.8.0 yet, so this issue is indeed new to me.

I did some research on the internet and maybe this bug is related to https://bugreports.qt-project.org/browse/QTBUG-24054
In that bug they discuss a similar problem which is caused by a setting which crosses "DLL boundaries".

In order to track down the problem, would it be possible to answer the following questions?

1. Do you have a setup which might be caused by crossing DLL boundaries, too?
2. Could you please tell me the 'nzmqt' revision you are using? You quoted the bit of code that issues the ASSERT, but I need to know if it is the 'delete' statement. (In the current revision d0ca53a of nzmqt.hpp line 415 refers to a different code snippet.)
3. Besides the ASSERT which only should occur in a DEBUG build, do you encounter any other strange behavior?

Thanks again for your help :),
Jonny

[jmesquita]

Jonny,

First of all, thank you for looking into this.

I think you are correct, I believe that the problem is somewhat related to the QTBUG you've sent.

Let me reply each one of your questions:

1. I am not sure how to reply this question. If I did my research correctly, no. I am not using any external shared object that could emit signals. Unless the signal is emitted on libzmq's threads somehow and that's what it is complaining about. I am not sure, really.
2. I was using g0d0a1a3 but now I've upgraded and the same thing happens on a clean build. I did not upgrade before because I did not need ZMQDevice, which bby the looks of it, was the only addition from my rev.
3. No, no unusual behavior. One thing I did notice is that I get SIGV on release build instead of SIGABORT. I can tell it is the same error and it is being caused by something on libzmq because when I comment the ASSERT on the moc generated file, I get sigv on libzmq (I can't debug that because it is really out of my league).

If you want to debug it on my mac, please, just let me know and we can do some sort of remote control session.

Regards,
John (I am Johnny too!)

[jonnydee]

Hi John,

I could reproduce your problem with Qt 4.8 and was able to (hopefully) fix this bug for you. On my machine it works now. Please let me know if the bugfix works for you.

Best regards,
Jonny

[jmesquita]

Jonny,

It has indeed fixed the problem. I will let you know if something else shows up.

Once again, I appreciate your prompt help and solution.

Regards,

Mesquita

[jonnydee]

You're welcome :)