This can be excluded from our side. BTW, IMO the reported bug is not really a bug because it mainly depends on how the signal/slot connection is created. If it's a direct connection then it's like calling repaint() from within which according to the docs must be avoided. But anyway, that's not our problem.This query on qt-project.org confirms what I remembered about calls to repaint() causing this problem and that you should only call update(). Having searched the freecad code, however, I can only find one call to repaint() on line 347 of HelpView.cpp in TextBrowser::done so I don't expect that is the cause.
This can be excluded, too.Again, on qt-project.org there's a question about the problem with the suggestion that widget updates are not thread safe so you should always use a signal/slot mechanism to update widgets from outside of the main GUI thread. Is that a possible cause?
This sounds good. Can you elaborate on how to disable and reenable updates of the main window and I'll test on my system.wmayer wrote:I built FreeCAD on Ubuntu 12.10 and there I could reproduce this crash every time I tried it. But after all IMO this is clearly a Qt bug because it crashes when an internal update is done after deleting an element from the tree view. Important here is to create enough elements so that the tree view shows a scrollbar. Then you have to scroll down to a hidden element and delete this one.
However, I found a work around which solves the issue for me on Ubuntu 12.10 (Qt 4.8.3). The trick is to disable the updates of the main window before deleting elements, enable it afterwards and then also trigger an update. This must be done inside StdCmdDelete::activated(int).
Simply pull the latest changes from the git repo. But FYI, it's like this:Can you elaborate on how to disable and reenable updates of the main window and I'll test on my system.
Code: Select all
getMainWindow()->setUpdatesEnabled(false); // .. do the delete getMainWindow()->setUpdatesEnabled(true); getMainWindow()->update();
I'm not what you are trying to do but doing any selection changes from within a thread is not allowed.I started trying to trace behaviour from SelectionSingleton::rmvSelection. That's running in a boost thread. I read what you wrote about ruling out calling update from another thread but is it not possible that the update is triggered from this thread? That would be consistent with your work-around?