Recursive repaint detected (*not like other problems), how do I remove the issue?

[kennethadammiller]

A brief synopsis: I'm reposting a question that is located (here (http://stackoverflow.com/questions/17220566/qt-tulip-recursive-repaint-detected-in-main-how-to-identify-and-repair-error)) in the hopes that someone on this forum will be more likely to have more knowledge. I really need an answer to this problem!

Here's the problem summary, if you don't follow the link to SO as well as the links that are at that page:

I've compiled a project built off of Qt, (Tulip (tulip.labri.fr)). Tulip provides some headers in order that other developers that come along can build software off of what they provide. I've been able to use the CMake build system to compile (what's meant to be) my own standalone gui. The problem is that when I try to run it, I get an error where it says recursive repaint detected, and then it drops a core dump and dies. The thing is, all I did was copy code from the tutorials (links to source provided at the SO site that I linked up above) provided by them, so I would think that the code for this example would work properly.

[wysota]

Is this main() your whole code? There is nothing Qt specific in there. If the code fails, the problem is within tulip (or your use of it) so better ask on some tulip-dedicated site.

[kennethadammiller]

Yeah, that main is my whole code.... although I just noticed that I was linking an extra header to it called modib.h. I removed that and updated the CMakeLists.txt to not include the Tulip library (I know that might sound confusing, but in the tulip sources meant to be built against have a lot of different libraries, its broken down a lot).

And I've asked the tulip people, but they aren't answering. I guess the only alternative now is to dig through their source and mine in order to figure out why its doing this.

Added after 19 minutes:

You know what I just found in their documentation however? The centerScene function is actually a slot. Does that mean I really do need to code it up using signals and slots?

Added after 29 minutes:

Also, I narrowed down what makes it crash. The code, without being modified crashes in processEvents; but when mainWidget->show() is not called or is commented out, it doesn't crash, but then it doesn't show the window. I can get it to show the window and not crash by removing the lines

GlLayer* mainLayer = mainWidget->getScene()->createLayer("Main");
mainLayer->addGraph(g,"graph");

But at this point, it doesn't show the nodes or edges that are in the file that I'm passing as an argument to be shown as a graph.

Added after 1 8 minutes:

So, it turns out, they did in fact release a demo that doesn't work with this version. They really need some comprehensive unit testing to be done as well because clearly, if they had some unit tests to fail when packaging it, they would know to update the demos.

Anyway, I literally used Cmake on the demos folder included in the actual, out of the box, source-literally going back to the root from where I had started adapting things to suit my needs to make sure that one of my changes hadn't broken anything. Turns out, I get the exact same error. Conclusion is that it is an out of date plugin.

So now, I need to dig through their source and find out why its dying, perhaps looking at the tulip source itself to see if I can get a viable example to build from.

[wysota]

Check the backtrace from the debugger.

[kennethadammiller]

Well I did give the backtrace that I originally had as a link on the original stack overflow link that I posted, but I will repeat and gather the backtrace for you as you request.

Here is the link to the original backtrace:

https://gist.github.com/anonymous/0b356a82ec3e9ff71e01

Added after 56 minutes:

Here is a link to an updated error log; the first is from literally adapting the CMakeLists.txt for the provided sample enough in order that it would compile, and then trying to run it, in which case I get an error:

https://gist.github.com/anonymous/44ee163e5c07b1f52f1a

The second, below, is from running my own. Although the source is exactly the same, there may be some difference, because I wrote the CMakeLists.txt as an adapted example provded for something else.

https://gist.github.com/anonymous/7d3c1158d33774251f5a

[kennethadammiller]

Ok, now the most up to date information that I have on this is the following:

having perused through their commit history on their sourceforge website, I found that they recently announced that it could be compiled with Qt5. So I went about installing everything I needed to, rebuilt ALL of tulip under qt5, and rebuilt my example linking to the new qt5. I get a new stack dump now.

https://gist.github.com/anonymous/4eb5e809cd36b465aa64

It is still dying under the show command. For everyone's information, the example I'm running uses a mainWidget pointer to a GlMainWidget. After looking it up in their documentation, found that thei GlMainWidget extends QGLWidget.

http://harmattan-dev.nokia.com/docs/library/html/qt4/qglwidget.html

http://tulip.labri.fr/Documentation/4_3/doxygen/_gl_main_widget_8h_source.html

The line that that particular stack trace refers to is where it calls mainWidget->centerScene(); this centerScene function is described at the link above, but its declared as a public slot. Does that mean I need to call it using the signals/slots thing that Qt developed?

[anda_skoa]

The line that that particular stack trace refers to is where it calls mainWidget->centerScene(); this centerScene function is described at the link above, but its declared as a public slot. Does that mean I need to call it using the signals/slots thing that Qt developed?

No, a slot is just a normal C++ method, it can be called directly.

Cheers,
_

[kennethadammiller]

Ok, I found the exact error:

In FTSize.cpp of their thirdparty/ftgl directory, at line 49, they have this:

err = FT_Set_Char_Size(*face, 0L, pointSize *64, xResolution, yResolution);

It's trying to dereference a null pointer at face;

I put these lines in:

if (!face)
std::cout << "face " << face << std::endl;

and I got "face 0" output when running it under gdb.