Several tasks in the CI setup were allowed to run on tagged commits. This meant
that pushing a new tag would result in re-running CI on the tagged commit. This
was already confusing, but was compounded by these unrestricted tasks depending
on non-tag-only tasks. The result was that CI would stall and fail because
dependencies could not be satisfied.
To fix this we simply disallow all CI on a tag. This means that a tagged commit
that is not on any branch will not be tested. However, no one should be pushing
such a commit to the Graphviz repository. All tagged commits that are on a
branch will be tested via their SHA. This is not expected to cause any problems
as the Graphviz build system never checks the Git tag or whether a commit is
tagged at all.
Two implementations of RectArea were provided that implemented the overflow
check based on whether there was a larger type than unsigned int available. It
is unnecessary to maintain multiple implementations of this as the overflow
check can be written in a width-independent way.
Moreover the `LLONG_MAX > UINT_MAX` alternative was incorrect. E.g. on x86-64
where this alternative is used, if `r->boundary[i + NUMDIMS] - r->boundary[i]`
is `UINT_MAX` and the accumulated value in `a_test` is `(long long)UINT_MAX`,
the multiplication (which is done on operands promoted to long long) overflows
causing undefined behavior. In practice, you would likely get a negative value,
that then erroneously passes the overflow check.
fix: remove Circo test of root.gv from rtest.py-tested graphs
This graph generates an overflow when computing the area of rectangles required
to layout it out. It should be rejected but it currently incorrectly is not.
Related to #1906.
The build system detection of Guile was relying on a binary named guile-config.
As of Guile 2.2, coexisting versions of Guile are supported and so the
guile-config binary is suffixed with its version. The result of this mismatch
was that the build system would fail to detect Guile 2.2 on platforms that did
not provide a guile-config redirection shim.
Guile 3.0 has already been out for awhile, but this commit does not add support
for it. The devel packages for it do not seem yet available on any major Linux
distro. We should extend this support to 3.0 when it becomes more widely
available if Graphviz' use of Guile is compatible. Related to #1885.
fix: lookup Guile version by guile-config, not guile
The Autotools build system was using the binary "guile" to detect what version
of Guile to build and link against. However, this is the Guile runtime system,
not the Guile developer dependencies. The effect of this was that the build
system could detect e.g. Guile 2.0 when guile20-devel was not installed. Related
to #1885.
These look to have been copied from Dockerfiles for other OSes that install
python2-devel or its equivalent. However, these ones do not so this comment does
not belong here.
This code was attempting to avoid an expensive call to strcasecmp when the first
byte already indicates a mismatch. Modern compilers can perform this
optimization themselves, including inlining strcasecmp and unrolling and
vectorizing its loop. Manually comparing the first byte actually impedes the
compiler because it's harder for it to see your intent. Related to #1913.
fix incorrect parsing of ALIGN attribute in a <BR> HTML tag
The logical operators here were incorrect. Rather than flipping them to the
correct operators, we undo this micro-optimization and write this code in a more
obvious manner. Fixes #1913.
use libc limit constants instead of defining our own
These are available in the C standard library even prior to C89. This change has
no effect on functionality, as the replaced constants have identical values.
NULL is more concise and more widely understood than the Graphviz-specific macro
NIL. We leave the definitions of NIL in case others are using these through the
public API.
VPSC: uniformly treat objects as structs that need to be exposed to C
The keywords "class" and "struct" are synonyms in C++, except for changing the
default visibility of declarations within the object. By using struct for
anything that needs to be declared in the C API, we can avoid some #ifdef mess
in this header.
Like the change to add_tree_edge(), this also fixes some resource leakage that
occurred in this error path. Now the tree list in rank2 is correctly cleaned up
on error. Related to #1801.
This also fixes some resource leaks that occurred in this path. The longjmp()
would jump over some intermediate allocations that had been made, whereas we now
return back through the callers, cleaning up resources as we go. Related to
#1801.
It looks to me as if cdc5efaf40d94b1020b650d654f94ebf0a856c62 attempted to
consolidate Qt5 support but actually erroneously re-enabled Qt4 qmake support.
This re-enabled qmake doesn't work because it produces a Makefile designed to
work with Qt4, while the CFLAGS and LDFLAGS set by PKG_CHECK_MODULES are all
based on Qt5 library names.
The outcome of this is that building on a Linux machine with libqt5 and
libqt4-dev installed but *not* libqt5-dev (a legal configuration) causes
Graphviz compilation to fail when processing GVEdit #includes it cannot find.
The fix here is to simply remove support for Qt4's qmake because Qt4 is
deprecated [0] and force the build system to find Qt5's qmake. Closes #1862.
make_label() internally strdups its input, so this extra allocation was simply
being lost. This was observable using an ASan-instrumented build and the command
`dot -Tsvg -o /dev/null ./rtest/share/alf.gv`:
Direct leak of 121 byte(s) in 12 object(s) allocated from:
#0 0x7fd2541bf810 in strdup (/lib/x86_64-linux-gnu/libasan.so.5+0x3a810)
#1 0x7fd25404a955 in parse_reclbl /tmp/tmp.bXYbsH93VJ/graphviz/lib/common/shapes.c:3314
#2 0x7fd25404a5eb in parse_reclbl /tmp/tmp.bXYbsH93VJ/graphviz/lib/common/shapes.c:3292
#3 0x7fd25404ca5f in record_init /tmp/tmp.bXYbsH93VJ/graphviz/lib/common/shapes.c:3556
#4 0x7fd25405966a in common_init_node /tmp/tmp.bXYbsH93VJ/graphviz/lib/common/utils.c:658
#5 0x7fd24fc78a01 in dot_init_node /tmp/tmp.bXYbsH93VJ/graphviz/lib/dotgen/dotinit.c:40
#6 0x7fd24fc79522 in dot_init_node_edge /tmp/tmp.bXYbsH93VJ/graphviz/lib/dotgen/dotinit.c:81
#7 0x7fd24fc7ad61 in dotLayout /tmp/tmp.bXYbsH93VJ/graphviz/lib/dotgen/dotinit.c:295
#8 0x7fd24fc7c4b9 in doDot /tmp/tmp.bXYbsH93VJ/graphviz/lib/dotgen/dotinit.c:450
#9 0x7fd24fc7ca94 in dot_layout /tmp/tmp.bXYbsH93VJ/graphviz/lib/dotgen/dotinit.c:496
#10 0x7fd253f7673d in gvLayoutJobs /tmp/tmp.bXYbsH93VJ/graphviz/lib/gvc/gvlayout.c:85
#11 0x55a9961b3960 in main /tmp/tmp.bXYbsH93VJ/graphviz/cmd/dot/dot.c:132
#12 0x7fd253d2309a in __libc_start_main ../csu/libc-start.c:308
Direct leak of 118 byte(s) in 19 object(s) allocated from:
#0 0x7fd2541bf810 in strdup (/lib/x86_64-linux-gnu/libasan.so.5+0x3a810)
#1 0x7fd25404a955 in parse_reclbl /tmp/tmp.bXYbsH93VJ/graphviz/lib/common/shapes.c:3314
#2 0x7fd25404ca5f in record_init /tmp/tmp.bXYbsH93VJ/graphviz/lib/common/shapes.c:3556
#3 0x7fd25405966a in common_init_node /tmp/tmp.bXYbsH93VJ/graphviz/lib/common/utils.c:658
#4 0x7fd24fc78a01 in dot_init_node /tmp/tmp.bXYbsH93VJ/graphviz/lib/dotgen/dotinit.c:40
#5 0x7fd24fc79522 in dot_init_node_edge /tmp/tmp.bXYbsH93VJ/graphviz/lib/dotgen/dotinit.c:81
#6 0x7fd24fc7ad61 in dotLayout /tmp/tmp.bXYbsH93VJ/graphviz/lib/dotgen/dotinit.c:295
#7 0x7fd24fc7c4b9 in doDot /tmp/tmp.bXYbsH93VJ/graphviz/lib/dotgen/dotinit.c:450
#8 0x7fd24fc7ca94 in dot_layout /tmp/tmp.bXYbsH93VJ/graphviz/lib/dotgen/dotinit.c:496
#9 0x7fd253f7673d in gvLayoutJobs /tmp/tmp.bXYbsH93VJ/graphviz/lib/gvc/gvlayout.c:85
#10 0x55a9961b3960 in main /tmp/tmp.bXYbsH93VJ/graphviz/cmd/dot/dot.c:132
#11 0x7fd253d2309a in __libc_start_main ../csu/libc-start.c:308
projects / graphviz / log