Bug 91727 – emacs fails to compile with usersandox and USE=leim

• Status: VERIFIED TEST-REQUEST
• Product: Gentoo Linux

[Description TGL 2005-05-06 12:29:39 UTC]

app-editors/emacs-21.4-r1 fails to compile when using FEATURES=usersandox and USE=leim. It segfaults actually:

./emacs -q -batch -f list-load-path-shadows
make[1]: *** [emacs] Segmentation fault
make[1]: Leaving directory `/var/tmp/portage/emacs-21.4-r1/work/emacs-21.4/src'
(export PARALLEL; PARALLEL=0; cd leim; make all  \
  CC='i686-pc-linux-gnu-gcc' CFLAGS='-pipe' CPPFLAGS='-D_BSD_SOURCE  ' \
  LDFLAGS='' MAKE='make')
make[1]: Entering directory `/var/tmp/portage/emacs-21.4-r1/work/emacs-21.4/leim'
if [ -d quail ]; then true; else make quail; fi
if [ -f quail/CCDOSPY.elc ]; then true; else \
 EMACSLOADPATH=/var/tmp/portage/emacs-21.4-r1/work/emacs-21.4/leim/../lisp ../src/emacs -batch --no-init-file --no-site-file --multibyte -l /var/tmp/portage/emacs-21.4-r1/work/emacs-21.4/leim/../lisp/international/titdic-cnv \
  --eval '(batch-titdic-convert t)' -dir quail /var/tmp/portage/emacs-21.4-r1/work/emacs-21.4/leim/CXTERM-DIC; fi
