Segmentation fault when using "layerselect"

Help
1

I’ve recently started to experiment with layers in Graphviz. I’ve however noticed that “dot” produces segmentation fault when I want to use any other layer in the layerselect attribute than the first one listed in the layers attribute. I’ve worked out that the behavior can be reproduced with the following minimal Bash code,

echo 'graph{}' | dot -Tjpg -Glayers='a b' -Glayerselect='b'

The result is the text “Segmentation fault (core dumped)”. The exit status is “139”. The expected behavior is that an “empty” diagram be produced. Note that I use the second layer in layerselect.

On the other hand, when I run nearly identical code,

echo 'graph{}' | dot -Tjpg -Glayers='a b' -Glayerselect='a'

then there is correctly produced a JPG file with an “empty” diagram (I can display it with feh), no errors. The exit status is “0”. Note that now I use the first layer in layerselect.

Is this an expected behavior or a bug? If this is an expected behavior, what am I doing wrong? Is there a workaround so that I be able to use any other layer in layerselect than the first one listed in layers?

dot -V gives dot - graphviz version 13.1.0 (20250701.0955).

uname -srm gives Linux 5.4.0-216-generic x86_64.

If you need more details, please tell which ones and I’ll post them.

2

A known bug (Using layerselect to produce a single layer fails for many output formats (#1648) · Issues · graphviz / graphviz · GitLab).

However, it will work as desired it you set the output format to svg, ps (Postscript), or pdf.

1 Like
3

Steve, thank you for that. It looks the bug you’ve reported is related to what I’ve encountered. If not the same, but to be sure I would need to see the layer.gv file, which you’re using in the code there.

I’m not able to accurately analyze the C patch you’ve proposed, but anyway, thank you for that! If it works for you, it’s one step closer to having it resolved in production. Can you say why the bug hasn’t been fixed so far?

I can confirm that segmentation fault in my case happens only for some file formats. Just to be sure and comprehensive, I’ve checked the formats that dot returns as a hint for an unrecognized format. (By the way, it’s much more than there’s listed in the “OUTPUT FORMATS” section in man dot. Shouldn’t it be the same list?) So, for the Bash code

{
    for x in 'bmp' 'canon' 'cmap' 'cmapx' 'cmapx_np' 'dot' 'dot_json' 'eps' 'fig' 'gv' 'ico' 'imap' 'imap_np' 'ismap' 'jpe' 'jpeg' 'jpg' 'json' 'json0' 'kitty' 'kittyz' 'pdf' 'pic' 'plain' 'plain-ext' 'png' 'pov' 'ps' 'ps2' 'svg' 'svg_inline' 'svgz' 'tif' 'tiff' 'tk' 'vt' 'vt-24bit' 'vt-4up' 'vt-6up' 'vt-8up' 'x11' 'xdot' 'xdot1.2' 'xdot1.4' 'xdot_json' 'xlib'
    do
        echo "$x"
        echo 'graph{}' \
            | >/dev/null dot -T"$x" -Glayers='a b' -Glayerselect='b' \
                && echo
    done
} &>/tmp/dot.log

# Here I am just formatting the output nicely
</tmp/dot.log paste -d ' ' - - \
    | gawk -F' ' '{
        printf ( "%s" , $1 )
        for ( x = 0 ; x < 16 - length ( $1 ) ; ++x ) {
            printf ( " " )
        }
        $1 = ""
        print $0
    }' \
    | sort -k2

I get

svg_inline      
xdot_json       
cmapx_np        
dot_json        
imap_np         
xdot1.2         
xdot1.4         
cmapx           
ismap           
json0           
cmap            
imap            
json            
svgz            
xdot            
eps             
pdf             
ps2             
svg             
ps              
gv               Segmentation fault (core dumped)
tk               Segmentation fault (core dumped)
vt               Segmentation fault (core dumped)
bmp              Segmentation fault (core dumped)
dot              Segmentation fault (core dumped)
fig              Segmentation fault (core dumped)
ico              Segmentation fault (core dumped)
jpe              Segmentation fault (core dumped)
jpg              Segmentation fault (core dumped)
pic              Segmentation fault (core dumped)
png              Segmentation fault (core dumped)
pov              Segmentation fault (core dumped)
tif              Segmentation fault (core dumped)
x11              Segmentation fault (core dumped)
jpeg             Segmentation fault (core dumped)
tiff             Segmentation fault (core dumped)
xlib             Segmentation fault (core dumped)
canon            Segmentation fault (core dumped)
kitty            Segmentation fault (core dumped)
plain            Segmentation fault (core dumped)
kittyz           Segmentation fault (core dumped)
vt-4up           Segmentation fault (core dumped)
vt-6up           Segmentation fault (core dumped)
vt-8up           Segmentation fault (core dumped)
vt-24bit         Segmentation fault (core dumped)
plain-ext        Segmentation fault (core dumped)

Update. I’ve noticed that running the following code I don’t have segmentation fault, although I would expect it.

echo 'graph{}' | dot -Tjpg -Glayers='2 1' -Glayerselect='1'

Update. As for my question about a workaround, for now I’ve resolved to set the output format to pdf. Then I can convert the file to a JPG or PNG (e.g. using the convert tool).

4

Nope, I can’t address why this bug has not been fixed. I am not a compentent C coder, more of a free-range assistant.
While I think layers are cool, you and I are in the minority.

Here is layer.gv (part of the source):

// SOURCE: Graphviz Source ./tests/graphs/layer.gv
digraph G {
	layers="local:pvt:test:new:ofc";

	node1  [layer="pvt"];
	node2  [layer="all"];
	node3  [layer="pvt:ofc"];		/* pvt, test, new, and ofc */
	node2 -> node3  [layer="pvt:all"];	/* same as pvt:ofc */
	node2 -> node4 [layer=3];		/* same as test */
}

Here is a different workaround. It uses gvpr to rearrange the layers value to put the desired layer in the 1st position. The gvpr code is a little fiddly, and assumes the standard values for layersep (layersep | Graphviz), but it seems to work.

L=    ## <<assign the desired layer here
f=    ## << assign your file name here
T=png;  ## or any other desired format
F=${f%.*};
gvpr -a"$L" -c '
BEG_G{
int n,i;string tok[int];
n=tokens(layers,tok," :\t");
layers=ARGV[0];
for (tok[i])if (tok[i]!=ARGV[0])
  layers=layers+" "+tok[i];
}' $f |
dot -Glayerselect="$L" -T$T -o$F.$T;

Whoops, the man page is out-of-date.
Here is a better reference: Output Formats | Graphviz

1 Like
5

Thanks for layer.gv. I guess then that our problems are the same. Irrespectively of whether a layer exists or not, if it’s not the first listed, Graphviz produces a segmentation fault.

Also, thanks for the workaround in gvpr! I don’t know that language, but your code looks quite simple. But I don’t know if it’s going to be of any help to me. I have yet to see how I’m going to use layers.

Also, thanks for the reference. Well, I now have read the man page more carefully, and it says that

to see what output formats your installation of dot supports[,] you can use ``dot -T:‘’ and check the warning message.

So you can say that this hint, in a way, makes the man page always up to date.

6

If all goes smoothly, this will be fixed in the next Graphviz release: fix: anticipate layers with null identifiers (!4436) · Merge requests · graphviz / graphviz · GitLab

3 Likes
7

Thanks, Matthew! I did see yesterday your activity in the GitLab issue, but generally I didn’t expect anything to be done so quick! (Maybe this thread has influenced it, maybe not, I don’t know, but am glad either way.)

Steve, will you mind I un-mark your post in this thread as a “solution”, and mark Matthew’s instead?

8

I do not mind at all. @smattr is doing the heavy lifting

1 Like
9

We have too few hands and too many bugs. So it’s mostly a case of the squeaky wheel getting the grease. This thread prompted me to take a look at that issue.

1 Like
10

Well, GitLab says Graphviz is mostly C, so if I knew C better, I could offer some help. But now I can only say that if I find another bug, I’ll do my best in helping to fix it, even if it means just reminding about it.

1 Like