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.
_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
