[SOLVED] Writing to QDataStream causes segmentation fault

[butterface]

Hi,

I have a class A which subclasses QWidget and a class B which subclasses class A. Both of them implement mousePressEvent as follows:

@
void A::mousePressEvent(QMouseEvent *event)
{
if (event->button() == Qt::LeftButton)
dragStartPosition = event->pos();
QByteArray itemData;
QBuffer *b = new QBuffer(&itemData);
b->open(QIODevice::WriteOnly);
dataStream.setDevice(b);
dataStream << QPoint(event->pos());
QMimeData *mimeData = new QMimeData;
mimeData->setData("application/x-dnditemdata", itemData);
drag = new QDrag(this);
drag->setMimeData(mimeData);
drag->setPixmap(QPixmap::grabWidget(this));
drag->setHotSpot(event->pos());
}
@

and the method of class B

@
void B::mousePressEvent(QMouseEvent *event)
{
A::mousePressEvent(event);
dataStream << 25;
if (acceptDrops())
drag->exec(Qt::MoveAction);
else
drag->exec(Qt::CopyAction);
}
@

At dataStream << 25; I get a segmentation fault even though the reference seems to be valid and getting the status of the stream returns 0 (OK). The datastream is am member of A. Can anyone please tell me what I am missing?

Thanks

[andre]

Where does dataStream come from?
Also, I think it is dangerous to just stream in '25'. Do you know what exactly is streamed in here? I'd always make sure to use an explicit type:
@
quint16 value(25);
dataStream << value;
@
Now, I am sure that I have a quint16 in the stream, not an integer of a who-knows-what type that depends on the platform the code was compiled on.

[butterface]

@dataStream@ is a member of A. As long as I am in A I can write to it without any problems. The 25 is just a test value. It has no meaning at all and in my program der is a method call which returns an int. I can use quint16 later but for writing it should not make a difference, should it?

[broadpeak]

How can B sees A's dataStream ? Not clear for me...

[nikCoder]

"QByteArray itemData" in void A::mousePressEvent(QMouseEvent *event) is a local, Hence the segfault . Allocate on heap or as a member . Hope it helps.

Cheers,
Nikhil

[mlong]

Also, I believe that the
@
QBuffer *b = new QBuffer(&itemData);
@ creates a memory leak.

[butterface]

Thanks Nikhil, it solved the problem. One day I will learn this stupid heap and stack thing.

@mlong: Why? Now itemData is a member as well. I should be able to delete it but I cannot see the memory leak of the implementation before.

[nikCoder]

I agree with mlong, there is lot of leaks in your code. Unless required dont allocate memory on heap (i.e using new) . Instead , make QBuffer object an member variable. If you need to use smart pointers when allocating. Every new , must have a delete , else you have potential memory leaks. In case of @ QBuffer *b = new QBuffer(&itemData);@ if b is not an member of the class , then in destructor you cant delete it since, b is a local pointer .

[mlong]

