Here we replace the custom vmalloc allocator implementation with calls to
malloc, while preserving the overall pool abstraction. That is, it is still
possible to not free any of your vmalloc allocations but then rely on a final
call to vmclose() to clean them up. Note that this also removes the vmprivate
functionality which is no longer relevant.
This is the only instance of a call to vmnewof() that appears to rely on the
semantics of the returned memory having been zeroed. We are about to make some
changes that make it impossible for the allocator to zero extra memory in a
vmresize() because it does not know the size of the original allocation. This
change makes it safe for vmresize() to stop providing zeroed out extra memory.
gv_doc_template.tcl: Pass "-gmt True" to support reproducible dates.
While the code already uses SOURCE_DATE_EPOCH, it also needs to ensure
that the times are emitted in UTC/GMT, otherwise building on machines
configured with different timezones may result in different embedded
timestamps.
Signed-off-by: Bernhard M. Wiedemann <bwiedemann@suse.de>
Bison only includes the legacy malloc.h header when using alloca() on Windows,
when YYSTACK_USE_ALLOCA is defined. The Graphviz build does not define this for
any generated parsers. Related to #1242.
remove use of deprecated pango_cairo_font_map_create_context
This API was deprecated in version 1.22 of Pango [0], released in 2008 [1]. The
one place that supported both the new and old API was still always calling the
old API as the build system does no HAVE_PANGO_FONT_MAP_CREATE_CONTEXT
detection.
remove unnecessary intdeallocator for IntegerVector
The underlying vector implementation anticipates that the destructor may be
null, so there is no need to provide an empty deallocator. We could simply
delete the IntegerVector implementation as nothing is currently using it, but it
looks like it may be of use in dealing with #1554.
This function checked if its second allocation to the vector's backing array
failed, but did not check if the original data structure allocation failed. It
is somewhat unlikely callers are currently equipped to handle this failure
anyway, but we may as well be consistent here.
Magnus Jacobsson [Wed, 24 Jun 2020 11:07:14 +0000 (13:07 +0200)]
Change to use patch version in the Windows installer
This changes the version in the Graphviz installer .exe produced by
CMake to use the patch version number instead of the build
date. Still, if the patch version is "$GRAPHVIZ_VERSION_DATE", the
patch version will be set to the build date. This conforms with how
the Linux packages are created.
This change affects the filename of the installer, the version
presented to the user in the installer GUI, the installation path and
the version presented by the running software.
Magnus Jacobsson [Thu, 18 Jun 2020 11:08:04 +0000 (13:08 +0200)]
Make CMake get Graphviz version from autogen.sh by parsing it
This will make autotools and CMake builds have a single source of
truth for the Graphviz version.
First, the major, minor and patch versions are retrieved. If the patch
version is "$GRAPHVIZ_VERSION_DATE", the patch version is set to the
committer date of the latest commit. This effectively repeals part of
the intention of 266ff5ee80b2d91231907e90ec650154f5225aa5: "Don't
encode build date stamp in it to be able to create reproducable
builds".
Address Sanitizer detected a few instances of the following:
Direct leak of 168 byte(s) in 7 object(s) allocated from:
#0 0x7f4bc2724330 in __interceptor_malloc (/lib/x86_64-linux-gnu/libasan.so.5+0xe9330)
#1 0x7f4bc24b1ea3 in vec_new /tmp/tmp.m68Z0dFAYs/graphviz/lib/common/routespl.c:918
#2 0x7f4bc24b291a in find_all_cycles /tmp/tmp.m68Z0dFAYs/graphviz/lib/common/routespl.c:1073
#3 0x7f4bc24b2b64 in get_cycle_centroid /tmp/tmp.m68Z0dFAYs/graphviz/lib/common/routespl.c:1121
#4 0x7f4bc24b3c5c in makeStraightEdges /tmp/tmp.m68Z0dFAYs/graphviz/lib/common/routespl.c:1233
#5 0x7f4bc24b35f8 in makeStraightEdge /tmp/tmp.m68Z0dFAYs/graphviz/lib/common/routespl.c:1203
#6 0x7f4bbdf28b52 in _spline_edges /tmp/tmp.m68Z0dFAYs/graphviz/lib/neatogen/neatosplines.c:659
#7 0x7f4bbdf29240 in splineEdges /tmp/tmp.m68Z0dFAYs/graphviz/lib/neatogen/neatosplines.c:736
#8 0x7f4bbdf29310 in spline_edges1 /tmp/tmp.m68Z0dFAYs/graphviz/lib/neatogen/neatosplines.c:749
#9 0x7f4bbdf293be in spline_edges0 /tmp/tmp.m68Z0dFAYs/graphviz/lib/neatogen/neatosplines.c:779
#10 0x7f4bbdf29bcb in spline_edges /tmp/tmp.m68Z0dFAYs/graphviz/lib/neatogen/neatosplines.c:817
#11 0x7f4bbdf14ea6 in neato_layout /tmp/tmp.m68Z0dFAYs/graphviz/lib/neatogen/neatoinit.c:1489
#12 0x7f4bc242b6fc in gvLayoutJobs /tmp/tmp.m68Z0dFAYs/graphviz/lib/gvc/gvlayout.c:85
#13 0x559fcd474960 in main /tmp/tmp.m68Z0dFAYs/graphviz/cmd/dot/dot.c:132
#14 0x7f4bc21d709a in __libc_start_main ../csu/libc-start.c:308
find_all_cycles() was calling vec_delete() on the temporary vector it allocated,
but it did not take into account that the nested vectors were not freed by
vec_delete(). This change moves the open coded clean up logic from
get_cycle_centroid() into vec_delete() to fix this and make it less likely that
this is missed in future.
This was initially encountered while investigating #1554.
The function being called here, gmalloc, now exits on allocation failure. None
of setPrefix's callers can tolerate failure anyway, so this error handling seems
to have been incomplete previously.
projects / graphviz / log