PDA

View Full Version : QList crash in destructor



mclark
9th October 2006, 22:11
When my function containing a QList<QTableWidgetSelectionRange> goes out of scope I get a crash in ~QList(). The call to this function is a response to a button click in a QDialog.

My intent is to find all rows with at least one cell selected and store a string from a cell in that row.


void Detect::on_Btn_clicked( void )
{
QList<QTableWidgetSelectionRange> list = ui.table->selectedRanges();
QStringList sList;

for ( int i = 0; i < list.count(); i++ )
{
if ( !sList.contains( ui.table->item( list[i].topRow(), COL2_IP )->text() ) )
sList.append( ui.table->item( list[i].topRow(), COL2_IP )->text() );
}

accept();
}

Even stripping the function to just:


void Detect::on_Btn_clicked( void )
{
QList<QTableWidgetSelectionRange> list = ui.table->selectedRanges();
accept();
}

still causes the crash.

My debugger lists a stack trace of:

msvcr71d.dll!operator delete(void* pUserData=non-zero)
QTableWidgetSelectionRange::`scalar deleting destructor'()
QList<QTableWidgetSelectionRange>::node_destructQList<QTableWidgetSelectionRange>::Node*from=non-zero)
QList<QTableWidgetSelectionRange>::free(QListData::Data*data=non-zero)
QList<QTableWidgetSelectionRange>::~QList<QTableWidgetSelectionRange>()
Detect::on_Btn_clicked()

All data in the stack trace is non-zero so I don't think I've got a NULL pointer causing the problem. Is there some maintainence that must be done to the contents of the QList before the function ends?

jpn
10th October 2006, 07:52
Sounds interesting, but I can't reproduce this with Qt 4.2.0. Could you provide a minimal compilable example that reproduces the crash.

mclark
10th October 2006, 23:24
I have hacked out everything I could to show how this is failing for me. A table with a single row and column is displayed. I select the cell and attempt to copy (Ctrl+C) which calls a function that has in it only:
QList<QTableWidgetSelectionRange> list = m_pTable->selectedRanges();
if ( list.count() > 1 )
return;

The crash occurs when leaving the function. I am using Qt 4.1.0 with Microsoft Visual Studio 2003 (Visual C++.NET).

If you cannot see a problem or reproduce the problem; I am just trying to determine which rows have a cell selected in them. Is there a better way to accomplish this than using QTableWidget::selectedRanges()?

Thank you for looking at this problem.

jpn
11th October 2006, 06:46
Try updating your Qt to a recent version. I couldn't get it to crash with Qt 4.1.4 nor Qt 4.2.0 / MSVC 2005.

bpetty
5th December 2006, 23:31
Interesting. I am having the same problem.

This is what is causing mine to crash:

bool CINAdminWindow::ViewStats()
{
QList<QTableWidgetSelectionRange> qlRange = ui.tblResults->selectedRanges();

if (qlRange.size() != 1)
{
//"Please Select One Spool"
return false;
}

int nRow = (*qlRange.begin()).topRow();

QString sSpoolID = ui.tblResults->item(nRow, 0)->text();

return true;
}

I have noticed that when it returns true (even when I comment out the "int nRow" and "QString sSpoolID" lines) it crashes but does not when it returns false.

It is very odd. I am using MS VS 2003 /w Qt 4.2.0.

They are on 4.2.2... maybe I should upgrade?

wysota
5th December 2006, 23:57
Maybe you should check if by any chance item() returns null.

bpetty
6th December 2006, 15:04
I would beleive that if it where not for the fact that when I comment out those lines it fails if it returns true.

mclark
6th December 2006, 15:27
Since jpn cannot reproduce this while using 4.1.4 or Qt 4.2.0 / MSVC 2005, I'm beginning to think this could be a problem with the MSVC 2003 C++ compiler in the way it's handling the QList<QTableWidgetSelectionRange> destructor. No proof, but the only commonality between bpetty's and my crashes is the MS compiler as I'm using Qt 4.1. This wouldn't be the first (nor the second) time I've been bitten by a MS compiler bug!

In the meantime I've switched to a more inefficient implementation but have kept the problematic code around. When this project is completed (within 6 weeks) I'll switch to Qt 4.2.x and retest the code. If it still breaks I'll lobby for a switch to MSVC 2005 and try again. It's kind of masochistic, but I need to know what the problem is.