Summary: | graphics/graphviz: (x11/pixman) Segmentation Fault (FreeBSD12/aarch64) | ||
---|---|---|---|
Product: | Ports & Packages | Reporter: | Stefan Rink <stefanrink> |
Component: | Individual Port(s) | Assignee: | Michal Meloun <mmel> |
Status: | Closed FIXED | ||
Severity: | Affects Some People | CC: | emaste, mikael, mmel, val, w.schwarzenfeld |
Priority: | --- | ||
Version: | Latest | ||
Hardware: | arm64 | ||
OS: | Any | ||
Bug Depends on: | 233204 | ||
Bug Blocks: |
Description
Stefan Rink
2018-10-10 13:28:19 UTC
The command cat test.dot | dot -Tpng also not works on amd64. It does not segfault, but it "hangs" anywhere. The command dot -Tpng test.dot -o test.png works. Uups cat test.dot | dot -Tpng works, but with -o cat test.dot | dot -Tpng -o test.png. # dot -Tpng test.dot -o test.png Segmentation fault (core dumped) As a workaround I made a dot shell file what does ssh to my machine; ssh test@FreeBSDi7 -C clusterdot $* On the i7 I have clusterdot shell file with; dot $* What works fine but isn't the best solution I guess. :-) It's only on the ARM64 it fails, I could try with ARM also but that will take a while to setup.. --- # dot -v -Tpng test.dot -o test.png dot - graphviz version 2.40.1 (20161225.0304) Using render: cairo:cairo Using device: png:cairo:cairo libdir = "/usr/local/lib/graphviz" Activated plugin library: libgvplugin_dot_layout.so.6 Using layout: dot:dot_layout The plugin configuration file: /usr/local/lib/graphviz/config6 was successfully loaded. render : cairo dot dot_json fig gd json json0 map mp pic pov ps svg tk vml vrml xdot xdot_json layout : circo dot fdp neato nop nop1 nop2 osage patchwork sfdp twopi textlayout : textlayout device : canon cmap cmapx cmapx_np dot dot_json eps fig gd gd2 gif gv imap imap_np ismap jpe jpeg jpg json json0 mp pdf pic plain plain-ext png pov ps ps2 svg svgz tk vml vmlz vrml wbmp x11 xdot xdot1.2 xdot1.4 xdot_json xlib loadimage : (lib) eps gd gd2 gif jpe jpeg jpg png ps svg xbm fontname: "Helvetica" resolved to: (ps:pango DejaVu Sans, ) (PangoCairoFcFont) "DejaVu Sans, Book" /usr/local/share/fonts/dejavu/DejaVuSans.ttf pack info: mode undefined size 0 flags 0 margin 8 pack info: mode node size 0 flags 0 network simplex: 20 nodes 19 edges maxiter=2147483647 balance=2 network simplex: 20 nodes 19 edges 0 iter 0.00 sec network simplex: 4 nodes 4 edges maxiter=2147483647 balance=2 network simplex: 4 nodes 4 edges 0 iter 0.00 sec network simplex: 5 nodes 4 edges maxiter=2147483647 balance=2 network simplex: 5 nodes 4 edges 0 iter 0.00 sec network simplex: 4 nodes 5 edges maxiter=2147483647 balance=2 network simplex: 4 nodes 5 edges 0 iter 0.00 sec network simplex: 2 nodes 1 edges maxiter=2147483647 balance=1 network simplex: 2 nodes 1 edges 0 iter 0.00 sec Maxrank = 1, minrank = 0 mincross: pass 0 iter 0 trying 0 cur_cross 0 best_cross 0 mincross oneDegreeRelationshipsDiagram: 0 crossings, 0.00 secs. network simplex: 3 nodes 2 edges maxiter=2147483647 balance=2 network simplex: 3 nodes 2 edges 0 iter 0.00 sec routesplines: 1 edges, 3 boxes 0.00 sec Using render: cairo:cairo Using device: png:cairo:cairo dot: allocating a 1337K cairo image surface (657 x 521 pixels) Segmentation fault (core dumped) First tests are on our Sopine cluster and I don't have a 32bit world for it yet. I do run a bit of customized kernel but nothing in that part of the kernel has changed but to be sure I got another brand of ARM64 CPU... So just tested this on the RPI-III with the corresponding aarch64 image and same problem. Also just tested on the latest ARM (32bit) image for RPI-II and that worked so it's aarch64 specific. Reproduce; Boot the aarch64 image on RPI3 or Pine64+/Sopine pkg install graphviz echo 'digraph "test" { "test":"testx" } ' | dot -Tpng -otest.png I think this should move to AARCH64 it seems arch specific. Cf bug #233204 for a wip patch (In reply to mikael.urankar from comment #5) You sir earned a cookie or a beer or something! That indeed fixed the issue, I will test further but the first tests seemed to work so I'll roll it out on our cluster and test some more in a bigger setting and cross my fingers that all nodes will stay stable. :-) I also have a feeling that will fix some other threading issues as well.. (i.e. Python < 3.7 issues) Fixed with: https://github.com/strejda/freebsd/commit/981459604061136fc68c020ff6124fab0d1196aa (In reply to Stefan Rink from comment #6) Please don't mark FIXED until the fix actually lands in upstream FreeBSD Final (and much more complex) version of this patch is under review now: https://reviews.freebsd.org/D18417 Michal All 42 nodes are still up and running with https://github.com/strejda/freebsd/commit/981459604061136fc68c020ff6124fab0d1196aa! Total crashcounter: 0 Will test https://reviews.freebsd.org/D18417 when I have some spare time. A commit references this bug: Author: mmel Date: Sat Dec 15 10:38:10 UTC 2018 New revision: 342113 URL: https://svnweb.freebsd.org/changeset/base/342113 Log: Improve R_AARCH64_TLSDESC relocation. The original code did not support dynamically loaded libraries and used suboptimal access to TLS variables. New implementation removes lazy resolving of TLS relocation - due to flaw in TLSDESC design is impossible to switch resolver function at runtime without expensive locking. Due to this, 3 specialized resolvers are implemented: - load time resolver for TLS relocation from libraries loaded with main executable (thus with known TLS offset). - resolver for undefined thread weak symbols. - slower lazy resolver for dynamically loaded libraries with fast path for already resolved symbols. PR: 228892, 232149, 233204, 232311 MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D18417 Changes: head/libexec/rtld-elf/aarch64/reloc.c head/libexec/rtld-elf/aarch64/rtld_start.S head/libexec/rtld-elf/amd64/reloc.c head/libexec/rtld-elf/arm/reloc.c head/libexec/rtld-elf/i386/reloc.c head/libexec/rtld-elf/mips/reloc.c head/libexec/rtld-elf/powerpc/reloc.c head/libexec/rtld-elf/powerpc64/reloc.c head/libexec/rtld-elf/riscv/reloc.c head/libexec/rtld-elf/rtld.c head/libexec/rtld-elf/rtld.h head/libexec/rtld-elf/sparc64/reloc.c Forgotten to close? (In reply to Walter Schwarzenfeld from comment #11) yes, can you close it please? |