make[3]: Entering directory '/home/costa/oss/graphviz/build/lib/gvpr'
CC actions.lo
In file included from ../../../lib/expr/expr.h:28,
from ../../../lib/gvpr/actions.h:18,
from ../../../lib/gvpr/actions.c:16:
../../../lib/expr/exparse.h:4:10: fatal error: expr/y.tab.h: No such file or directory
4 | #include <expr/y.tab.h>
| ^~~~~~~~~~~~~~
compilation terminated.
core plugin map_output_shape: replace dynamic buffer with inline conversion
This function was using a long lived buffer to hold conversions of the input
array `AF`. However each entry was only used once or twice. It is faster to
avoid the heap buffer altogether and simply do the conversions on-demand when
they are needed.
This change is expected to be a slight performance improvement as well as
further progress towards thread safety in this code.
core plugin: remove assumptions that pen width fits in an int
By dealing with this field consistently as a double, we retain the previous
intent while removing assumptions on the characteristics of `int`. Squashes 8
compiler warnings.
GNU Make supports both this syntax and `patsubst` for pattern substitution. The
former is more portable to other Make implementations, so use this in preference
to the latter.
This file has a fairly strange structure where almost every use of `cur_level`
is actually referencing a local that shadows the global `cur_level`. The global
`cur_level` is never written to and remains 0 throughout execution, making it
somewhat useless.
Criterion is a testing framework that has been used for writing Graphviz unit
tests in the past (see tests/unit_tests). These unit tests are not currently
enabled. However, Windows CI unconditionally checks out all submodules, thus
pulling in a version of Criterion that goes unused.
This change removes the previously described behavior. If/when the
Criterion-based unit tests are resurrected, an up to date version of Criterion
can be pulled in via a package manager or the Windows build dependencies
repository¹ instead.
This change should slightly accelerate Windows CI jobs.
GD plugin: use a dynamically allocated VRML rendering state instead of globals
This brings the affected code closer to being thread safe. The goal is to allow
(1) multiple threads to execute in this code safely as well as (2) multiple VRML
renderings on the same thread to be interleaved with each other.
GD plugin: remove unnecessary common/utils.h include
This was introduced in ff97490f4de09db950f708b1bf44a8f8f62902c5 in the same
commit that _removed_ all usage of `late_double` here, so it is unclear what the
intended meaning of the leading comment was.
1. Everything, with warning count piped to metrics.txt
2. Everything except the check for FIXMEs, hard failing if there is any
warning
The latter passes. That is, all Graphviz Python code is warning-free with the
exception of FIXMEs. Meanwhile FIXMEs are frequently _intentionally_ introduced
in test code, indicating a known open bug for which a test case is being added.
So metric collection in step 1 above is not relevant; we expect this number
often to go up. This commit removes the collection of this unused metric to
decrease CI complexity.
The return value of `execvp` is irrelevant because this function only ever
returns when it fails. In this situation, the failure cause is in the `errno`
global, not in the return value.
gvc: [nfc] remove parens around return value style
This is an idiom occasionally used to allow defining `return` as a macro that
does some additional instrumentation. This style has mostly fallen out of favor,
with mechanisms like `-finstrument-functions` instead used as a more robust way
of achieving the same thing.
The build system does not check for `g_type_term` so this code is always
disabled. More importantly though, I cannot locate any reference to a
`g_type_term` function that has ever existed anywhere except the Graphviz code
base. That is, it appears this has never been a librsvg or Glib function. The
commit message of its introduction in 9f4cb1fcb745b9b71c937980ef6b0d08552ead0f
also offers no enlightenment, only suggesting this was somehow related to Fedora
20.
DevIL plugin: squash -Wsign-conversion warning for 'ilSaveF' call
The DevIL plugin provides a number of output devices for which it claims IDs
matching the DevIL `ILenum` types. That is, it effectively stashes the DevIL
output format in the Graphviz device ID. This change simply makes it more
obvious to the compiler that the translation back and forth is intentional. For
more information, see the DevIL manual.¹
According to the DevIL API docs,¹ any error from `ilTexImage` is reported via
`ilGetError`, not through its return value. Squashes a -Wunused-but-set-variable
warning.
Pango plugin: fix: do not judge empty lines as failing during text layout
Text layout plugins are expected to return failure as `false` from their
`textlayout` function. The Pango plugin considered failure to be anything that
resulted in a horizontal layout width of 0. However, this is not a failure in
the case where the text being laid out is the empty string; its horizontal width
is expected to be 0.
The effect of this was that HTML-like strings like `<<br/>1>` were judged to
fail during text layout and a (redundant) estimation of their text width was
performed. This seems to have been a latent bug present since commit ad82ef8613b0731806b81f9c0047d0cbf6745470 (~July 2007). This recently became more
visible due to commit 7aa0dcc03ea20b544b2463d97fe4a78af699589c that introduced
warnings during text width estimation if a fallback metric needed to be used.
Users were now presented with “Warning: no hard-coded metrics” when using fonts
that Pango knew of and should not have needed estimation in the first place.
This fix makes the Pango plugin consider 0 width for the layout of an empty
string to be successful. To be clear, this commit is both a functional fix and a
performance improvement.
CMake: enable libgd support on macOS when possible
As discussed in the comment in this commit, we hard code the options the
Homebrew libgd package is built with.¹ It seems not possible to build a libgd
without GIF support, so perhaps the `HAVE_GD_GIF` logic in the Graphviz code
base could be simplified in future.
CMake: fix: link against pathplan when building GD plugin
This replicates something from the Autotools build system that was missing in
the CMake build system. The CMake build was not failing because the pathplan
dependency is only required when VRML support is enabled, which an upcoming
commit will add.
In contrast to the Autotools build system, this adds pathplan for all platforms,
not only Windows. Empirically it seems necessary on at least macOS and Windows
and it does no harm on Linux.
This is mostly just over-cautiousness to not accidentally define variables like
`HAVE_GD_PNG` if we not have libgd. But it will also ease some upcoming
macOS-specific changes.
CI: skip package uploading and deployment steps on non-release revisions
Traditionally CI has uploaded release artifacts and packaged a “release” for
every single commit on the main branch. These inter-release packages were
intended for testing and internal deployment. As far as we aware these are no
longer used; all Graphviz developers build from source and do not rely on
Gitlab’s generic package repository.¹
This change rearranges deployment steps to skip uploading artifacts and
packaging if the current commit is not a proper release. This should slightly
accelerate CI and reduce Graphviz storage requirements, which are currently at
>800GB on Gitlab.
fix gvpr corruption of dynamically allocated arguments to user-defined functions
Gvpr programs can define their own functions which can then be called within the
same program:
void foo(string s) {
print(s);
}
foo("bar");
This mostly worked. However in some cases the gvpr implementation was not
extending the lifetime of the memory allocated to store the passed in value
long enough. Enumerating the cases in which this occurred is complicated because
whether this (used-after-free) memory retained its intended content depended on
(1) the complexity of the expression of the passed in value and (2) what the
target function (`foo` in the above example) was itself doing. As a result, it
seems users mostly did not observe the problem (program/output corruption)
unless they were writing non-trivial functions and calling them with non-trivial
expressions.
Commit 8da53964edec8a665c3996d483df243eb150c2c4 compounded the above problem by
replacing the underlying allocator. While both before and after states use an
arena allocator,¹ the allocator after this change eagerly returns memory to the
backing system allocator (`malloc`) on `vmclear` while the allocator before this
change retained it within its own internal pool. The system allocator is used
much more pervasively in the Graphviz code base than the more tightly scoped
lib/vmalloc allocator, and it also typically does much more aggressive reuse of
recently-freed memory under the assumption that this is more likely to still be
cache-resident and thus faster to access. The net effect of this was that the
chance of the memory in question being reused and overwritten significantly
increased, making a number of latent cases of the problem described above now
user-visible.
The fix in this commit removes the freeing of expressions that are still
potentially in use. The contents of a subexpression in the above described
scenarios now remains intact up to the point it is accessed when evaluating its
parent containing expression.
The astute reader who has followed everything up to now may notice that the
subexpressions’ contents are actually maintained _beyond_ the point of
evaluation of the parent expression, and may be wondering, “didn’t you just turn
a use-after-free into a memory leak?” Unfortunately the answer is yes. However,
it is unclear how to determine when it is safe to free a subexpression without
introducing a more complex concept of call stacks and arbitrarily nested
expressions to lib/expr. Thus given the choice right now between use-after-free
or leaking memory, we are choosing to leak memory. Hopefully this can be
revisited in future.
projects / graphviz / log