[Dot] segfault when cluster and rank subgraph have the same node

[chtenb]

Example dot input:

digraph "Name" {
    subgraph "cluster_foo" {
        "n1";
    }
    subgraph "rank-1" {
        graph [rank=same];
        "n1";
    }
}

$ cat ~/Desktop/dump1.dot | ./dot.exe -Tpng > ~/Desktop/dump1.png
Segmentation fault

I'd say that is a bug, correct?

[ellson]

On Linux, the error is:

$ dot bug.gv Warning: n1 was already in a rankset, deleted from cluster Name dot: fastgr.c:231: delete_fast_node: Assertion `find_fast_node(g, n)' failed. Aborted (core dumped)

[chtenb]

Btw, is there a way to get this to be drawn correctly? The following code doesn't segfault, but shows no cluster boundary neither:

digraph "Name" {
    graph [compound=true];
    subgraph "rank-1" {
        graph [rank=same];
        subgraph "cluster_foo" {
            "n1";
        }
        "n1";
    }
}

[emden]

Definitely a bug. It is some strange interaction between the cluster being in a subgraph with rank=same set. (Go figure.) A simple workaround is to use newrank=true.

[chtenb]

What is the exact meaning of newrank=true? I've seen it before, but it doesn't seem to be documented.

[emden]

The original ranking algorithm was fairly complex, and tried to produce a very compact ranking. This could lead to some anomalies (at least to me), such as having an edge a->b in an acyclic graph but b appears above a in the ranking. In addition, it limited the constraints. For example, you couldn't have a node in a cluster constrained to be on the same rank as a node outside the cluster. Another problem with the old ranking algorithm is that it sometimes has problems handling conflicting constraints, and sometimes doesn't report them.

If you set newrank=true, dot uses a new ranking algorithm that is much simpler. It doesn't try to do anything fancy with clusters, but does a simple global optimization based on the constraints given in the graph. Rank constraints will usually take precedence over edge constraints (a->b means b is lower than a).

By the way, using newrank in the your original graph avoids the error.

I didn't document newrank because I thought we were going to decide if we wanted to make it the default. Unfortunately, years have passed.