Number: 878
Title: Relayout skews cmapx coordinates with gv_python
Submitter: Juhani Eronen
Date: Mon Feb 6 12:15:21 2006
Subsys: Output generation
Version: 2.9
System: x86-Linux-
Severity: minor
Problem:
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
Input file: b878.py
Comments:
[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).
Owner: ellson
Status: *