[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