Graphviz Issue Tracker
Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0001056graphvizOutput Generationpublic2006-02-06 12:152011-04-28 04:03
ReporterJuhani Eronen 
Assigned Toellson 
PlatformOSx86-Linux-OS Version
Summary0001056: Relayout skews cmapx coordinates with gv_python

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 | 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

I'm attaching the \<A\>test script\</A\> along with the
\<A HREF=b878.txt\>report\</A\> I got from
Valgrind about the memory leaks it caused, along with the tool's
command line usage.

As the third \<A HREF=b878a.txt\>attachment\</A\>,
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).

TagsNo tags attached.
VERSION     2.9
Attached Files

- Relationships

-  Notes
There are no notes attached to this issue.

- Issue History
Date Modified Username Field Change
2011-04-28 04:03 user1 New Issue
2011-04-28 04:03 user1 Assigned To => user695

MantisBT 1.2.5[^]
Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker