Crash: QWidget::Repaint: Recursive repaint detected

Post here for help on using FreeCAD's graphical user interface (GUI).
Forum rules
and Helpful information
IMPORTANT: Please click here and read this first, before asking for help

Also, be nice to others! Read the FreeCAD code of conduct!
chrisf1874
Posts: 8
Joined: Sat Aug 10, 2013 10:45 am

Crash: QWidget::Repaint: Recursive repaint detected

Postby chrisf1874 » Sat Sep 07, 2013 7:04 am

Hi all,
I'm steadily getting to grips with FreeCAD and am now enjoying producing parts with it. I've had a lot of stability problems though (Ubuntu 13.04 64 bit - Qt 4.8.4 - Freecad 0.13R1830). It's got better since I updated my Intel graphics drivers but I'm still getting regular crashes when deleting objects. It's not associated with any particular file and I haven't been able to figure out what order of actions causes it.

Running under gdb, it always looks like this:
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff5925b51 in ?? () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4

and the log file reports remove selection followed by:
QWidget::Repaint: Recursive repaint detected

My limited experience with Qt is that the above error is often caused by code that calls the Repaint() method when you should call Update() which will then schedule a later Repaint.

Is this a common problem or something to do with my setup or workflow?
wmayer
Site Admin
Posts: 14892
Joined: Thu Feb 19, 2009 10:32 am

Re: Crash: QWidget::Repaint: Recursive repaint detected

Postby wmayer » Sat Sep 07, 2013 8:33 am

It has something to do with Qt. With older Qt versions we didn't have this problem but it started with Qt 4.8.1 IIRC. The big question is if it's just a different behaviour of Qt or is it a bug. The second question is how can we work around this issue?
chrisf1874
Posts: 8
Joined: Sat Aug 10, 2013 10:45 am

Re: Crash: QWidget::Repaint: Recursive repaint detected

Postby chrisf1874 » Sat Sep 07, 2013 3:49 pm

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.

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 unanswered question on Stack Overflow suggests that Tulip (?) has a similar problem with the change from Qt 4.7 to 4.8. The poster says he got rid of the problem by compiling against Qt5 but that did introduce other issues.
User avatar
yorik
Site Admin
Posts: 11566
Joined: Tue Feb 17, 2009 9:16 pm
Location: São Paulo, Brazil
Contact:

Re: Crash: QWidget::Repaint: Recursive repaint detected

Postby yorik » Sat Sep 07, 2013 4:25 pm

This problem is apparently the same as this: https://sourceforge.net/apps/mantisbt/f ... hp?id=1140
wmayer
Site Admin
Posts: 14892
Joined: Thu Feb 19, 2009 10:32 am

Re: Crash: QWidget::Repaint: Recursive repaint detected

Postby wmayer » Sat Sep 07, 2013 4:47 pm

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 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.
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 can be excluded, too.

IMO this is a bug in Qt itself. In the past we had some similar issues where it worked to generate an event instead of calling a function directly. Maybe we can apply this trick here, too.
chrisf1874
Posts: 8
Joined: Sat Aug 10, 2013 10:45 am

Re: Crash: QWidget::Repaint: Recursive repaint detected

Postby chrisf1874 » Sun Sep 08, 2013 9:25 am

I've established something else about this issue:
- If you want it to happen so that you can look at a backtrace in gdb, it will take over half an hour of deletes to cause it
- If you decide to ignore it and get on with some work, it'll bomb within 5 minutes
:roll:
The backtrace didn't show anything useful BTW.

I found a post attributing similar problems (albeit Qt4.7) to desktop themes so switched my Ubuntu 13.04 from 'ambience' to 'radiance' but still got a crash.

Is there a debug build setting that I can use to get more information about the order of events?
wmayer
Site Admin
Posts: 14892
Joined: Thu Feb 19, 2009 10:32 am

Re: Crash: QWidget::Repaint: Recursive repaint detected

Postby wmayer » Sun Sep 08, 2013 12:37 pm

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).
chrisf1874
Posts: 8
Joined: Sat Aug 10, 2013 10:45 am

Re: Crash: QWidget::Repaint: Recursive repaint detected

Postby chrisf1874 » Sun Sep 08, 2013 2:10 pm

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).
This sounds good. Can you elaborate on how to disable and reenable updates of the main window and I'll test on my system.

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?
wmayer
Site Admin
Posts: 14892
Joined: Thu Feb 19, 2009 10:32 am

Re: Crash: QWidget::Repaint: Recursive repaint detected

Postby wmayer » Sun Sep 08, 2013 3:13 pm

Can you elaborate on how to disable and reenable updates of the main window and I'll test on my system.
Simply pull the latest changes from the git repo. But FYI, it's like this:

Code: Select all

getMainWindow()->setUpdatesEnabled(false);
// .. do the delete
getMainWindow()->setUpdatesEnabled(true);
getMainWindow()->update();
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?
I'm not what you are trying to do but doing any selection changes from within a thread is not allowed.
chrisf1874
Posts: 8
Joined: Sat Aug 10, 2013 10:45 am

Re: Crash: QWidget::Repaint: Recursive repaint detected

Postby chrisf1874 » Sun Sep 15, 2013 1:49 pm

I've been working with the patched code and was pretty confident that the changes had fixed this issue (about five hours without a crash) until just now when I got a crash on deleting an imported stp object.

QWidget::repaint: Recursive repaint detected
*** Abort *** an exception was raised, but no catch was found.
... The exception is:Bnd_Box is void

I hadn't seen this report before, maybe there's a clue?