b is allocated with a new() but never deleted anywhere that I can see. (Unless something takes ownership of the buffer object and deletes it on your behalf, but I don't think it does.) I know that there's no parent object given to the buffer.

[butterface]

Thanks for your help so far. I changed those objects to references or added deletes where necessary. It works now, at least some kind of.
I can read some information from the stream but something seems to be wrong. The QPoint I added is restored as expected in the dropEvent but my own object is not. For my class to write into the stream I have operator>> and operator<< as non-members. At the moment I only add an int which I cast(?) to quint32 as Andre mentioned but on the other end, when I try to read it again it is always 0. I don't get any errors so something valid must be there but not what I expect.
Any ideas?

[goetz]

You should start to debug your operators without drag/drop functionality.

Just create an object, call the output operator. Then destroy your object; create a new one and call it on your input operator working on the data you have written previously. Don't forget to close the file and re-open it or reset the file pointer to the beginning. Then use a debugger to see what's coming in from the stream. Also, have a look at the file, e.g. by using some hexdump utility. The data is usually pretty straight forward to interpret.

Once you're sure that this all works, go back to the DnD thingie.

[butterface]

I just figured out that everything works fine (read and write) if I write in the base class A. Everything written in B could not be read again.

Here again both methods:

@
void A::mousePressEvent(QMouseEvent *event)
{
if (event->button() == Qt::LeftButton)
dragStartPosition = event->pos();
itemData = new QByteArray();
b = new QBuffer(itemData);
b->open(QIODevice::WriteOnly);
dataStream.setDevice(b);
dataStream << QPoint(event->pos());
mimeData = new QMimeData;
mimeData->setData("application/x-dnditemdata", *itemData);
drag = new QDrag(this);
drag->setMimeData(mimeData);
drag->setPixmap(QPixmap::grabWidget(this));
drag->setHotSpot(event->pos());
}
@

@
void B::mousePressEvent(QMouseEvent *event)
{
A::mousePressEvent(event);
quint16 val(4);
dataStream << val; //this one can never be read out again...
if (acceptDrops())
drag->exec(Qt::MoveAction);
else
drag->exec(Qt::CopyAction);
}
@

@
class A : public QWidget
{
public:
A(QWidget *parent = NULL, bool acceptDrops = true);
virtual ~A();

protected:
virtual void mousePressEvent(QMouseEvent *);

QPoint dragStartPosition;
QDrag *drag;
QDataStream dataStream;
QByteArray *itemData;
QBuffer *b;
QMimeData *mimeData;

};
@

[butterface]

The "funny" thing is if I step through with the debugger the value is written to the stream in the subclass but if the program runs free it is not. I can see the qDebug message right before the write to the datastream in any case but the data is only writte in debug mode?!

[andre]

Well, so far you are still not showing us how class A and B are related, so it is very hard to get an idea of what is actually going on in your code.

[butterface]

Sorry for asking, but is there another relation between them then subclassing, i. e. B is a subclass of A.
I can post the exact class definition when I am back home.

[butterface]

And here comes definition of class B

@
class B : public A
{
Q_OBJECT
public:
B(QWidget *parent = NULL, bool acceptDrops = true);
virtual ~B();

protected:
void paintEvent(QPaintEvent *);
void mousePressEvent(QMouseEvent *);
};
@

[goetz]

In class A's mousePressEvent function, you set the mime data in the QDrag object in line 11:

@
mimeData->setData("application/x-dnditemdata", *itemData);
@

At this point in time, only the QPoint data has been written to the QDataStream and its underlying byte array.

Once you come back to class B's mousePressEvent function, you write some more data to the byte array, but that never reaches the QDrag object! QDrag takes a copy of the data. At the moment you write to the array in class B, the implicit sharing creates a deep copy of the array and in turn, you end up with two QByteArrays: one that's within the drag object, and one in class B, which is never used again.

As a side note: Your split of code looks very strange to me and in my opinion it cries for additional trouble in the future.

[butterface]

Okay, thanks for that so far.

What would you suggest for the setting of the QByteArray? The point is, I want to make sure that subclasses don't need to take care about those things. I want the base class to take care of the clicked points and all the things which come again and again (like the definition of when I make a base class). If there is no other way, I can move the whole dnd code to the subclasses of course.
What do you mean by "it looks strange"? I actually took the dnd example from the website and changed a few things like adding my own object.

So please let me know how to make it better and what you would suggest for the problem of the subclass datastream writing.

[goetz]

I would split out the preparation of the mime data into some other virtual functions. Only implement the mousepress event handler in class A and call the new functions from that. Basicall like this:

@
void A::mousePressEvent(QMouseEvent *event)
{
QByteArray itemData;
QDataStream dataStream(&itemData, QIODevice::WriteOnly);

// the new function:
prepareDragData(event, dataStream);

QMimeData *mimeData = new QMimeData;
mimeData->setData("application/x-dnditemdata", itemData);
drag = new QDrag(this);
drag->setMimeData(mimeData);
drag->setPixmap(QPixmap::grabWidget(this));
drag->setHotSpot(event->pos());

if (acceptDrops())
    drag->exec(Qt::MoveAction);
else
    drag->exec(Qt::CopyAction);

}

void A::prepareDragData(QMouseEvent *event, QDataStream &stream)
{
dataStream << QPoint(event->pos());
}

void B::prepareDragData(QMouseEvent *event, QDataStream &stream)
{
A::prepareDragData(event, stream);
dataStream << 25;
}
@

Additional notes:

• no more need of class variables for the dataStream
• no need for a QBuffer, the dataStream can work directly on a QByteArray

[andre]

I think Volkers suggestion makes a lot of sense. However, perhaps you should even considder taking it a step further. Does your drag target really need to know the QPoint where the drag started? Or is it really only interested in some kind of handle to the object that is being dragged, and the type of that object? Usually, in my experience, it is the latter...