|Anonymous | Login||2017-11-21 18:30 EST|
|Main | My View | View Issues | Change Log | Roadmap | My Account|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0001056||graphviz||Output Generation||public||2006-02-06 12:15||2011-04-28 04:03|
|Summary||0001056: 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
[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
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 HREF=b878a.py\>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).
|Tags||No tags attached.|
|AUXILLARY-FILES||http://www.graphviz.org/bugs/b878a.py [^] http://www.graphviz.org/bugs/b878.txt [^] http://www.graphviz.org/bugs/b878a.txt [^]|
|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|