8

Using David Brown's downloadable sample at ImplicitOperator I've put together an often working GraphViz renderer of a DOT file to an in-memory image.

Unfortunately, my version fails at a guestimated rate of 1 in 8 executions from with the IIS 7 ASP.NET web application I've got it in. I know that the DOT file data is consistent because I've compared the failing instances against the working instances and they are identical.

As David's site seems to suggest that the blog's future is uncertain, I'll reprint the interop pieces here. Hope he doesn't mind. The failure is toward the end of the sample, within RenderImage at the third statement set. I've noted the failing line with // TODO: .... The failure always happens there (if it happens at all). By this line, g and gvc pointers are non-zero and the layout string is correctly populated.

I don't really expect anyone to debug this at runtime. Rather, I hope that some static analysis of the interop code might reveal the problem. I can't think of any advanced marshaling techniques available here - two IntPtrs and a string shouldn't need a lot of help, right?

Thanks!

Side note: I've looked at a trial of MSAGL and I'm not impressed - for $99 from Microsoft, I'd expect more features for node layout and/or documentation explaining what I'm missing. Maybe my rapid port from QuickGraph to AGL unfairly biases my experience because of some fundamental differences in the approaches (edge-centric vs node-centric, for example).

public static class Graphviz
{
  public const string LIB_GVC = "gvc.dll";
  public const string LIB_GRAPH = "graph.dll";
  public const int SUCCESS = 0;

  /// <summary> 
  /// Creates a new Graphviz context. 
  /// </summary> 
  [DllImport(LIB_GVC)]
  public static extern IntPtr gvContext();

  /// <summary> 
  /// Releases a context's resources. 
  /// </summary> 
  [DllImport(LIB_GVC)]
  public static extern int gvFreeContext(IntPtr gvc);

  /// <summary> 
  /// Reads a graph from a string. 
  /// </summary> 
  [DllImport(LIB_GRAPH)]
  public static extern IntPtr agmemread(string data);

  /// <summary> 
  /// Releases the resources used by a graph. 
  /// </summary> 
  [DllImport(LIB_GRAPH)]
  public static extern void agclose(IntPtr g);

  /// <summary> 
  /// Applies a layout to a graph using the given engine. 
  /// </summary> 
  [DllImport(LIB_GVC)]
  public static extern int gvLayout(IntPtr gvc, IntPtr g, string engine);

  /// <summary> 
  /// Releases the resources used by a layout. 
  /// </summary> 
  [DllImport(LIB_GVC)]
  public static extern int gvFreeLayout(IntPtr gvc, IntPtr g);

  /// <summary> 
  /// Renders a graph to a file. 
  /// </summary> 
  [DllImport(LIB_GVC)]
  public static extern int gvRenderFilename(IntPtr gvc, IntPtr g,
    string format, string fileName);

  /// <summary> 
  /// Renders a graph in memory. 
  /// </summary> 
  [DllImport(LIB_GVC)]
  public static extern int gvRenderData(IntPtr gvc, IntPtr g,
    string format, out IntPtr result, out int length);

  public static Image RenderImage(string source, string layout, string format)
  {
    // Create a Graphviz context 
    IntPtr gvc = gvContext();
    if (gvc == IntPtr.Zero)
      throw new Exception("Failed to create Graphviz context.");

    // Load the DOT data into a graph 
    IntPtr g = agmemread(source);
    if (g == IntPtr.Zero)
      throw new Exception("Failed to create graph from source. Check for syntax errors.");

    // Apply a layout 
    if (gvLayout(gvc, g, layout) != SUCCESS) // TODO: Fix AccessViolationException here
      throw new Exception("Layout failed.");

    IntPtr result;
    int length;

    // Render the graph 
    if (gvRenderData(gvc, g, format, out result, out length) != SUCCESS)
      throw new Exception("Render failed.");

    // Create an array to hold the rendered graph
    byte[] bytes = new byte[length];

    // Copy the image from the IntPtr 
    Marshal.Copy(result, bytes, 0, length);

    // Free up the resources 
    gvFreeLayout(gvc, g);
    agclose(g);
    gvFreeContext(gvc);

    using (MemoryStream stream = new MemoryStream(bytes))
    {
      return Image.FromStream(stream);
    }
  }
}
Jason Kleban
  • 20,024
  • 18
  • 75
  • 125
  • 1
    I know this might sound stupid. But is there a need to run the dll directly in your code? Would it be possible to generate the dot language in a text file and then run the standalone dot executable with a command like: "dot -Tpng -o MyFile.png MyFile.dot" using the C# Process class? Once you have the image you could just load it directly into your programs memory. – jluzwick Feb 02 '11 at 00:43
  • I guess that's an option, but dealing with files on disk for this operation would be slow AND would introduce additional points of failure in the I/O mechanisms themselves. Since the dll is employed either way, I'd rather understand how to make it work properly in memory. – Jason Kleban Feb 02 '11 at 04:12
  • Could you show the usage of your class? – Bruno Machado - vargero Mar 25 '12 at 19:04
  • @Bruno - to what end? To solve the bug or use it as good as it works? To use it, just `GraphViz.RenderImage()` passing your DOT source, layout engine name, and I forget what `format` is. – Jason Kleban Mar 26 '12 at 05:00
  • @uosɐſ: Thanks. I was intending to use it but I solved my problem by calling "dot.exe" as a process. – Bruno Machado - vargero Mar 26 '12 at 16:24

