[Output Generation] Relayout skews cmapx coordinates with gv_python
Ported Issue from Mantis Original ID: 1056 Reported By: Juhani Eronen
SEVERITY: MINOR Submitted: 2006-02-06 17:15:21
OS: X86-LINUX-
VERSION: 2.9
DESCRIPTION
If gv.layout is called an extra time between rendering an
image and the associated image map in a gv_python script,
the coordinated of the resulting image map will be skewed
by a constant amount. Removing the extra layout or doing
new renders of the image and the cmapx corrects the error.
The input gives the script I used to discover the problem
ADDITIONAL INFORMATION
[erg] In general, one should never do another layout without first doing a gvFreeLayout. In the best case, you're causing a significant memory leak. In the worst case, the layout algorithms rely on fields in the data structures being 0. If gvFreeLayout is not called, many fields will already be set, which can cause a crash or a totally different layout.
Also, although not happening here, neato sometimes relies on a random number generator for initial node placement. Thus, two layouts of the same graph might be totally different. This can even occur using a pipeline like
cat x.dot x.dot | neato
where neato doesn't get a chance to reset the RNG.
[ellson] I'd prefer not to expose memory management issues to the script interfaces, so I've just put in a change to CVS so that a gv.layout will first cleanup any previous layout.
[exec] There seem to be some memory leaks regarding relayouts. One of the projects I'm involved in is a network traffic visualiser of sorts, and in that application, we have very dynamic graphs where layouts change at rapid rates - new nodes are introduced, old ones removed and so on. The problem is that relayouts with current gv_python often results in crashes.
I have not managed to create a simple test file that would demonstrate you the crashes. However, while analysing the execution of a simpler test script with the Valgrind debugging tools, I may have managed to determine the probable cause of the crashes - Valgrind gave very similar outputs for these crashes as to the test script. (Valgrind detects memory management issues, and seems actually quite useful at that.)
I'm attaching the test script along with the report I got from Valgrind about the memory leaks it caused, along with the tool's command line usage.
As the third attachment, I include stack traces of the four different core dumps I have managed to bring about with the network visualisation tool in different contexts. All of the crashes seem to be related and may have the same cause, which is possibly gvFreeLayout. Hope you'll find them useful - if you have any trouble with debugging this, I'll be glad to help if I can.
Just one more thing - the core dumps are taken from a build with all compiler optimisations off (that was the source of the "Source file is more recent than executable." warnings).