/bin/sh: line 1: 22213 Segmentation fault      EMACSLOADPATH=/var/tmp/portage/emacs-21.4-r1/work/emacs-21.4/leim/../lisp ../src/emacs -batch --no-init-file --no-site-file --multibyte -l /var/tmp/portage/emacs-21.4-r1/work/emacs-21.4/leim/../lisp/international/titdic-cnv --eval '(batch-titdic-convert t)' -dir quail /var/tmp/portage/emacs-21.4-r1/work/emacs-21.4/leim/CXTERM-DIC
make[1]: *** [quail/CCDOSPY.elc] Error 139
make[1]: Leaving directory `/var/tmp/portage/emacs-21.4-r1/work/emacs-21.4/leim'
make: *** [leim] Error 2


I've tried different CFLAGS (stripping them down to only "-pipe") but it makes no difference.
It actually appears to be dependent on the sandbox settings in FEATURES:
 - "+sandbox -userpriv -usersandbox" works
 - "+sandbox +userpriv -usersandbox" works
 - "+sandbox +userpriv +usersandbox" fails
Also, with USE="-leim", it finish to build fine.

Note that this bug may be related to a few others, but i was not sure, hence the fresh report:
 - bug #233 is also about bad emacs/sandbox interaction, although it's pretty old
 - bug #61085 is also about a segfault during the build, but in xemacs. And for me, xemacs builds fine.
 - bug #64790 is also about emacs not building with leim, but the log is different (i see no segfault there)



Portage 1.585-cvs (default-linux/x86/2005.0, gcc-3.4.3-20050110, glibc-2.3.5-r0, 2.6.11-tgl3 i686)
=================================================================
System uname: 2.6.11-tgl3 i686 Intel(R) Pentium(R) M processor 1500MHz
Gentoo Base System version 1.6.11
Python:              dev-lang/python-2.3.5 [2.3.5 (#1, Feb 17 2005, 23:21:20)]
distcc: No such file or directory [disabled]
dev-lang/python:     2.3.5
sys-apps/sandbox:    1.2.5-r1
sys-devel/autoconf:  2.59-r6, 2.13
sys-devel/automake:  1.5, 1.7.9-r1, 1.9.5, 1.8.5-r3, 1.4_p6, 1.6.3
sys-devel/binutils:  2.15.92.0.2-r8
sys-devel/libtool:   1.5.16
virtual/os-headers:  2.6.11
ACCEPT_KEYWORDS="x86 ~x86"
AUTOCLEAN="no"
CFLAGS="-march=i686 -mtune=pentium-m -O2 -fomit-frame-pointer -pipe"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref /usr/share/config /usr/share/cursors/xfree/default /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/X11/Sessions /etc/dev.d /etc/env.d /etc/gconf /etc/hotplug /etc/hotplug.d /etc/init.d /etc/sound /etc/terminfo /etc/texmf/web2c /etc/env.d"
CXXFLAGS="-march=i686 -mtune=pentium-m -O2 -fomit-frame-pointer -pipe"
DISTDIR="/var/portage/distfiles"
FEATURES="autoaddcvs autoconfig ccache digest distlocks fixpackages manifest parallel-fetch sandbox sfperms userpriv usersandbox verify-rdepend"
GENTOO_MIRRORS="http://distro.ibiblio.org/pub/linux/distributions/gentoo ftp://ftp.ussg.iu.edu/linux/gentoo"
LANG="fr_FR@euro"
LC_ALL="fr_FR@euro"
LINGUAS="fr fr_FR en en_US"
MAKEOPTS="-j1"
PKGDIR="/var/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/var/portage/tree"
PORTDIR_OVERLAY="/var/portage/overlays/bugzilla /var/portage/overlays/tgl /var/portage/overlays/demexp /var/portage/overlays/portage-cvs /var/portage/overlays/x11r6"
SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage"
USE="x86 X Xaw3d a52 aac aalib acpi adns alsa apache2 apm audiofile avi bash-completion berkdb bitmap-fonts bzip2 cdparanoia cdr cross crypt cscope cups curl dba dga dpms dvd dvdr emboss encode esd faad fbcon ffmpeg flac flagB flash foomaticdb fortran freetype gd gdbm ggz gif gnome gnomedb gphoto2 gpm gstreamer gtk gtk2 gtkhtml guile hal howl imagemagick imap imlib imlib2 ipv6 java jikes jpeg junit lcms leim libcaca libg++ libwww lirc lzo mad mailwrapper matroska mbox memlimit mikmod mmx mng mozilla mp3 mpeg ncurses network nls nptl offensive ogg oggvorbis openal opengl oss pam pdflib perl plotutils png pnp postgres python qt quicktime readline ruby ruby18 scanner sdl slang slp smooth snmp speex spell sqlite sse sse2 ssl svg svga tcltk tcpd tetex theora threads tiff tmpfs truetype truetype-fonts type1-fonts unicode usb v4l v4l2 vorbis win32codecs wmf wxwindows xface xfs xine xinerama xml xml2 xosd xpm xprint xv xvid zeo zlib video_cards_radeon input_devices_synaptics linguas_fr linguas_fr_FR linguas_en linguas_en_US userland_GNU kernel_linux elibc_glibc"
Unset:  ASFLAGS, CBUILD, CTARGET, LDFLAGS

[Comment 1 Mamoru KOMACHI (RETIRED) 2005-05-21 13:25:39 UTC]

Sorry but the bug is not reproduceable to me ;(
Does anyone else confirm this bug?

[Comment 2 TGL 2005-05-21 14:59:51 UTC]

If it can be of any help, i've tried again (and got exactly the same behavior)
and here is what gdb says of the dumped core file:

(gdb) bt
#0  0xb7bf6495 in free () from /lib/tls/libc.so.6
#1  0xffffffd8 in ?? ()
#2  0xffffffd8 in ?? ()
#3  0xbfffcd58 in ?? ()
#4  0xffffffd8 in ?? ()
#5  0xb7bf63b6 in free () from /lib/tls/libc.so.6
#6  0x00000001 in ?? ()
#7  0x0000002f in ?? ()
#8  0x0843d100 in ?? ()
#9  0x6b727574 in ?? ()
#10 0x00687369 in ?? ()
#11 0x20202020 in ?? ()
#12 0x08489748 in ?? ()
#13 0x00001000 in ?? ()
#14 0x53492e52 in ?? ()
#15 0xb7bf53bf in malloc_usable_size () from /lib/tls/libc.so.6
#16 0xb7cc2820 in __malloc_initialize_hook () from /lib/tls/libc.so.6
#17 0x00000038 in ?? ()
#18 0xb7cc2820 in __malloc_initialize_hook () from /lib/tls/libc.so.6
#19 0xbfffcdd0 in ?? ()
#20 0xb7bf53bf in malloc_usable_size () from /lib/tls/libc.so.6
#21 0xb7cb3b0f in in6addr_any () from /lib/tls/libc.so.6
#22 0xb7cb3b0f in in6addr_any () from /lib/tls/libc.so.6
#23 0xb7cc2858 in __malloc_initialize_hook () from /lib/tls/libc.so.6
#24 0x74207470 in ?? ()
#25 0x72000a6f in ?? ()
#26 0xb7cb3b0f in in6addr_any () from /lib/tls/libc.so.6
#27 0xb7cb3b0f in in6addr_any () from /lib/tls/libc.so.6
#28 0xb7bf59cb in malloc_trim () from /lib/tls/libc.so.6
#29 0xb7ffac6c in __libc_memalign () from /lib/ld-linux.so.2
#30 0xb7bf63b6 in free () from /lib/tls/libc.so.6
#31 0xb7cc2858 in __malloc_initialize_hook () from /lib/tls/libc.so.6
#32 0x00000008 in ?? ()
#33 0x00000040 in ?? ()
#34 0xb7cc2848 in __malloc_initialize_hook () from /lib/tls/libc.so.6
#35 0xb7cc2820 in __malloc_initialize_hook () from /lib/tls/libc.so.6
#36 0xb7cc2858 in __malloc_initialize_hook () from /lib/tls/libc.so.6
#37 0x00000004 in ?? ()
#38 0xb7cc0ff4 in ?? () from /lib/tls/libc.so.6
#39 0xb7cc2820 in __malloc_initialize_hook () from /lib/tls/libc.so.6
#40 0xfffffff0 in ?? ()
#41 0x00000038 in ?? ()
#42 0xb7bf861c in malloc () from /lib/tls/libc.so.6
#43 0xb7cc2820 in __malloc_initialize_hook () from /lib/tls/libc.so.6
#44 0x00000038 in ?? ()
#45 0xb7cc0ff4 in ?? () from /lib/tls/libc.so.6
#46 0x00000038 in ?? ()
#47 0x00000040 in ?? ()
#48 0xbfffce14 in ?? ()
#49 0x08129a1a in emacs_blocked_malloc (size=1886221359) at alloc.c:737
Previous frame inner to this frame (corrupt stack?)

I'm really not used at C debugging and don't really know how to get more info,
symbols, etc., but if you have a few instructions you would like me to follow,
don't hesitate to ask.

[Comment 3 Matthew Kennedy (RETIRED) 2006-08-08 21:51:00 UTC]

Does this problem still persist?

While I cannot reproduce it either, the reporter might consider trying GCC CFLAGS options, eg. -march=i686 -O2 would be safe.  The error looks similar to the -O3 failures with recent GCCs.

[Comment 4 TGL 2006-08-08 23:31:26 UTC]

(In reply to comment #3)
> Does this problem still persist?

I've just tried again (emacs-21.4-r3, sandbox-1.2.18.1, gcc-4.1.1, with "usersandbox" in FEATURES and "leim" in USE), and now it works fine.  I will let you change resolution (seems i don't have rights to do it myself).

> While I cannot reproduce it either, the reporter might consider trying GCC
> CFLAGS options, eg. -march=i686 -O2 would be safe.

I had tried that at the time of my initial report. The failure log was with CFLAGS="-pipe" btw, and i had also tried various middle ground flags like "-march=686 -02 -pipe".  So we'll probably never now what was happening...

[Comment 5 Matthew Kennedy (RETIRED) 2006-08-09 18:48:57 UTC]

Thanks for replying back.