3 Answers3

5

Visual Studio 2010 added a "PInvokeStackImbalance" detection that I think helped me fix the problem. While the image would still get generated, I would get this error several times.

By specifying CallingConvention = CallingConvention.Cdecl on all the LIBGVC PInvoke sigantures, the error and crashes disappear.

[DllImport(LIB_GVC, CallingConvention = CallingConvention.Cdecl)]
public static extern IntPtr gvContext();

[DllImport(LIB_GVC, CallingConvention = CallingConvention.Cdecl)]
public static extern int gvFreeContext(IntPtr gvc);

...

I've had no crashes since making this change, so I'll mark this as the new answer, for now.

Jason Kleban
  • 20,024
  • 18
  • 75
  • 125
4

I remember running into problems like this while I was working on the article and posted questions about them here and here (the second of which you appear to have commented on; my apologies for not seeing the comment earlier).

The first question is probably not directly related to this because I was writing a test application in C, not C#, and gvLayout was failing every single time instead of just every now and then. Regardless, make sure your application does have access to the Graphviz configuration file (copy it alongside your executable or place the Graphviz bin directory in your system PATH).

The second question is more relevant, except it applies to agmemread and not gvLayout. However, it's very possible that both are caused by the same issue. I was never able to figure out a solution, so I sent the Graphviz team a bug report. Unfortunately, it hasn't been resolved.

The Graphviz API is very simple, so it's unlikely that the issue is caused by the interop code. There is one thing that I neglected to mention in the article: the result pointer needs to be freed. I don't know if this will fix your issue, but it's still a good idea to add it anyway:

[DllImport("msvcrt.dll", SetLastError = true)]
private static extern void free(IntPtr pointer);

// After Marshal.Copy in RenderImage
free(result);

As far as I know, this issue is related to how Graphivz recovers from internal errors, so until the bug is addressed, I'm not sure there's anything you or I can do. But, I'm not an interop expert, so hopefully someone else can help you out a little more.

Community
  • 1
  • 1
David Brown
  • 35,411
  • 11
  • 83
  • 132
  • Hi David. Thanks for the response and the code change. I tried to apply it and it now crashes ALWAYS on free(result); Any idea why? Maybe my other code is out of sync with yours? – Jason Kleban Feb 03 '11 at 01:11
  • I just ran the sample with the `free` code again and it crashed for me, as well. Not sure why it didn't do that a year ago, though. Here's a bug report about it (unresolved, unfortunately): http://www.graphviz.org/bugs/b1775.html – David Brown Feb 03 '11 at 02:36
  • Bummer. GraphViz has the best node layout engine and overall options, but has these two unresolved bugs we've been discussing. And I found them both in what I would consider a fairly basic application, so they're close to the surface. Plus, no x64 distribution. I feel like I know how to rewrite everything my ideal way in C# except for the edge routing algorithms. – Jason Kleban Feb 03 '11 at 18:11
0

changing the calling convention DOESN'T help!!

Yes, it works when a simple (actually not that simple) dot source, but it ALWAYS crash if the dot source containing unicode character (simplified chinese).

Alsan
  • 399
  • 1
  • 4
  • 15
  • 1
    Perhaps that's a different issue which ALSO crashes? I don't know that Graphviz supports unicode, do you? [Here is a link that mentions using html-encoding of unicode characters for some content.](http://www.graphviz.org/doc/info/lang.html) – Jason Kleban Jul 23 '12 at 18:56
  • Yes, I can confirm Graphviz does support unicode. I can generate a correct graph by hand-written dot file. – Alsan Nov 02 '12 at 11:52