Столкнулся с ситуацией, когда QTreeWidget::clear() роняет программу. Только из-за того, что используются его сигнал currentItemChanged(...)
В обработчике сигнала банальный код:

void MainWindow::currentItemChanged(QTreeWidgetItem * current, QTreeWidgetItem *)
{
    qDebug() << "currentItemChanged";
    QTreeWidgetItem *parentItem = current->parent();
    if (parentItem)
        deleteFileAction->setEnabled(true);
    else
        deleteFileAction->setDisabled(true);
}

Если очистку обернуть так:

    m_tree->blockSignals(true);
    m_tree->clear();
    m_tree->blockSignals(false);

то проблема больше не возникает. Однако такое поведение всё равно лажа.

П.С.
Использована Qt 4.7.0



ещё одно решение - проверять current, т.е.:

void MainWindow::currentItemChanged(QTreeWidgetItem * current, QTreeWidgetItem *)
{
    qDebug() << "currentItemChanged";
    if (!current) return; // <---
    QTreeWidgetItem *parentItem = current->parent();
    if (parentItem)
        deleteFileAction->setEnabled(true);
    else
        deleteFileAction->setDisabled(true);
}

Но и это по сути обход проблемы, т.к. если текущий элемент умер, то зачем же сигналить так?

В багзиллу.

я так и поступаю всегдаПотому что этот сигнал содержит еще и предыдущий элемент, и он валидный. Пользователю это может понадобиться (не спрашивайте зачем). Просто это особенность которую нужно знать. ИМХО, это скорее недостаток документации, а не бага Qt

О недостатках документации тоже лучше сообщать.
Это не оно -- http://bugreports.qt.nokia.com/browse/QTBUG-16614 ?

да похоже.

в примерах у тролей тоже, но нигде ни слухом ни духом о том, зачем.согласен. Если поведение считается нормой, то должно быть задокументировано.

Проголосуйте в том баге тогда, ведь вы с ним тоже столкнулись .

Да он не такой уж значимый, что бы за него голосовать. Есть баги по важнее. Решат в порядке очереди.