autofs start fails: segfault at 0 ip 00007f738cb881bb sp 00007ffeff888f70 error 4 in lookup_file.so[7f738cb76000+2b000]

[Stefan Bader]

Wily server 64bit installation, after dist-upgrade, restart of autofs.service fails and dmesg shows those errors:

[ 1030.673473] automount[3276]: segfault at 0 ip 00007f738cb881bb sp 00007ffeff888f70 error 4 in lookup_file.so[7f738cb76000+2b000]

ProblemType: Bug
DistroRelease: Ubuntu 15.10
Package: autofs 5.1.1-1ubuntu1
ProcVersionSignature: Ubuntu 3.19.0-22.22-generic 3.19.8-ckt1
Uname: Linux 3.19.0-22-generic x86_64
ApportVersion: 2.17.3-0ubuntu4
Architecture: amd64
Date: Tue Jul 7 07:11:13 2015
SourcePackage: autofs
UpgradeStatus: No upgrade log present (probably fresh install)

[Stefan Bader (smb)]

Segfault persists after reboot into latest kernel: Ubuntu 4.0.0-4.6-generic 4.0.7.

[Stefan Bader (smb)]

/etc/autofs.conf:
master_map_name = /etc/auto.master

/etc/auto.master:
+dir:/etc/auto.master.d
+auto.master

/etc/auto.master.d/import.autofs:
/import file:/etc/auto.import

/etc/auto.import:
isos -ro,soft,intr,nfsvers=3 nano:/srv/images/iso
cloud-images -ro,soft,intr,nfsvers=3 nano:/srv/images/cloudimg
tests -rw,soft,intr,nfsvers=3 nano:/home/tests

The /import directory exists.

[Stefan Bader (smb)]

#0 0x00007fab78969e10 in conf_lookup_key ()
   from /usr/lib/x86_64-linux-gnu/autofs/lookup_file.so
#1 0x00007fab78969ece in conf_lookup ()
   from /usr/lib/x86_64-linux-gnu/autofs/lookup_file.so
#2 0x00007fab7896b246 in conf_get_yesno ()
   from /usr/lib/x86_64-linux-gnu/autofs/lookup_file.so
#3 0x00007fab7896bc95 in defaults_get_browse_mode ()
   from /usr/lib/x86_64-linux-gnu/autofs/lookup_file.so
#4 0x00007fab78963660 in local_init_vars ()
   from /usr/lib/x86_64-linux-gnu/autofs/lookup_file.so
#5 0x00007fab78963a43 in master_parse_entry ()
   from /usr/lib/x86_64-linux-gnu/autofs/lookup_file.so
#6 0x00007fab7895b7b5 in lookup_read_master ()
   from /usr/lib/x86_64-linux-gnu/autofs/lookup_file.so
#7 0x00007fab7bfb6371 in do_read_master ()
#8 0x00007fab7bfb6861 in lookup_nss_read_master ()
#9 0x00007fab780afa63 in include_file ()
   from /usr/lib/x86_64-linux-gnu/autofs/lookup_dir.so
#10 0x00007fab780afc92 in lookup_read_master ()
   from /usr/lib/x86_64-linux-gnu/autofs/lookup_dir.so
#11 0x00007fab7bfb6371 in do_read_master ()
#12 0x00007fab7bfb6b99 in lookup_nss_read_master ()
#13 0x00007fab7895b61e in lookup_read_master ()
   from /usr/lib/x86_64-linux-gnu/autofs/lookup_file.so
#14 0x00007fab7bfb6371 in do_read_master ()
#15 0x00007fab7bfb6861 in lookup_nss_read_master ()
#16 0x00007fab7bfcf797 in master_read_master ()
#17 0x00007fab7bfaa579 in main ()

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Stefan Bader (smb)]

Seems that defaults_read_config(), defaults_get_searchdns() or at least conf_init() needs to be called before trying conf_get_yesno() in defaults_get_browse_mode(). Otherwise the config pointer is still NULL when accessing the hash table indirectly.

[Stefan Bader (smb)]

Its not only that call site. I get the feeling that the daemon does not inherit the dynamically allocated structures across fork(). At least it does do a defaults_read_config() before the fork which does not seem to survive.

[Launchpad Janitor (janitor)]

This bug was fixed in the package autofs - 5.1.1-1ubuntu2

---------------
autofs (5.1.1-1ubuntu2) wily; urgency=low

  * Add LDFLAGS to avoid issues with accessing global variables in
    shared libraries (LP: #1470687, LP: #1472115).

 -- Stefan Bader <email address hidden> Tue, 07 Jul 2015 16:28:53 +0200

[Robie Basak (racb)]

Did this patch get sent upstream? We're still having to maintain the Ubuntu delta here.

[Stefan Bader (smb)]

Robie, you really believe I will be able to answer what I did 2 years ago? Most likely answer is no.

[Stefan Bader (smb)]

Refreshing memory, this was to filter out --symbolic-functions from LDFLAGS, and that might be a compiler bug which may or may not have been fixed.

[Stefan Bader (smb)]

FWIW I looked at the current zesty version where it seems possible to drop the filter but still need the explicit set of LDFLAGS, so

override_dh_auto_build:
        CFLAGS="$(CFLAGS) $(CPPFLAGS)" \
        LDFLAGS="$(dpkg-buildflags --get LDFLAGS)" \
        dh_auto_build

appears to be working. Could that be a difference in the way Ubuntu automatically exports flags (or not)?