I have recently noticed that gnupg does no longer work on my machine segfaulting when performing various operations. Using gdb I could trace back the segfault to a call for ctermid, which is a POSIX.1 function to determine a terminal's name (for Linux, it is always "/dev/tty"). This function may be called with a preallocated char pointer or a NULL pointer as parameter. I wrote a small test programm (http://www.unix-ag.uni-kl.de/~fischer/ctermidtest.c) that calls this function. Supplying a valid string buffer, ctermid returns "/dev/tty". Passing a NULL pointer causes ctermid to segfault (in my test program, this is the second ctermid call). I assume my C program is valid, as the same program works perfectly on another Gentoo box with similar setup. Any suggestions how to tackle this problem? Portage 2.0.54-r2 (default-linux/x86/2005.0, gcc-4.1.0, glibc-2.3.6-r3, 2.6.16-suspend2-r4 i686) ================================================================= System uname: 2.6.16-suspend2-r4 i686 Intel(R) Pentium(R) M processor 1.50GHz Gentoo Base System version 1.6.14 ccache version 2.3 [enabled] dev-lang/python: 2.3.5-r2, 2.4.2 dev-python/pycrypto: [Not Present] dev-util/ccache: 2.3 dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.16.1 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=pentium-m -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/eselect/compiler /etc/gconf /etc/terminfo /etc/texmf/web2c /etc/env.d" CXXFLAGS="-O2 -march=pentium-m -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig ccache distlocks sandbox sfperms strict" GENTOO_MIRRORS="ftp://ftp.uni-kl.de/pub/linux/gentoo ftp://ftp.unixag-zw.fh-kl.de/pub/mirrors/gentoo ftp://ftp.gentoo.mesh-solutions.com/gentoo " LANG="german" LC_ALL="de_DE.utf8" LINGUAS="en de sv" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage /usr/local/portageruben" SYNC="rsync://ftp.uni-kl.de/ftp/linux/gentoo-portage" USE="x86 7zip X a52 aac aalib acpi alsa audiofile avi bash-completion berkdb bitmap-fonts bzip2 cdparanoia cdr cli crypt cups curl dri dv dvd dvdread emboss encode ethereal exif expat faad fam fame ffmpeg flac foomaticdb footmaticdb gd gdbm gif glut gmp gnutls gphoto2 gpm graphviz gstreamer gtk2 hal icq idn imagemagick imap imlib isdnlog jabber jbig jpeg jpeg2k junit kde latex lcms libcaca libg++ libwww live lzo mad matroska mbox md5sum mikmod mjpeg mmx mng mp3 mpeg mplayer ncurses network nls nntp ogg oggvorbis opengl oss pam pcre pdflib perl pic plotutils png ppds pppd python qt quicktime readline recode reflection rtc samba sasl sdl session slang speex spell spl sqlite sse sse2 ssl subtitles subversion svg svga tcpd tetex tga theora threads tiff truetype truetype-fonts type1-fonts udev unicode usb userlocales v4l v4l2 vorbis wifi win32codec win32codecs wmf xinerama xml xml2 xorg xscreensaver xv xvid zlib video_cards_ati linguas_en linguas_de linguas_sv userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, INSTALL_MASK, LDFLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTAGE_RSYNC_OPTS
Created attachment 86680 [details] ctermidtest.c always post example files as attachments
your example app works for me on the few machines i tested it ... and the code looks correct going by the manpage you could try emerging glibc with FEATURES=split-debug ... but you'll need to emerge portage-2.1_pre* for that feature ... that should give you a useful gdb backtrace though
> you could try emerging glibc with FEATURES=split-debug ... > but you'll need to emerge portage-2.1_pre* for that feature ... Still using stable portage. Instead, I've patched glibc's sysdeps/posix/ctermid.c like this: char * ctermid (s) char *s; { char *result; printf("ctermid A\n"); static char name[L_ctermid]; printf("ctermid B\n"); printf("L_ctermid= %i\n", L_ctermid); printf("s=%s\n", s); printf("s=%x\n", s); if (s == NULL) { printf("ctermid C\n"); s = name; printf("ctermid D\n"); } else printf("ctermid D2\n"); printf("ctermid E\n"); result = strcpy (s, "/dev/tty"); printf("ctermid F\n"); return result; } This is my output: A ctermid A ctermid B L_ctermid= 9 s= s=bfacb505 ctermid D2 ctermid E ctermid F buffer1=/dev/tty M ctermid A ctermid B L_ctermid= 9 s=(null) s=0 ctermid D2 ctermid E Segmentation Fault So, according the two printfs before the if block, s is NULL. But the if block executes the else part printing "D2". But as s is NULL, strcpy fails. Might be some compiler bug. Strange... Backtrace from gdb: (gdb) run Starting program: /tmp/ctermidtest A ctermid A ctermid B L_ctermid= 9 s= s=bfb4a7a5 ctermid D2 ctermid E ctermid F buffer1=/dev/tty M ctermid A ctermid B L_ctermid= 9 s=(null) s=0 ctermid D2 ctermid E Program received signal SIGSEGV, Segmentation fault. 0xb7e3c08f in ctermid () from /lib/libc.so.6 (gdb) bt #0 0xb7e3c08f in ctermid () from /lib/libc.so.6 #1 0x08048467 in main () at ctermidtest.c:12
looks that way to me as well ... try running this: objdump -C -w -d /lib/libc.so.6 you're going to get a ton of output ... search for "<ctermid>" and then post the disassembly of that section ... should be like ~20 to ~30 lines of assembly
00039000 <ctermid>: 39000: 55 push %ebp 39001: 89 e5 mov %esp,%ebp 39003: 56 push %esi 39004: 53 push %ebx 39005: e8 e6 c2 fd ff call 152f0 <sigprocmask@plt+0x78> 3900a: 81 c3 ea 9f 0d 00 add $0xd9fea,%ebx 39010: 83 ec 08 sub $0x8,%esp 39013: 8b 75 08 mov 0x8(%ebp),%esi 39016: 8d 83 8f 34 ff ff lea 0xffff348f(%ebx),%eax 3901c: 89 04 24 mov %eax,(%esp) 3901f: e8 34 c1 fd ff call 15158 <puts@plt> 39024: 8d 83 99 34 ff ff lea 0xffff3499(%ebx),%eax 3902a: 89 04 24 mov %eax,(%esp) 3902d: e8 26 c1 fd ff call 15158 <puts@plt> 39032: b8 09 00 00 00 mov $0x9,%eax 39037: 89 44 24 04 mov %eax,0x4(%esp) 3903b: 8d 83 a3 34 ff ff lea 0xffff34a3(%ebx),%eax 39041: 89 04 24 mov %eax,(%esp) 39044: e8 bf c0 fd ff call 15108 <printf@plt> 39049: 8d 83 b2 34 ff ff lea 0xffff34b2(%ebx),%eax 3904f: 89 74 24 04 mov %esi,0x4(%esp) 39053: 89 04 24 mov %eax,(%esp) 39056: e8 ad c0 fd ff call 15108 <printf@plt> 3905b: 8d 83 b8 34 ff ff lea 0xffff34b8(%ebx),%eax 39061: 89 74 24 04 mov %esi,0x4(%esp) 39065: 89 04 24 mov %eax,(%esp) 39068: e8 9b c0 fd ff call 15108 <printf@plt> 3906d: 8d 83 be 34 ff ff lea 0xffff34be(%ebx),%eax 39073: 89 04 24 mov %eax,(%esp) 39076: e8 dd c0 fd ff call 15158 <puts@plt> 3907b: 8d 83 c9 34 ff ff lea 0xffff34c9(%ebx),%eax 39081: 89 04 24 mov %eax,(%esp) 39084: e8 cf c0 fd ff call 15158 <puts@plt> 39089: 8d 83 d3 34 ff ff lea 0xffff34d3(%ebx),%eax 3908f: c7 06 2f 64 65 76 movl $0x7665642f,(%esi) 39095: c7 46 04 2f 74 74 79 movl $0x7974742f,0x4(%esi) 3909c: c6 46 08 00 movb $0x0,0x8(%esi) 390a0: 89 04 24 mov %eax,(%esp) 390a3: e8 b0 c0 fd ff call 15158 <puts@plt> 390a8: 83 c4 08 add $0x8,%esp 390ab: 89 f0 mov %esi,%eax 390ad: 5b pop %ebx 390ae: 5e pop %esi 390af: 5d pop %ebp 390b0: c3 ret 390b1: 90 nop 390b2: 90 nop 390b3: 90 nop 390b4: 90 nop 390b5: 90 nop 390b6: 90 nop 390b7: 90 nop 390b8: 90 nop 390b9: 90 nop 390ba: 90 nop 390bb: 90 nop 390bc: 90 nop 390bd: 90 nop 390be: 90 nop 390bf: 90 nop
I could not determine the actual reason for this bug, but recompiling glibc with use flags nptl and nptlonly fixed the problem.
*** Bug 141141 has been marked as a duplicate of this bug. ***
looks like this is a bug in glibc-2.3.6 ... it has been fixed in glibc-2.4
added fix from upstream to our cvs patchset
*** Bug 147115 has been marked as a duplicate of this bug. ***
*** Bug 137196 has been marked as a duplicate of this bug. ***
