SIGSEGV due to different options for amanda-server and amanda-client

[G. Paul Ziemba]

Summary
-------
For a given installation, make sure amanda-server and amanda-client ports
are built with the same port/build options, or memory access errors could
occur.

A Longer Summary
----------------
These two ports are built from the same source tree, and binaries from
both ports reference data in libamanda.so. However, only the instance
of libamanda.so from amanda-clients is actually installed. The build options
are captured in the version_info[] string pointer array in libamanda.so,
and the size of the array can vary if the build options are different.

I don't know the details of the dynamic linker, but it seems that the
arrangement of data in libamanda.so at build time of a dynamically-linked
application leaves state in the application binary that influences the
memory layout of the library data at run time.

A binary that references version_info[] (in libamanda.so) contains some
information (maybe segment boundaries?) that depends on the size of
version_info[] that the binary was built against.

Using a binary with a libamanda.so that has a larger version_info[]
than what the binary was built with can result in some sort of truncation
of the array, with ensuing gnashing of teeth.

What to do?
-----------
I think it's FreeBSD's issue (i.e., not upstream) because the potential
for mismatch arises from splitting into two ports. However, it might
be possible for upstream to fix it by hiding version_info[] in libamanda.so
and providing some access function(s).

I don't think there is a way to detect inconsistent flags/options
between ports.

Maybe the best FreeBSD can do is add a warning in pkg-message about the
potential for problems if options are different.

Or other ideas?

Details
-------

Versions:

% uname -m -r -s -v
FreeBSD 11.1-STABLE FreeBSD 11.1-STABLE #0 r321349: Fri Jul 21 16:31:37 PDT 2017     root at hairball:/usr/obj/usr/src/sys/GENERIC  amd64
% pkg info -x amanda
amanda-client-3.3.9,1
amanda-perl-wrapper-1.01
amanda-server-3.3.9,1

amdump failed with:

    driver: FATAL Did not get DATE line from planner

I ran planner by itself with:

    % cd ~/tmp/amanda/amanda-3.3.9/server-src
    % sudo gdb /usr/local/libexec/amanda/planner
    (gdb) run Weekly --starttime 2017090812130000 -otapedev= -otpchanger=

and found a bad string address (0x100) deep in printf and friends 
from the g_fprintf here (planner.c):

267         for (i = 0; version_info[i] != NULL; i++)
268             g_fprintf(stderr, _("%s: %s"), get_pname(), version_info[i]);

Program received signal SIGSEGV, Segmentation fault.
strlen (str=0x100 <error: Cannot access memory at address 0x100>)
    at /usr/src/lib/libc/string/strlen.c:100
100             va = (*lp - mask01);
(gdb) where
#0  strlen (str=0x100 <error: Cannot access memory at address 0x100>)
    at /usr/src/lib/libc/string/strlen.c:100
#1  0x0000000802c1721a in __vfprintf (fp=<optimized out>, 
    locale=0x802ec1578 <__xlocale_global_locale>, fmt0=<optimized out>, 
    ap=<optimized out>) at /usr/src/lib/libc/stdio/vfprintf.c:845
#2  0x0000000802c15344 in vfprintf_l (fp=0x802ec2ab0, 
    locale=0x802ec1578 <__xlocale_global_locale>, fmt0=0x411fae "%s: %s", 
    ap=0x7fffffffd370) at /usr/src/lib/libc/stdio/vfprintf.c:283
#3  0x0000000802467030 in g_vfprintf (file=0x802ec2ab0, 
    format=0x411fae "%s: %s", args=0x7fffffffd370) at gprintf.c:213
#4  0x0000000802466fb9 in g_fprintf (file=0x802ec2ab0, 
    format=0x411fae "%s: %s") at gprintf.c:82
#5  0x00000000004041fe in main (argc=4, argv=0x7fffffffea10) at planner.c:268

Further investigation with code modifications per:

        for (i = 0; version_info[i] != NULL; i++) {
            char *vinfo;
            vinfo = version_info[i];
            g_fprintf(stderr, _("%s: %s"), get_pname(), vinfo);
        }

showed that with i=25, after the assignment to vinfo but before the call
to g_printf, version_info[i] was a valid string pointer but vinfo contained
0x100.

Here is some output of "nm -n /usr/local/libexec/amanda/planner" (the binary):

    0000000000614730 A __bss_start
    0000000000614730 B __stdoutp@@FBSD_1.0
    0000000000614730 A _edata
    0000000000614740 B version_info
    0000000000614808 B __mb_sb_limit@@FBSD_1.0
    0000000000614810 B _DefaultRuneLocale@@FBSD_1.0

Note that 0x614808 - 0x614740 = 200 decimal.

Here is some output of
"objdump -a -t -s /usr/local/lib/amanda/libamanda-3.3.9.so" (the library):

    0000000000295020 g     O .data.rel.ro   00000000000000d8              version_info

     295020 b3990800 00000000 d2990800 00000000  ................
     295030 119a0800 00000000 469a0800 00000000  ........F.......
     295040 809a0800 00000000 af9a0800 00000000  ................
     295050 e09a0800 00000000 1c9b0800 00000000  ................
     295060 409b0800 00000000 7e9b0800 00000000  @.......~.......
     295070 ac9b0800 00000000 e79b0800 00000000  ................
     295080 2b9c0800 00000000 559c0800 00000000  +.......U.......
     295090 989c0800 00000000 dc9c0800 00000000  ................
     2950a0 199d0800 00000000 5e9d0800 00000000  ........^.......
     2950b0 819d0800 00000000 cb9d0800 00000000  ................
     2950c0 049e0800 00000000 4b9e0800 00000000  ........K.......
     2950d0 889e0800 00000000 bd9e0800 00000000  ................
     2950e0 fb9e0800 00000000 189f0800 00000000  ................
     2950f0 00000000 00000000                    ........        
    Contents of section .dynamic:
     2950f8 01000000 00000000 63310000 00000000  ........c1......
     295108 01000000 00000000 72310000 00000000  ........r1......
     295118 01000000 00000000 7c310000 00000000  ........|1......

Note that version_info size here is 0xd8 = 216 decimal.
-- 
G. Paul Ziemba
FreeBSD unix:
 9:31PM  up 1 day, 11:57, 9 users, load averages: 1.13, 1.21, 1.28