Port-macppc archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: installing graphviz from pkgsrc on NetBSD/macppc 9.1
> # dot -c
> Error: /usr/pkg/lib/graphviz/config6 is zero sized, or other read
> error.
> Warning: Could not load "/usr/pkg/lib/graphviz/libgvplugin_gd.so.6" -
> It was found, so perhaps one of its dependents was not. Try ldd.
> [1] Segmentation fault (core dumped) dot -c
FWIW, I'm seeing the same issue.
> It seems to be some missing hidden dependency, but after manually
> reviewing and re-installing all stated dependencies I was still
> getting this error.
>
> I did not install strace to root this out further.
Strace is a Linuxy thing. "ktrace" and "kdump" are included in
the base system and does basically the same job.
However, it doesn't look like this is an issue which can be
traced using a system call tracer, as all that gets you is
21802 1 dot CALL __sigprocmask14(3,0xffffe1b0,0)
21802 1 dot RET __sigprocmask14 0
21802 1 dot CALL __stat50(0xfd908000,0xffffe340)
21802 1 dot NAMI "/usr/pkg/lib/graphviz/libgvplugin_gd.so.6"
21802 1 dot RET __stat50 0
21802 1 dot CALL write(2,0xffffdd68,9)
21802 1 dot GIO fd 2 wrote 9 bytes
"Warning: "
21802 1 dot RET write 9
21802 1 dot CALL write(2,0xffffddf8,0x7f)
21802 1 dot GIO fd 2 wrote 127 bytes
"Could not load \"/usr/pkg/lib/graphviz/libgvplugin_gd.so.6\" - It was \
found, so perhaps one of its dependents was not. Try ldd.\n"
21802 1 dot RET write 127/0x7f
...
21802 1 dot CALL __sigprocmask14(3,0xffffe1b0,0)
21802 1 dot RET __sigprocmask14 0
21802 1 dot PSIG SIGSEGV SIG_DFL: code=SEGV_MAPERR, addr=0x0, trap=768)
21802 1 dot NAMI "dot.core"
so not really useful.
I suspect it has more to do with the dynamic linker and any
issues it might uncover, and debugging that requires building
ld.elf_so with -DDEBUG and setting LD_DEBUG in the environment.
Doing that reveals that this ends in
doing non-PLT relocations
doing lazy PLT binding
fixing up PLTGOT
obj /usr/pkg/lib/graphviz/libgvplugin_neato_layout.so.6 secure-plt gotptr=0xfd6b1d9c start=0xfdee2568 obj=0xfd7fc000
doing non-PLT relocations
doing lazy PLT binding
fixing up PLTGOT
obj /usr/pkg/lib/libgts-0.7.so.5 secure-plt gotptr=0xfd27a3a4 start=0xfdee2568 obj=0xfd7fb800
doing non-PLT relocations
doing lazy PLT binding
fixing up PLTGOT
obj /usr/pkg/lib/libgthread-2.0.so.0 secure-plt gotptr=0xfd830a5c start=0xfdee2568 obj=0xfd7fb400
doing non-PLT relocations
doing lazy PLT binding
fixing up PLTGOT
obj /usr/lib/libstdc++.so.9 secure-plt gotptr=0xfd1f9354 start=0xfdee2568 obj=0xfd7fb000
_rtld_call_init_functions()
_rtld_initlist_tsort
calling init function /usr/pkg/lib/libpcre.so.1 at 0xfc5a1394
Segmentation fault (core dumped)
and running this under the debugger gives a stack trace which is
consistent with the above:
Program received signal SIGSEGV, Segmentation fault.
0xfc5cae5c in ?? () from /usr/pkg/lib/libpcre.so.1
(gdb) where
#0 0xfc5cae5c in ?? () from /usr/pkg/lib/libpcre.so.1
#1 0xfc5a13a4 in _init () from /usr/pkg/lib/libpcre.so.1
#2 0xfdee5060 in _rtld_call_init_function.part.8 ()
from /usr/libexec/ld.elf_so
#3 0xfdee549c in _rtld_call_init_functions () from /usr/libexec/ld.elf_so
#4 0xfdee68a8 in dlopen () from /usr/libexec/ld.elf_so
#5 0xfddf735c in vm_open () from /usr/pkg/lib/libltdl.so.7
#6 0xfddf2d7c in tryall_dlopen () from /usr/pkg/lib/libltdl.so.7
#7 0xfddf4ebc in try_dlopen () from /usr/pkg/lib/libltdl.so.7
#8 0xfddf5628 in lt_dlopenadvise () from /usr/pkg/lib/libltdl.so.7
#9 0xfddf57f8 in lt_dlopen () from /usr/pkg/lib/libltdl.so.7
#10 0xfde36a00 in gvplugin_library_load () from /usr/pkg/lib/libgvc.so.6
#11 0xfde39168 in gvconfig () from /usr/pkg/lib/libgvc.so.6
#12 0xfde56190 in dotneato_args_initialize () from /usr/pkg/lib/libgvc.so.6
#13 0xfde4cab0 in gvParseArgs () from /usr/pkg/lib/libgvc.so.6
#14 0x01800df4 in ?? ()
#15 0x01800ba4 in ?? ()
#16 0x0180097c in ?? ()
(gdb)
(gdb) i reg
r0 0xfc5a13a4 4233761700
r1 0xffffe070 4294959216
r2 0xfddf1008 4259254280
r3 0x0 0
r4 0x0 0
r5 0x0 0
r6 0xfefefeff 4278124287
r7 0x1 1
r8 0x0 0
r9 0x0 0
r10 0x0 0
r11 0x8 8
...
pc 0xfc5cae5c 0xfc5cae5c
...
(gdb) x/i 0xfc5cae5c
=> 0xfc5cae5c: lbz r9,0(r4)
(gdb)
So, for some reason the init function hits a null pointer
de-reference in libpcre. Need to look closer at that.
Hmm, "make test" in /usr/pkgsrc/devel/pcre
fails one of the tests, RunTest.log ends up with
PCRE C library tests using test data from ./testdata
PCRE version 8.45 2021-06-15
---- Testing 8-bit library ----
Test 1: Main functionality (Compatible with Perl >= 5.10)
OK
OK with study
Test 2: API, errors, internals, and non-Perl stuff (not UTF-8)
[1] Segmentation fault (core dumped) ${sim} ${valgrind} ${opt:+${vjs} ./pcretest -q...
** Test 2 requires a lot of stack. If it has crashed with a
** segmentation fault, it may be that you do not have enough
** stack available by default. Please see the 'pcrestack' man
** page for a discussion of PCRE's stack usage.
FAIL RunTest (exit status: 1)
This leaves a pcretest.core, but inspecting it with the debugger
doesn't look useful:
(gdb) where
#0 0xfde74274 in ?? ()
#1 0xfde82748 in ?? ()
#2 0xfde75080 in ?? ()
#3 0xfde753a4 in ?? ()
#4 0xfde757bc in ?? ()
...
#5652 0xfde753a4 in ?? ()
#5653 0xfde82748 in ?? ()
#5654 0xfde75080 in ?? ()
#5655 0xfde753a4 in ?? ()
#5656 0xfde757bc in ?? ()
#5657 0xfde86200 in ?? ()
#5658 0x01809454 in ?? ()
#5659 0x01801854 in ?? ()
#5660 0x0180162c in ?? ()
(gdb)
(gdb) i reg
r0 0xfde75080 4259795072
r1 0xffdff150 4292866384
r2 0xfde0d008 4259368968
r3 0xfdaeb7b6 4256085942
r4 0xfda4c03e 4255432766
r5 0xfdaeb058 4256084056
r6 0x2 2
r7 0xffffb444 4294947908
r8 0xffdff758 4292867928
r9 0x1618 5656
r10 0x3 3
r11 0xfdd4dfd0 4258586576
r12 0x44822444 1149379652
r13 0x182a2b0 25338544
r14 0x2 2
r15 0xffdff758 4292867928
r16 0x24222448 606217288
r17 0xfdaec000 4256088064
r18 0xffffb460 4294947936
r19 0xfdaeb058 4256084056
r20 0xfdaec000 4256088064
r21 0xfde8f73c 4259903292
r22 0xffffb444 4294947908
r23 0xfda4c069 4255432809
r24 0x79 121
r25 0xfdaeb7b6 4256085942
r26 0x7fffffff 2147483647
r27 0x0 0
r28 0xfda4c042 4255432770
r29 0xfda4c03e 4255432766
r30 0xfdebe268 4260094568
r31 0x79 121
pc 0xfde74274 0xfde74274
msr <unavailable>
cr 0x44822448 1149379656
lr 0xfde82748 0xfde82748
ctr 0xfde7617c 4259799420
xer 0x0 0
fpscr 0xfff80000 -524288
vscr <unavailable>
vrsave <unavailable>
(gdb) x/i 0xfde74274
=> 0xfde74274: Cannot access memory at address 0xfde74274
(gdb)
Well, the stack size limit on this host is 2M, bumping it to 8M
makes the test pass.
So ... let's return to graphviz with a larger stack:
Nope, that's not it:
granny-smith# dot -c
Error: /usr/pkg/lib/graphviz/config6 is zero sized, or other read error.
Warning: Could not load "/usr/pkg/lib/graphviz/libgvplugin_gd.so.6" - It was found, so perhaps one of its dependents was not. Try ldd.
Segmentation fault (core dumped)
granny-smith#
It turns out that pcre has configure code to explicitly remove
any user-supplied "-g" option, which makes debugging more
difficult. Getting a "-g" through to the copiler turns out to
not exactly be straight-forward (I've tried tweaking configure to
do so, so far unsuccessfully), so I'm stuck there at the moment.
Regards,
- Håvard
Home |
Main Index |
Thread Index |
Old Index