Bugzilla Bug 182999

I can run 0.6.18 or 0.6.19 perfectly fine with identical C[XX]FLAGS/use flags -
however w/ 0.6.20 the initscript fails to start, and running avahi-deamon
manually shows that it immediately segfaults.

Unfortunately, I haven't been able to produce a meaningful backtrace, remi has
reproduced the issue, so maybe he'll have more luck w/ debugging this.

[ebuild     U ] net-dns/avahi-0.6.20 [0.6.19] USE="autoipd bookmarks dbus -doc
gdbm gtk howl-compat mdnsresponder-compat -mono python qt3 -qt4 -test" 0 kB 

Portage 2.1.3_rc5 (default-linux/x86/2007.0/desktop, gcc-4.1.2, glibc-2.5-r3,
2.6.21-gentoo-r3 i686)
=================================================================
System uname: 2.6.21-gentoo-r3 i686 AMD Athlon(tm) XP 1600+
Gentoo Base System release 1.13.0_alpha12
Timestamp of tree: Sat, 23 Jun 2007 19:00:01 +0000
ccache version 2.4 [enabled]
dev-java/java-config: 1.3.7, 2.0.33-r1
dev-lang/python:     2.5.1-r2
dev-python/pycrypto: 2.0.1-r5
dev-util/ccache:     2.4-r7
sys-apps/sandbox:    1.2.18.1
sys-devel/autoconf:  2.13, 2.61
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10
sys-devel/binutils:  2.17, 2.17.50.0.15, 2.17.50.0.16
sys-devel/gcc-config: 1.3.16
sys-devel/libtool:   1.5.23b
virtual/os-headers:  2.6.21
ACCEPT_KEYWORDS="x86 ~x86"
AUTOCLEAN="yes"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-march=athlon-xp -O2 -pipe -fomit-frame-pointer -fforce-addr"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config
/usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config"
CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/revdep-rebuild
/etc/splash /etc/terminfo /usr/share/X11/xkb"
CXXFLAGS="-march=athlon-xp -O2 -pipe -fomit-frame-pointer -fforce-addr"
DISTDIR="/usr/portage/distfiles"
EMERGE_DEFAULT_OPTS="--alphabetical --with-bdeps=y"
FEATURES="ccache collision-protect distlocks metadata-transfer parallel-fetch
sandbox sfperms splitdebug strict unmerge-orphans userfetch userpriv
usersandbox"
GENTOO_MIRRORS="ftp://ftp.fi.muni.cz/pub/linux/gentoo/
http://gentoo.osuosl.org"
LANG="en_US.UTF-8"
LDFLAGS="-Wl,-O1 -Wl,--sort-common"
LINGUAS="cs en"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_RSYNC_EXTRA_OPTS="--progress --prune-empty-dirs"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress
--force --whole-file --delete --delete-after --stats --timeout=180
--exclude=/distfiles --exclude=/local --exclude=/packages
--filter=H_**/files/digest-*"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage /usr/local/overlays/beryl
/usr/local/overlays/enlightenment"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="3dnow 3dnowext 7zip X X509 a52 aac aalib acl acpi alsa amr ao asf
audiofile avahi bash-completion berkdb bluetooth branding bzip2 cairo caps cddb
cdparanoia cdr chroot cli cpudetection cracklib crypt cscope css cups curl
curlwrappers daap dbus dbx dga directfb dri dts dv dvb dvd dvdr dvdread encode
exif expat fam fame fbcon ffmpeg fftw firefox flac flash flatfile foomaticdb
ftp fuse gd gdbm ggi gif gimp glibc-omitfp glitz glut gmp gphoto2 gpm graphviz
gs gstreamer gtk hal ical iconv icq idn imagemagick imap imlib inifile ipv6
irda jack javascript jbig joystick jpeg jpeg2k kdeenablefinal
kdehiddenvisibility kipi lame lcms libcaca libg++ libnotify libsamplerate lirc
live lm_sensors logrotate lzo mad maildir matroska midi mikmod mime mjpeg mmap
mmx mmxext mng modplug moznopango mp3 mp4 mpeg mplayer mudflap multiuser
musepack musicbrainz ncurses network network-cron nfs nls no-old-linux nodrm
nptl nptlonly nsplugin nvidia offensive ogg openal opengl openmp pam pcre pdf
perl png portaudio ppds python qt3 qt3support quicktime rar readline real
reflection rle ruby samba sdl sdl-image session skey sms sndfile speex spell
spl sqlite sqlite3 sse ssl startup-notification subtitles svg symlink syslog
tcpd theora threads threadsafe thumbnail tiff truetype unicode urandom usb v4l
v4l2 vcd vim-syntax vim-with-x vorbis wavpack win32codecs wmf x264 x86 xattr
xcomposite xine xinerama xinetd xml xmlrpc xorg xosd xpm xv xvid xvmc zeroconf
zip zlib" ALSA_CARDS="emu10k1 bt87x" ALSA_PCM_PLUGINS="adpcm alaw asym copy
dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear
meter mulaw multi null plug rate route share shm softvol" ELIBC="glibc"
INPUT_DEVICES="joystick keyboard mouse vmmouse" KERNEL="linux"
LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses
text" LINGUAS="cs en" LIRC_DEVICES="cph06x" USERLAND="GNU" VIDEO_CARDS="fbdev
nv nvidia v4l vesa vmware"
Unset:  CTARGET, INSTALL_MASK, LC_ALL, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS

