neatogen fdpAdjust: use cgraph wrapper for allocation
The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.
neatogen makeMatrix: use cgraph wrappers for allocation
The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.
neatogen getSizes: use cgraph wrappers for allocation
The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.
neatogen sortSites: use cgraph wrapper for allocation
The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.
neatogen makeInfo: use cgraph wrapper for allocation
The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.
circogen mkNodelist: use cgraph wrapper for allocation
The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.
circogen init_nodelistitem: use cgraph wrapper for allocation
The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.
circogen makeDerivedNode: use cgraph wrappers for allocation
The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.
circogen circular_init_node_edge: use cgraph wrappers for allocation
The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.
circogen mkItem: use cgraph wrapper for allocation
The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.
circogen position: use cgraph wrapper for allocation
The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.
circogen mkBlock: use cgraph wrapper for allocation
The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.
circogen find_pair_edges: use cgraph wrappers for allocation
The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.
circogen mkItem: use cgraph wrapper for allocation
The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.
The Autotools build system was doing quite a bit of work to try and find a
`date` syntax that worked on the current platform and still failing (this logic
does not work on NetBSD). We can side step all of this by just doing date
manipulation in Python which we were calling anyway.
It seems all contemporary supported platforms except Windows have `ssize_t`.
Furthermore, `int` is not a suitable fallback for a platform that does not have
`ssize_t`.
fdpgen objectList: use cgraph wrapper for allocation
The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.
fdpgen makeClustObs: use cgraph wrappers for allocation
The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.
The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.
fdpgen fdp_init_node_edge: use cgraph wrapper for allocation
The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.
fdpgen init_node: use cgraph wrapper for allocation
The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.
fdpgen findCComp: use cgraph wrappers for allocation
The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.
fdpgen adjustGrid: use cgraph wrapper for allocation
The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.
fdpgen newBlock: use cgraph wrappers for allocation
The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.
The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.
fdpgen expandCluster: use cgraph wrapper for allocation
The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.
fdpgen getEdgeList: use cgraph wrapper for allocation
The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.
fdpgen deriveGraph: use cgraph wrapper for allocation
The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.
The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.
fdpgen addCluster: use cgraph wrapper for allocation
The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.
fdpgen mkDeriveNode: use cgraph wrappers for allocation
The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.
As far as I can tell, this code has never been compilable. It relies on `CellW`
and `CellH`, neither of which have ever been defined in Graphviz’ history.
The majority of Graphviz code was using the types `intptr_t` and `uintptr_t`
unconditionally. So it seems safe to assume that any compliant C99 environment
has both of these.
The Intel C Compiler is now based on LLVM. We think this means it has a Clang
compatible front end, though we do not have access to it to check. If this is
accurate, it means the build system no longer needs any specialized ICC support.
neatogen makeMultiSpline: use cgraph wrapper for allocation
The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.
neatogen triPath: use cgraph wrapper for allocation
The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.
neatogen mkPoly: use cgraph wrapper for allocation
The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.
neatogen genroute: use cgraph wrapper for allocation
The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.
neatogen finishEdge: use cgraph wrapper for allocation
The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.
neatogen mkRouter: use cgraph wrapper for allocation
The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.
neatogen mkTriGraph: use cgraph wrapper for allocation
The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.
Note that in this change we can drop some explicit initialization because the
cgraph wrappers zero-initialize.
neatogen: remove upfront allocation of trigraph edges
Following on from fc465488e1e62fe5ef879b379a07ef272431f400, this removes
assumptions about how many total edges will be generated by this algorithm. New
edges are now allocated on demand when appending.
neatogen mkTriIndices: use cgraph wrapper for allocation
The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.
neatogen mkCtrlPts: use cgraph wrapper for allocation
The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.
neatogen addTri: use cgraph wrapper for allocation
The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.
neatogen newIpair: use cgraph wrapper for allocation
The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.
neatogen newItem: use cgraph wrapper for allocation
The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.
CMake: fix: teach 'gvpack' how to find plugins at run time
Because `gvpack` links against the plugins as libraries rather than loading them
on demand, the dynamic linker needs to be able to locate the plugin libraries at
run time.
CC: Jaroslav Škarvada <jskarvad@redhat.com>
Gitlab: fixes #1838
Red Hat: fixes https://bugzilla.redhat.com/show_bug.cgi?id=1838679
core plugin: stop emitting an empty 'alt' tag in cmap output
This was working around a behavior on an old version of Microsoft Internet
Explorer that is no longer supported. Tooltips should show consistently on
modern browsers and the `alt` tag is once again available to be set dynamically
by Javascript or inherited.
CI: add Qt generated sources to files excluded from coverage analysis
These will be generated by an upcoming commit adding GVEdit to the CMake build
system. The cryptic EWIEGA46WW directory in this path is a checksum generated by
`AUTOMOC`. But it is based on relative path and appears to be stable as long as
we do not rename any cmd/gvedit subdirectories.
Qt 5.15 deprecated the version of this function that returns a pointer and
throws compiler warnings when calls to it are seen. This modernization is
necessary to avoid the upcoming integration of Gvedit into the CMake build
system failing in CI where `-Werror` is applied.
Unfortunately we need to do this conditionally while retaining the old code for,
e.g., CentOS 7 which has a version of Qt 5.15 that does not have the new API.
gvedit: locate attrs.txt based on the location of our own executable
This commit adapts 24bd92c1e5d49b354141cd06d88ca658991b9825 that taught Smyrna
how to find the share directory without a build time define to Gvedit. The
pattern is essentially the same, but we can take advantage of some nicer C++
mechanisms instead of C.
The motivation for this is to make integration of Gvedit into the CMake build
system easier. By doing location of the share directory in the code instead of
the build system, we can more easily ensure the same behavior between build
systems. A side effect of this is the `gvedit` binary becoming more relocatable.
Note that the Windows discovery mechanism differs from what it was before, but
it is now more in line with how discovery works on other platforms.
neatogen: fix miscalculation of intermediate edge resources
`genroute` was allocating an array for edge computation upfront. But what it was
not accounting for was that some of the functions it later calls _change_ the
`pn` value it used to determine how many array elements it should allocate.
Specifically, `Pshortestpath` can add new points to the polygon, thereby causing
the walk of the (now too short) array to write out of bounds.
neatogen: fix out of bounds write when exceeding estimated edges
The `edgei` allocation in `mkTriGraph` was wrong. This code was written prior to
Git history, and it is not obvious how the calculation for how many edges to
allocate was arrived at. My educated guess is that the `+ 2` was intended to
account for the maximum number of final appended edges (the maximum trip count
of the trailing loop in this function), except that is 3 not 2. Bumping this to
3 indeed bypasses the ASan failure in #42.
Rather than just make that equally error prone adjustment, this commit stops
estimating the edge count upfront at all and instead allocates edges per-node
on-demand.
The prior code was allocating edges for all nodes as a contiguous array. Each
node would then be given an offset pointer into this array. Apart from the
problem described above, this meant all nodes apart from the last one could
overflow their edge count, silently corrupting their neighbor’s edges, in a way
undetectable by ASan. This refactoring gives each node distinct memory for its
edges. But this means we needed to introduce a node count (`nnodes`) to the
trigraph and free each of these separate allocations when destructing the
trigraph.
This also required passing in original edge counts to `resetGraph`. Previously
the code would detect an edge that needed to be removed by a node’s edges
running up against its neighbor’s. Obviously this was subject to the above
described bugs which could cause false negatives in this test, leading to even
further compounding data corruption.
Fixing this unfortunately only yields yet another ASan crash (below). This will
be addressed in an upcoming commit.
WRITE of size 16 at 0x613000001860 thread T0
#0 0x7f5b44579e80 in genroute lib/neatogen/multispline.c:869
#1 0x7f5b4457f53d in makeMultiSpline lib/neatogen/multispline.c:1311
#2 0x7f5b4452ac4d in _spline_edges lib/neatogen/neatosplines.c:632
#3 0x7f5b4452b4c8 in splineEdges lib/neatogen/neatosplines.c:729
#4 0x7f5b4452b5a6 in spline_edges1 lib/neatogen/neatosplines.c:742
#5 0x7f5b4452b658 in spline_edges0 lib/neatogen/neatosplines.c:771
#6 0x7f5b4451154d in init_nop lib/neatogen/neatoinit.c:597
#7 0x7f5b44516ac9 in neato_layout lib/neatogen/neatoinit.c:1407
#8 0x7f5b488a847f (/tmp/tmp.jiRlFO5wtW/lib+0x8647f)
#9 0x55ddbc8126dc in main graphviz/cmd/dot/dot.c:89
#10 0x7f5b485e2d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
#11 0x7f5b485e2e3f in __libc_start_main_impl ../csu/libc-start.c:392
#12 0x55ddbc812344 in _start (bin/dot+0x1344)
It should be clear from the above that the code here has a very error prone
structure. (1) Estimating how much memory is required upfront with non-trivial
calculations and (2) allocating a block of memory that is then partitioned out
to clients trusted not to run into each other, effectively creates a scenario
where bugs are undetectable by memory safety tools and easily compound one
another. In future the other allocations in this file should be rewritten to
avoid this structure too.
projects / graphviz / log