[Interest] Calling QT Class method from pthread thread

Gonzalo Aguilar Delgado gaguilar at aguilardelgado.com
Wed Oct 4 18:24:03 CEST 2017


Thiago, Konstantin,

You are both great. Indeed the problem was that pesky pointer. It's so 
bizarre that it happened to me... Soo long.

There's something I was aware but didn't really realized. Indeed 
Konstantin when I made the pointer a static cast to the class, it 
doesn't matter what goes in the pointer. Because (as can be seen in glib 
clearly) the class definition (methods) and the class data are held 
apart. And the pointer is referencing the class data. So the method can 
be executed even if the pointer is pointer to invalid address as Thiago 
pointed me out.


For example in Glib they have in their library a runtime type checking 
that will warn about this kind of issues. This and because the function 
executed I discarded that error at the begining. I was expecting a 
segfault error if the pointer was wrong.

It also gcc didn't warned be that the function definition of the 
callback didn't matched the specification.

static gboolean callbackWrapper(SG64ZeroMQ* mq, ThriftStruct* message, 
gpointer data, GError **error) {

In my case it was defined by error to

typedef gboolean (*SG64ZeroMQHandler)(SG64ZeroMQ* mq, ThriftStruct* 
message, GError **error);

instead

typedef gboolean (*SG64ZeroMQHandler)(SG64ZeroMQ* mq, ThriftStruct* 
message, gpointer data, GError **error);

That alone caused all the troubles. I fixed the pointer and now 
everything is working nicely!!!


Oh men. So much reading and testing and the solution was in front of my 
eyes.

Thank you both guys. I owe you one!



On 04/10/17 17:57, Thiago Macieira wrote:
> On Wednesday, 4 October 2017 08:41:32 PDT Gonzalo Aguilar Delgado wrote:
>> Hello Thiago,
>>
>> Hope you can see something...
> Thanks.
>
> Did you also run this under valgrind? Maybe using a prelinker? Some pointers
> are funny.
>
>> #0  0x00007ffff61d7cec in QMetaObject::activate(QObject*, QMetaObject
>> const*, int, void**) (sender=0x7fffd15dddf0, m=<optimized out>,
>> local_signal_index=<optimized out>, argv=<optimized out>) at
>> kernel/qobject.cpp:3513
> The "this" pointer passes the smell detection: it's an address on a thread's
> stack (unlikely to be the main thread) or a thread's memory pool and is
> aligned to 16.
>
>> #1  0x000055555555ea29 in MQMessageManager::cardValidationSuccess()
>> (this=0x7fffd15dddf0) at moc_mqmessagemanager.cpp:134
>> #2  0x000055555555d785 in MQMessageManager::processMessage(_SG64ZeroMQ*,
>> _ThriftStruct*, _GError**) (this=0x7fffd15dddf0, mq=0x555555a59d40,
>> message=0x7fffd400f380, error=0x555555a59d40) at ../mqmessagemanager.cpp:114
> Those pointers starting with lots of 5 are the funny ones I mentioned.
>
>> array = {static shared_null = {ref = {_q_value = 299}, alloc = 0, size = 0,
>> data = 0x7ffff65297b8 <QByteArray::shared_null+24> "", array = ""}, static
>> shared_empty = {ref = {_q_value = 3}, alloc = 0, size = 0, data =
>> 0x7ffff6529798 <QByteArray::shared_empty+24> "", array = ""}, d =
>> 0x7fffc00049c0}
> This variable is wrong. The shared_null in Qt 5 has a counter always equal to
> 0. It should never grow from it, so 299 and 3 are definitely wrong. The
> debugging information is coming from Qt 4 because of the presence of "array"
> member.
>
> You're either using Qt 4 or you're mixing Qt 4 and Qt 5 in the same
> aplication. I'm going to stop here until you confirm you're only using Qt 5
> (minimum 5.6). I'm not going to support a Qt 4 application.
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20171004/56253193/attachment.html>


More information about the Interest mailing list