Here's the backtrace I got :

(gdb) bt
#0  0xb7db736a in malloc_consolidate (av=0xb7e7b120) at malloc.c:4712
#1  0xb7db91da in _int_malloc (av=0xb7e7b120, bytes=1052) at malloc.c:4081
#2  0xb7dbac8e in *__GI___libc_malloc (bytes=1052) at malloc.c:3468
#3  0xb7dda515 in __alloc_dir (fd=6, close_fd=true, statp=<value optimized
out>)
    at ../sysdeps/unix/opendir.c:159
#4  0xb7dda5f4 in __opendir (name=0xb7ed97a8 "/proc/self/fd") at
../sysdeps/unix/opendir.c:135
#5  0xb7ed7822 in daemon_close_allv (except_fds=0x8065410) at dfork.c:394
#6  0xb7ed7a20 in daemon_close_all (except_fd=-1) at dfork.c:379
#7  0x0804e310 in main (argc=1, argv=Cannot access memory at address 0x5
) at main.c:1252
#8  0xb7d68e58 in __libc_start_main (main=0x804da80 <main>, argc=1,
ubp_av=0xbffa0da4, 
    init=0x805cef0 <__libc_csu_init>, fini=0x805cee0 <__libc_csu_fini>,
rtld_fini=0xb7f44010 <_dl_fini>, 
    stack_end=0xbffa0d9c) at libc-start.c:238
#9  0x0804ca51 in _start ()


Looking at the libdaemon news : "add new function daemon_close_all() to close
all open file descriptors except a given set;" My little finger tells me this
might be a bug in libdaemon, or a misuse of this library.

My 0.02€

I'm still unable to reproduce this issue on amd64 and x86.

This might be glibc and/or kernel-dependent.

avahi-0.6.20 fails on my laptop (default-linux/x86/2007.0/desktop, gcc-4.1.2,
glibc-2.5-r3, 2.6.21-gentoo-r3 i686, kernel has suspend2 patches manually
applied).
However, it works fine on my desktop (default-linux/amd64/2007.0/desktop,
gcc-4.1.2, glibc-2.5-r3, 2.6.21-gentoo-r3 x86_64)

(In reply to comment #3)
> This might be glibc and/or kernel-dependent.

Actually, after some experimentation, it seems this is not glibc or kernel
dependent. On my x86 laptop the bug persists with glibc 2.4 and with kernels
2.6.19 and 2.6.20.

I ripped out daemon_close_allv() from libdaemon and built it on it's own and
seems to work fine (doesn't segfault in opendir)

Maybe libdaemon or avahi is doing something funny before hand, but strace did
point out anything obvious.

FYI, I can reproduce on 2 very different ~x86 boxes but they are mostly
identical software wise.

Created an attachment (id=123338) [details]
avahi-0.6.20-daemon_close_all.patch

The basic problem is that daemon_close_all() from libdaemon-0.11 is broken. It
has fencepost errors and doesn't use the stdarg macros correctly. In fact, as
far as I can tell, there is no way to use glibc stdarg macros to do what
daemon_close_all() is trying to do. The fact that avahi-0.6.20 doesn't crash on
some machines is a lucky accident. IMHO, any use of daemon_close_all() in any
package in the portage tree should be considered a bug.

The solution is to replace the daemon_close_all() call with the slightly less
convenient daemon_close_allv().

Created an attachment (id=123341) [details]
avahi-0.6.20.ebuild that uses above patch

Created an attachment (id=123346) [details]
libdaemon-0.11-daemon_close_all.patch

Actually, daemon_close_all() in libdaemon-0.11 turns out to be easy to fix.

Created an attachment (id=123347) [details]
libdaemon-0.11.ebuild that uses above patch

Tried your patch and it works again :) Thanks Alex

libdaemon is herd-less : Sven, I can commit this later today if that's ok with
you.

WFM as well.

Rémi, if you want to commit it, do it.

Fixed in CVS :)

Has anyone poked upstream about this bug? I didn't find any mailing list, maybe
avahi directly? (same upstream)

(In reply to comment #13)
I emailed Lennart Poettering with the patch yesterday. Haven't received a reply
so far.

Unfortunately, libdaemon has neither a mailing list nor a bugtracking system,
so directly emailing the author seems the only way to go.

OK, I'm closing this now.