Bug#1015740: libc6: Include patch to make grantpt usable after multi-threaded fork in more cases
Package: libc6
Version: 2.31-13+deb11u3
Severity: normal
Tags: patch
X-Debbugs-Cc: iwien...@redhat.com
Dear Maintainer,
The glibc bug
https://sourceware.org/bugzilla/show_bug.cgi?id=24941
fixed by
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=27fe5f2e67a0e4cc0526b1b32b55f8e519075edb
provides fixes for the grantpt() call deadlocking after fork(). This
seems rather esoteric, but has caused difficult to debug issues for
Ansible users, e.g.
https://github.com/ansible/ansible/issues/59642
In opendev.org CI (zuul.opendev.org) several users hit this in various
ways as our execution environment is based on Debian Bullseye. We
have pulled a more recent glibc into our images with
https://review.opendev.org/c/zuul/zuul/+/849795
But hopefully we can find a solution that is helpful to everyone.
I have pulled the patch and applied it with minor fuzz updates against
2.31-13+deb11u3. Could we consider having this applied?
Thanks,
-i
-- System Information:
Debian Release: 11.4
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.18.10-200.fc36.x86_64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: unable to detect
Versions of packages libc6 depends on:
ii libcrypt1 1:4.4.18-4
ii libgcc-s1 10.2.1-6
Versions of packages libc6 recommends:
ii libidn2-0 2.3.0-5
pn libnss-nis
pn libnss-nisplus
Versions of packages libc6 suggests:
ii debconf [debconf-2.0] 1.5.77
pn glibc-doc
pn libc-l10n
pn locales
-- debconf information excluded
commit 27fe5f2e67a0e4cc0526b1b32b55f8e519075edb
Author: Florian Weimer
Date: Wed Oct 7 14:55:04 2020 +0200
Linux: Require properly configured /dev/pts for PTYs
Current systems do not have BSD terminals, so the fallback code in
posix_openpt/getpt does not do anything. Also remove the file system
check for /dev/pts. Current systems always have a devpts file system
mounted there if /dev/ptmx exists.
grantpt is now essentially a no-op. It only verifies that the
argument is a ptmx-descriptor. Therefore, this change indirectly
addresses bug 24941.
Reviewed-by: Adhemerval Zanella
(Cherry-picked by Ian Wienand )
Index: glibc-2.31/INSTALL
===
--- glibc-2.31.orig/INSTALL
+++ glibc-2.31/INSTALL
@@ -184,14 +184,9 @@ if 'CFLAGS' is specified it must enable
'--enable-pt_chown'
The file 'pt_chown' is a helper binary for 'grantpt' (*note
Pseudo-Terminals: Allocation.) that is installed setuid root to fix
- up pseudo-terminal ownership. It is not built by default because
- systems using the Linux kernel are commonly built with the 'devpts'
- filesystem enabled and mounted at '/dev/pts', which manages
- pseudo-terminal ownership automatically. By using
- '--enable-pt_chown', you may build 'pt_chown' and install it setuid
- and owned by 'root'. The use of 'pt_chown' introduces additional
- security risks to the system and you should enable it only if you
- understand and accept those risks.
+ up pseudo-terminal ownership on GNU/Hurd. It is not required on
+ GNU/Linux, and the GNU C Library will not use the installed
+ 'pt_chown' program when configured with '--enable-pt_chown'.
'--disable-werror'
By default, the GNU C Library is built with '-Werror'. If you wish
Index: glibc-2.31/NEWS
===
--- glibc-2.31.orig/NEWS
+++ glibc-2.31/NEWS
@@ -399,6 +399,18 @@ Changes to build and runtime requirement
Older GCC versions and non-GNU compilers are still supported when
compiling programs that use the GNU C Library.
+* On Linux, the system administrator needs to configure /dev/pts with
+ the intended access modes for pseudo-terminals. glibc no longer
+ attemps to adjust permissions of terminal devices. The previous glibc
+ defaults ("tty" group, user read/write and group write) already
+ corresponded to what most systems used, so that grantpt did not
+ perform any adjustments.
+
+* On Linux, the posix_openpt and getpt functions no longer attempt to
+ use legacy (BSD) pseudo-terminals and assume that if /dev/ptmx exists
+ (and pseudo-terminals are supported), a devpts file system is mounted
+ on /dev/pts. Current systems already meet these requirements.
+
Security related changes:
CVE-2019-7309: x86-64 memcmp used signed Jcc instructions to check
Index: glibc-2.31/sysdeps/unix/sysv/linux/getpt.c
===
--- glibc-2.31.orig/sysdeps/unix/sysv/linux/getpt.c
+++ glibc-2.31/sysdeps/unix/sysv/linux/getpt.c
@@ -16,69 +16,18 @@
License along with the GNU C Library; if not, see
<https:
Bug#451939: libc6: Upgrading x86 chroot on ia64 dies with cannot set up thread-local storage
Package: libc6 Version: 2.3.6.ds1-13 Severity: normal Hi, I am trying to upgrade libc in a x86-32 chroot on my IA64 (Itanium) machine. It dies with the following Setting up libc6 (2.6.1-6) ... cannot set up thread-local storage: set_thread_area failed when setting up thread-local storage dpkg: error processing libc6 (--configure): subprocess post-installation script returned error exit status 127 Errors were encountered while processing: libc6 E: Sub-process /usr/bin/dpkg returned an error code (1) The underlying kernel is 2.6.22-3-mckinley. It was previously running 2.3.2.dl1-19. Any suggestions? Thanks, -i -- System Information: Debian Release: testing/unstable APT prefers stable APT policy: (900, 'stable'), (700, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18.2-paulaner-1 Locale: LANG=en_AU, LC_CTYPE=en_AU (charmap=ISO-8859-1) Versions of packages libc6 depends on: ii tzdata2007b-1Time Zone and Daylight Saving Time libc6 recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#451939: libc6: Upgrading x86 chroot on ia64 dies with cannot set up thread-local storage
On Mon, Nov 19, 2007 at 01:18:07PM +0100, Aurelien Jarno wrote: Where does this version come from? It doesn't seems to be a package from Debian. Sorry I mistyped it, it is 2.3.6.ds1-13 Any suggestions? Could you please send us the output of ls -l /lib as well as ldd /bin/ls from the insided of the chroot? Certainly ldd === librt.so.1 = /lib/librt.so.1 (0x4002c000) libacl.so.1 = /lib/libacl.so.1 (0x40038000) libc.so.6 = /lib/libc.so.6 (0x40044000) libpthread.so.0 = /lib/libpthread.so.0 (0x4018c000) /lib/ld-linux.so.2 (0x4000) libattr.so.1 = /lib/libattr.so.1 (0x401a4000) ls -l = total 4296 lrwxrwxrwx 1 root root 16 Dec 7 2004 cpp - /usr/bin/cpp-3.3 drwxr-xr-x 2 root root4096 Oct 18 16:38 i486-linux-gnu drwxr-xr-x 2 root root4096 Dec 7 2004 init drwxr-xr-x 2 root root4096 Dec 7 2004 iptables -rwxr-xr-x 1 root root 117340 Oct 18 16:52 ld-2.6.1.so lrwxrwxrwx 1 root root 11 Nov 19 11:46 ld-linux.so.2 - ld-2.6.1.so -rw-r--r-- 1 root root5444 Oct 18 16:52 libBrokenLocale-2.6.1.so lrwxrwxrwx 1 root root 24 Nov 19 11:46 libBrokenLocale.so.1 - libBrokenLocale-2.6.1.so -rw-r--r-- 1 root root 13696 Oct 18 16:52 libSegFault.so lrwxrwxrwx 1 root root 15 Dec 7 2004 libacl.so.1 - libacl.so.1.1.0 -rw-r--r-- 1 root root 22448 Sep 20 2004 libacl.so.1.1.0 -rw-r--r-- 1 root root9804 Oct 18 16:52 libanl-2.6.1.so lrwxrwxrwx 1 root root 15 Nov 19 11:46 libanl.so.1 - libanl-2.6.1.so lrwxrwxrwx 1 root root 16 Dec 7 2004 libattr.so.1 - libattr.so.1.1.0 -rw-r--r-- 1 root root 10824 Sep 21 2004 libattr.so.1.1.0 lrwxrwxrwx 1 root root 15 Dec 7 2004 libblkid.so.1 - libblkid.so.1.0 -rw-r--r-- 1 root root 23728 Sep 25 2004 libblkid.so.1.0 -rwxr-xr-x 1 root root 1335536 Oct 18 16:52 libc-2.6.1.so lrwxrwxrwx 1 root root 13 Nov 19 11:46 libc.so.6 - libc-2.6.1.so lrwxrwxrwx 1 root root 14 Dec 7 2004 libcap.so.1 - libcap.so.1.10 -rw-r--r-- 1 root root 11024 Apr 13 2004 libcap.so.1.10 lrwxrwxrwx 1 root root 17 Dec 7 2004 libcfont.so.0 - libcfont.so.0.0.0 -rw-r--r-- 1 root root 12272 Jul 31 2004 libcfont.so.0.0.0 -rw-r--r-- 1 root root 185824 Oct 18 16:52 libcidn-2.6.1.so lrwxrwxrwx 1 root root 16 Nov 19 11:46 libcidn.so.1 - libcidn-2.6.1.so lrwxrwxrwx 1 root root 17 Dec 7 2004 libcom_err.so.2 - libcom_err.so.2.1 -rw-r--r-- 1 root root5900 Sep 25 2004 libcom_err.so.2.1 lrwxrwxrwx 1 root root 19 Dec 7 2004 libconsole.so.0 - libconsole.so.0.0.0 -rw-r--r-- 1 root root 71836 Jul 31 2004 libconsole.so.0.0.0 -rw-r--r-- 1 root root 21912 Oct 18 16:52 libcrypt-2.6.1.so lrwxrwxrwx 1 root root 17 Nov 19 11:46 libcrypt.so.1 - libcrypt-2.6.1.so lrwxrwxrwx 1 root root 19 Dec 7 2004 libctutils.so.0 - libctutils.so.0.0.0 -rw-r--r-- 1 root root 18288 Jul 31 2004 libctutils.so.0.0.0 lrwxrwxrwx 1 root root 15 Dec 7 2004 libdb.so.2 - libdb1-2.2.5.so -rw-r--r-- 1 root root 49424 Oct 18 2002 libdb1-2.2.5.so lrwxrwxrwx 1 root root 15 Dec 7 2004 libdb1.so.2 - libdb1-2.2.5.so -rw-r--r-- 1 root root9684 Oct 18 16:52 libdl-2.6.1.so lrwxrwxrwx 1 root root 14 Nov 19 11:46 libdl.so.2 - libdl-2.6.1.so lrwxrwxrwx 1 root root 13 Dec 7 2004 libe2p.so.2 - libe2p.so.2.3 -rw-r--r-- 1 root root 16720 Sep 25 2004 libe2p.so.2.3 lrwxrwxrwx 1 root root 16 Dec 7 2004 libext2fs.so.2 - libext2fs.so.2.4 -rw-r--r-- 1 root root 89100 Sep 25 2004 libext2fs.so.2.4 -rw-r--r-- 1 root root 32356 Dec 5 2004 libgcc_s.so.1 lrwxrwxrwx 1 root root 17 Dec 7 2004 libhistory.so.4 - libhistory.so.4.3 -rw-r--r-- 1 root root 23916 Nov 13 2004 libhistory.so.4.3 -rw-r--r-- 1 root root 149332 Oct 18 16:52 libm-2.6.1.so lrwxrwxrwx 1 root root 13 Nov 19 11:46 libm.so.6 - libm-2.6.1.so -rw-r--r-- 1 root root 13696 Oct 18 16:52 libmemusage.so lrwxrwxrwx 1 root root 17 Dec 7 2004 libncurses.so.5 - libncurses.so.5.4 -rw-r--r-- 1 root root 252592 May 27 2004 libncurses.so.5.4 -rw-r--r-- 1 root root 83712 Oct 18 16:52 libnsl-2.6.1.so lrwxrwxrwx 1 root root 15 Nov 19 11:46 libnsl.so.1 - libnsl-2.6.1.so -rw-r--r-- 1 root root 30436 Oct 18 16:52 libnss_compat-2.6.1.so lrwxrwxrwx 1 root root 22 Nov 19 11:46 libnss_compat.so.2 - libnss_compat-2.6.1.so -rw-r--r-- 1 root root 17884 Oct 18 16:52 libnss_dns-2.6.1.so lrwxrwxrwx 1 root root 19 Nov 19 11:46 libnss_dns.so.2 - libnss_dns-2.6.1.so -rw-r--r-- 1 root root 38420 Oct 18 16:52 libnss_files-2.6.1.so lrwxrwxrwx 1 root root 21 Nov 19 11:46 libnss_files.so.2 - libnss_files-2.6.1.so -rw-r--r-- 1 root root 17900 Oct 18 16:52 libnss_hesiod-2.6.1.so lrwxrwxrwx 1 root root 22 Nov 19 11:46 libnss_hesiod.so.2 - libnss_hesiod-2.6.1.so -rw-r--r-- 1 root root 34352 Oct 18 16:52 libnss_nis-2.6.1.so lrwxrwxrwx 1 root root 19 Nov 19 11:46 libnss_nis.so.2 - libnss_nis-2.6.1.so
Bug#451939: libc6: Upgrading x86 chroot on ia64 dies with cannot set up thread-local storage
Thank you for your help on IRC As per http://www.gelato.unsw.edu.au/archives/linux-ia64/0711/21471.html I think this is a kernel bug. When it gets resolved I will close this bug. Thanks, -i -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#320240: ucontext.h bug also breaks libgc build
On Wed, Aug 03, 2005 at 09:58:32PM -0400, Nathanael Nerode wrote: If glibc in unstable doesn't require significant fixes to build with gcc-4.0, it really would be a good idea to backport the fix for this bug and the rpc/xdr.h one. I started to try this but gave up quite quickly; the problem seems to be more related to new versions of binutils than the newer gcc. I forward ported about 5 changes before I gave up. The ucontext change is quite trivial ... see attached. I just applied it straight to my sys/ucontext.h and I'm up and running :) If I built libc in a stable chroot (i.e. the older toolchain) with this patch would that help anyone? If it does require significant fixes, perhaps you could suggest to the release team that ia64 be dropped from consideration for packages migrating to testing. That's the only other way I can see to avoid tying most of the C++ transition to the glibc transition (which is clearly a bad idea). It seems that the modern toolchain has left the old glibc versions too far behind to bother with updating. Maybe having the glibc transistion go hand in hand with the C++ transision is just something we'll have to put up with. -i [EMAIL PROTECTED] http://www.gelato.unsw.edu.au #! /bin/sh -e # All lines beginning with `# DP:' are a description of the patch. # DP: Description: fix ucontext.h for IA64 with later gcc versions # DP: Related bugs: #284449 # DP: Dpatch author: Ian Wienand [EMAIL PROTECTED] # DP: Patch author: Andreas Schwab [EMAIL PROTECTED] # DP: Upstream status: In upstream if [ $# -ne 2 ]; then echo 2 `basename $0`: script expects -patch|-unpatch as argument exit 1 fi case $1 in -patch) patch -d $2 -f --no-backup-if-mismatch -p4 $0;; -unpatch) patch -d $2 -f --no-backup-if-mismatch -R -p4 $0;; *) echo 2 `basename $0`: script expects -patch|-unpatch as argument exit 1 esac exit 0 Index: ucontext.h === RCS file: /cvs/glibc/libc/sysdeps/unix/sysv/linux/ia64/sys/ucontext.h,v retrieving revision 1.7 retrieving revision 1.8 diff -u -r1.7 -r1.8 --- /cvs/glibc/libc/sysdeps/unix/sysv/linux/ia64/sys/ucontext.h 19 Jun 2002 07:22:14 - 1.7 +++ /cvs/glibc/libc/sysdeps/unix/sysv/linux/ia64/sys/ucontext.h 2 Sep 2004 03:40:06 - 1.8 @@ -1,4 +1,4 @@ -/* Copyright (C) 1998, 2000, 2001, 2002 Free Software Foundation, Inc. +/* Copyright (C) 1998, 2000, 2001, 2002, 2004 Free Software Foundation, Inc. This file is part of the GNU C Library. The GNU C Library is free software; you can redistribute it and/or @@ -32,7 +32,10 @@ typedef struct sigcontext mcontext_t; -#ifdef __GNUC__ +#if defined __cplusplus __GNUC_PREREQ (3, 5) +# define _SC_GR0_OFFSET\ + __builtin_offsetof (struct sigcontext, sc_gr[0]) +#elif defined __GNUC__ # define _SC_GR0_OFFSET\ (((char *) ((struct sigcontext *) 0)-sc_gr[0]) - (char *) 0) #else signature.asc Description: Digital signature
Re: How do *I* create a libc6-i686 package?
On Wed, Feb 16, 2005 at 03:18:42PM -0800, Kevin A. Burton wrote: How do I grab the sources to build my own packages? Could someone at LEAST give me a link for building my own packages? If you absolutely have to follow recent versions of libc, you're best learning about chroot environments and how to build libc from CVS sources. This isn't an easy task, and you aren't going to get much support. If you just want to try jamming 2.3.4 into the existing Debian build framework so you have .debs, it can at least minimally work, see http://www.gelato.unsw.edu.au/IA64wiki/HackedDebianLibc Note don't bother asking anyone (but me) for help with this as it's totally and utterly unsupported in every way (email me off list and I can provide a link for some 386 debs I have hacked together this way that work at least enough for me). -i [EMAIL PROTECTED] http://www.gelato.unsw.edu.au signature.asc Description: Digital signature
Re: Sarge, kernel, threads and limits
On Tue, Feb 08, 2005 at 09:39:17AM +0100, Ryszard Lach wrote:
* how to determine if my system/application is running linux or POSIX
threads
Your system can be running both libraries at the same time,
depending on flags to the dynamic loader, etc. The only sane way to
check is a runtime one
#include stdio.h
#include unistd.h
#include alloca.h
#include string.h
int isnptl (void)
{
size_t n = confstr (_CS_GNU_LIBPTHREAD_VERSION, NULL, 0);
if (n 0)
{
char *buf = alloca (n);
confstr (_CS_GNU_LIBPTHREAD_VERSION, buf, n);
if (strstr (buf, NPTL))
return 1;
}
return 0;
}
int main(void)
{
printf(NPTL: %s\n, isnptl() ? yes : no);
return 0;
}
* how to determine limits of threads per system, threads per process and
threads per user (hard compiled or set by PAM etc.)
I believe this is set by the ulimit of the number of processes. This
can be changed by ulimit -u or in something like /etc/security/limits.conf
* how is related amount of available stack to number of threads, which
process can create
Did you mean : how is the amount of available system memory for stacks
related to the number of threads? If you use the default stack size
that you get when you call pthread_create() you're going to run out of
memory pretty quickly. If you change down with
pthread_attr_setstacksize() you're going to be able to run many more
threads. However, you're still going to hit a kernel limit, see
kernel/fork.c:fork_init()
/*
* The default maximum number of threads is set to a safe
* value: the thread structures can take up at most half
* of memory.
*/
max_threads = mempages / (8 * THREAD_SIZE / PAGE_SIZE);
* I'd like also really understand what 'ps' displays. Don't say 'read
manual', because manual assumes that you really know what's going on
in kernel and tells you only how to display it.
ps should only display the main thread. You need to pass something
like '-m' to show the sub-threads.
-i
[EMAIL PROTECTED]
http://www.gelato.unsw.edu.au
signature.asc
Description: Digital signature
Re: libunwind in unstable
On Wed, Nov 24, 2004 at 12:46:12AM +0100, Matthias Klose wrote: ok, Ian, if it's ok with you, I'll prepare a libunwind upload, which plays well with a libgcc1 package including the libunwind7 shared libs. It's actually Matthieu's package so he needs to have the final say so; it's a rock and a hard place type problem but FWIW I think having the Mosberger libunwind.so as the default one is an enhancement (and something Debian should have got around to sooner). Of course after sarge is released (if any of us are still around ;) someone needs to remember to fix it properly so libgcc depends on libunwind to avoid version skew ... -i signature.asc Description: Digital signature
Re: wait4 causes segfault in i386 chroot
On Thu, Jun 10, 2004 at 12:08:26PM -0700, Arun Sharma wrote: On 6/9/2004 10:16 PM, Ian Wienand wrote: I've tracked it down to doing a wait/waitpid/wait4 (they all end up in wait4) in a sigchld signal handler. If I do a minimal test case where I catch the sigchld and wait, once the call returns it segfaults as in this trace (gdb can't seem to give a good backtrace). I recall seeing this problem earlier. But I'm unable to reproduce it now. I tried with 2.4.x and 2.6.6. Will try 2.6.7-rc3 later today. What was your glibc version ? Hi, I can replicate it with 2.6.6, so I guess we must have different libcs :( The libc is 2.3.2.ds1-13 from Debian unstable. With this in mind, I ran in the chroot with LD_LIBRARY_PATH=/usr/lib/debug and to my surprise things seemed to work. Run it again with LD_LIBRARY_PATH=/usr/lib/debug/lib/tls (or indeed just leave the default path) and it segfaults. A guess : the only major difference with the optimised libraries is they enable __thread which has the effect of putting errno in the TLS area (sysdeps/unix/sysv/linux/i386). TLS uses the %gs register to get at the thread local data. Now for some reason the gs register gets trashed somewhere along the way, say in a signal handler, it's possible that you'd get a segfault? Anyone got any other ideas (cc: [EMAIL PROTECTED] in case they do). -i signature.asc Description: Digital signature
Re: wait4 causes segfault in i386 chroot
On Thu, Jun 10, 2004 at 12:08:26PM -0700, Arun Sharma wrote: On 6/9/2004 10:16 PM, Ian Wienand wrote: I've tracked it down to doing a wait/waitpid/wait4 (they all end up in wait4) in a sigchld signal handler. If I do a minimal test case where I catch the sigchld and wait, once the call returns it segfaults as in this trace (gdb can't seem to give a good backtrace). I recall seeing this problem earlier. But I'm unable to reproduce it now. I tried with 2.4.x and 2.6.6. Will try 2.6.7-rc3 later today. What was your glibc version ? Hi, I can replicate it with 2.6.6, so I guess we must have different libcs :( The libc is 2.3.2.ds1-13 from Debian unstable. With this in mind, I ran in the chroot with LD_LIBRARY_PATH=/usr/lib/debug and to my surprise things seemed to work. Run it again with LD_LIBRARY_PATH=/usr/lib/debug/lib/tls (or indeed just leave the default path) and it segfaults. A guess : the only major difference with the optimised libraries is they enable __thread which has the effect of putting errno in the TLS area (sysdeps/unix/sysv/linux/i386). TLS uses the %gs register to get at the thread local data. Now for some reason the gs register gets trashed somewhere along the way, say in a signal handler, it's possible that you'd get a segfault? Anyone got any other ideas (cc: debian-glibc@lists.debian.org in case they do). -i signature.asc Description: Digital signature
Re: SIGILL in __libc_csu_fini
On Fri, Apr 02, 2004 at 12:33:26AM +0100, Ian Lynagh wrote: I'm having some trouble with ghc6 on ia64 (this is not using the packages, which also give SIGILL, but trying to crossport from x86 again. What versions of things are you using? I just installed both ghc6 and ghc-cvs packages on an I2, and apart from creating a 8MB executable file from my simple 10 line example both work fine. libc6.1 2.3.2.ds1-11 GNU C Library: Shared libraries and Timezone data ghc-cvs 20031220-3 GHC - the Glasgow Haskell Compilation system ghc66.2-3GHC - the Glasgow Haskell Compilation system gcc 3.3.3-2 The GNU C compiler (might want to leave glibc list off, they have enough to worry about until we can prove it's a glibc bug) -i [EMAIL PROTECTED] http://www.gelato.unsw.edu.au signature.asc Description: Digital signature
A question on debugging libraries
Hi,
I'm not sure if this is a bug or something I have misunderstood about
the debugging libraries. I want to show an example of debugging a
libc call, so just simply overflowed a buffer with strcpy.
---
#include stdio.h
#include string.h
char *b = A long string;
int main(void)
{
char a[1];
strcpy(a, b);
}
---
Which when I run on i386 under GDB with LD_LIBRARY_PATH=/usr/lib/debug
I get
--- gdb output on i386 ---
$ gcc -g -o test test.c
$ echo $LD_LIBRARY_PATH
/usr/lib/debug
$ gdb ./test
GNU gdb 6.0 (etc)
(gdb) r
Starting program: /home/ianw/test
Program received signal SIGSEGV, Segmentation fault.
0x74732067 in ?? ()
(gdb) back
#0 0x74732067 in ?? ()
#1 0x676e6972 in ?? ()
#2 0xba00 in ?? ()
#3 0xba0c in ?? ()
#4 0x40016c20 in ?? () from /lib/ld-linux.so.2
#5 0x0001 in ?? ()
#6 0x080482a0 in ?? ()
---
I don't belive the strcpy has been inlined, for example it shows up in ltrace
$ ltrace ./test
__libc_start_main(0x08048364, 1, 0xba04, 0x08048390, 0x080483f0
unfinished ...
strcpy(0xb9b7, A long string) = 0xb9b7
--- SIGSEGV (Segmentation fault) ---
+++ killed by SIGSEGV +++
I would have expected that this would give me a good backtrace. Is
this wrong?
-i
[EMAIL PROTECTED]
http://www.gelato.unsw.edu.au
pgp0.pgp
Description: PGP signature
A question on debugging libraries
Hi,
I'm not sure if this is a bug or something I have misunderstood about
the debugging libraries. I want to show an example of debugging a
libc call, so just simply overflowed a buffer with strcpy.
---
#include stdio.h
#include string.h
char *b = A long string;
int main(void)
{
char a[1];
strcpy(a, b);
}
---
Which when I run on i386 under GDB with LD_LIBRARY_PATH=/usr/lib/debug
I get
--- gdb output on i386 ---
$ gcc -g -o test test.c
$ echo $LD_LIBRARY_PATH
/usr/lib/debug
$ gdb ./test
GNU gdb 6.0 (etc)
(gdb) r
Starting program: /home/ianw/test
Program received signal SIGSEGV, Segmentation fault.
0x74732067 in ?? ()
(gdb) back
#0 0x74732067 in ?? ()
#1 0x676e6972 in ?? ()
#2 0xba00 in ?? ()
#3 0xba0c in ?? ()
#4 0x40016c20 in ?? () from /lib/ld-linux.so.2
#5 0x0001 in ?? ()
#6 0x080482a0 in ?? ()
---
I don't belive the strcpy has been inlined, for example it shows up in ltrace
$ ltrace ./test
__libc_start_main(0x08048364, 1, 0xba04, 0x08048390, 0x080483f0
unfinished ...
strcpy(0xb9b7, A long string) = 0xb9b7
--- SIGSEGV (Segmentation fault) ---
+++ killed by SIGSEGV +++
I would have expected that this would give me a good backtrace. Is
this wrong?
-i
[EMAIL PROTECTED]
http://www.gelato.unsw.edu.au
pgpVMksDxYvrr.pgp
Description: PGP signature
Re: A question on debugging libraries
On Mon, Feb 09, 2004 at 07:49:53PM -0500, Daniel Jacobowitz wrote:
You are trying to get a backtrace. A walk up the stack frame, yes? So
you generated a crash by overwriting the stack; naturally we can not
backtrace.
doh, you are of course right.
Just for the archives, don't use a stack variable and try something
like
--- new program ---
#include stdio.h
#include string.h
char *b = A long string;
char *a;
int main(void)
{
strcpy(a, b);
}
---
and you'll correctly be able to debug it
Program received signal SIGSEGV, Segmentation fault.
strcpy (dest=0x0, src=0x80484a4 A long string) at
../sysdeps/generic/strcpy.c:40
40 ../sysdeps/generic/strcpy.c: No such file or directory.
in ../sysdeps/generic/strcpy.c
(gdb) info args
dest = 0x0
src = 0x80484a4 A long string
(gdb)
-i
pgp8EdOt5jnAR.pgp
Description: PGP signature
Re: Moving glibc out of unstable
On Sun, Oct 26, 2003 at 07:21:35PM -0500, Jeff Bailey wrote: I'll also try to ia64/nptl in before then too. I simply added the following patch and it seems to work. This was just the obvious change, I may have missed something subtle. I've checked it and stressed it as much as I know how, and it looks fine. As an example - test environment - [EMAIL PROTECTED]:/local/ianw/bktree/linux-2.5-import$ uname -a Linux tartufi 2.6.0-test7 #1 SMP Wed Oct 22 15:01:19 EST 2003 ia64 GNU/Linux - looking at ld.so.cache for right flags - [EMAIL PROTECTED]:~$ sudo ldconfig -p | grep pthread libpthread.so.0 (libc6,IA-64, hwcap: 0x8000, OS ABI: Linux 2.6.0) = /lib/tls/libpthread.so.0 libpthread.so.0 (libc6,IA-64, OS ABI: Linux 2.4.0) = /lib/libpthread.so.0 - checking ld sees new library - [EMAIL PROTECTED]:~$ ldd /bin/ls | grep pthread libpthread.so.0 = /lib/tls/libpthread.so.0 (0x202c8000) [EMAIL PROTECTED]:~$ LD_ASSUME_KERNEL=2.4.0 ldd /bin/ls | grep pthread libpthread.so.0 = /lib/libpthread.so.0 (0x202d) - performance test to see it really uses the new library - [EMAIL PROTECTED]:~/pthreadbench$ ./lifecycle 337813 threads created in 4.9993 sec = 67572 per second [EMAIL PROTECTED]:~/pthreadbench$ LD_ASSUME_KERNEL=2.4.0 ./lifecycle 43677 threads created in 5.00046 sec = 8735 per second Thanks for making such great packages! -i [EMAIL PROTECTED] http://www.gelato.unsw.edu.au --- glibc-2.3.2.ds1-orig/debian/sysdeps/ia64.mk 2003-10-26 23:02:47.065287964 + +++ glibc-2.3.2.ds1/debian/sysdeps/ia64.mk 2003-10-26 23:12:44.802585329 + @@ -1,3 +1,7 @@ +GLIBC_PASSES += nptl + +nptl_LIBDIR = /tls + libc = libc6.1 libc_extra_config_options = $(extra_config_options) --with-tls
Re: Moving glibc out of unstable
On Sun, Oct 26, 2003 at 10:10:57PM -0500, Daniel Jacobowitz wrote: Wonderful. Could you post the results of zgrep 'Error' in the various log-test's in /usr/share/doc/libc6.1/? Ahh, yes, of course. *** Summary of errors *** Both builds : annexc.out Linuxthreads Build : tst-attr1 NPTL Build : tst-cancel[6,9,17] and test-[float,double,ldouble] Errors with some context *** BOTH BUILDS *** [/home/user/glibc-2.3.2.ds1/build-tree/ia64-libc/posix/annexc.out] Error 1 (ignored) diff between two annexc.out's --- /home/user/glibc-2.3.2.ds1/build-tree/ia64-libc/posix/annexc.out2003-10-27 00:03:33.447079233 + +++ /home/user/glibc-2.3.2.ds1/build-tree/ia64-nptl/posix/annexc.out2003-10-27 00:16:04.099413787 + @@ -67,7 +67,6 @@ * invalid macro `SSIZE_MAX' * invalid macro `XATTR_SIZE_MAX' * invalid macro `XATTR_LIST_MAX' -* invalid macro `TIMER_MAX' * invalid macro `TTY_NAME_MAX' * invalid macro `XATTR_NAME_MAX' ** macro `_POSIX_CLOCKRES_MAX' not defined @@ -79,6 +78,7 @@ !! not available === pthread.h === * invalid macro `sched_priority' +* invalid macro `PTHREAD_RWLOCK_INITIALIZER' ** macro `PTHREAD_PRIO_INHERIT' not defined ** macro `PTHREAD_PRIO_NONE' not defined ** macro `PTHREAD_PRIO_PROTECT' not defined *** LINUXTHREADS BUILD *** [/home/user/glibc-2.3.2.ds1/build-tree/ia64-libc/linuxthreads/tst-attr1.out] Error 1 tst-attr1.out reads as initial thread stack 0x6f7fc000-0x6fffc000 (0x80) thread stack 0x2010-0x2050 (0x40) /home/user/glibc-2.3.2.ds1/build-tree/ia64-libc/linuxthreads/tst-attr1: guardsize differs 32768 != 16384 thread stack 0x2010-0x20308000 (0x208000) /home/user/glibc-2.3.2.ds1/build-tree/ia64-libc/linuxthreads/tst-attr1: guardsize differs 32768 != 16384 thread stack 0x20308000-0x20548000 (0x24) thread guardsize 262144 *** NPTL build *** --- nptl/tst-cancel[6,9,17] failed with Timed out: killed the child process --- test-float failed with : testing float (without inline functions) Failure: fdim (0, NaN) == NaN: Exception Invalid operation set Failure: fdim (9, NaN) == NaN: Exception Invalid operation set Failure: fdim (-9, NaN) == NaN: Exception Invalid operation set Failure: fdim (inf, NaN) == NaN: Exception Invalid operation set Failure: fdim (-inf, NaN) == NaN: Exception Invalid operation set Failure: fdim (NaN, NaN) == NaN: Exception Invalid operation set Failure: fmax (0, NaN) == 0: Exception Invalid operation set Failure: fmax (9, NaN) == 9: Exception Invalid operation set Failure: fmax (-9, NaN) == -9: Exception Invalid operation set Failure: fmax (inf, NaN) == inf: Exception Invalid operation set Failure: fmax (-inf, NaN) == -inf: Exception Invalid operation set Failure: fmin (0, NaN) == 0: Exception Invalid operation set Failure: fmin (9, NaN) == 9: Exception Invalid operation set Failure: fmin (-9, NaN) == -9: Exception Invalid operation set Failure: fmin (inf, NaN) == inf: Exception Invalid operation set Failure: fmin (-inf, NaN) == -inf: Exception Invalid operation set --- test-[double|ldouble] failed with __ieee754_exp2l not implemented __ieee754_log2l not implemented -i -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Testing/help needed - experimental glibc version
On Wed, Oct 22, 2003 at 10:13:44PM -0400, Daniel Jacobowitz wrote: If you want to try it out, copy the relevant bits from i386.mk into ia64.mk in debian/sysdeps/; it should be pretty easy. The attached makes the build go a lot faster for me :) Also, as I mentioned in this thread http://sources.redhat.com/ml/libc-alpha/2003-09/msg00256.html IA64 gets a lot of warnings from a redefined symbol. Should this be modified with a dpatch in kernel-headers? -i--- ./patch_against/glibc-2.3.2.ds1/debian/rules.d/build.mk 2003-10-23 03:56:08.591766882 + +++ ./glibc-2.3.2.ds1/debian/rules.d/build.mk 2003-10-23 03:57:36.305632995 + @@ -3,6 +3,9 @@ # This little bit of magic makes it possible: xx=$(if $($(curpass)_$(1)),$($(curpass)_$(1)),$($(1))) +# Use as many processors as there are available +NJOBS=$(shell if [ -f /proc/cpuinfo ] ; then echo `cat /proc/cpuinfo | grep 'processor' | wc -l` ; else echo 1 ; fi) + $(patsubst %,mkbuilddir_%,$(GLIBC_PASSES)) :: mkbuilddir_% : $(stamp)mkbuilddir_% $(stamp)mkbuilddir_%: $(stamp)patch-stamp $(LINUX_HEADER_DIR) @echo Making builddir for $(curpass) @@ -45,7 +48,7 @@ $(patsubst %,build_%,$(GLIBC_PASSES)) :: build_% : $(stamp)build_% $(stamp)build_%: $(stamp)configure_% @echo Building $(curpass) - $(MAKE) -C $(DEB_BUILDDIR) 21 | tee -a $(log_build) + $(MAKE) -C $(DEB_BUILDDIR) -j $(NJOBS) 21 | tee -a $(log_build) touch $@ $(patsubst %,check_%,$(GLIBC_PASSES)) :: check_% : $(stamp)check_%
Re: Testing/help needed - experimental glibc version
On Thu, Oct 23, 2003 at 08:31:16AM -0400, Daniel Jacobowitz wrote: Sure, I suppose so. Send me a dpatch against the linux-kernel-headers package, please? Did you maybe mean a patch? It doesn't seem to use dpatches. -idiff -urN linux-2.6.0-test7-bk-orig/debian/patches/elf.h.patch linux-2.6.0-test7-bk/debian/patches/elf.h.patch --- linux-2.6.0-test7-bk-orig/debian/patches/elf.h.patch1970-01-01 00:00:00.0 + +++ linux-2.6.0-test7-bk/debian/patches/elf.h.patch 2003-10-24 02:43:43.247988275 + @@ -0,0 +1,12 @@ +# Stop warnings about redefined symbols in glibc +--- linux-2.6.0-test7-bk-orig/include/asm-ia64/elf.h 2003-10-24 02:26:14.622024559 + linux-2.6.0-test7-bk/include/asm-ia64/elf.h2003-10-24 02:27:33.785109526 + +@@ -42,8 +42,6 @@ + */ + #define ELF_ET_DYN_BASE (TASK_UNMAPPED_BASE + 0x8) + +-#define PT_IA_64_UNWIND 0x7001 +- + /* IA-64 relocations: */ + #define R_IA64_NONE 0x00/* none */ + #define R_IA64_IMM14 0x21/* symbol + addend, add imm14 */
Re: Testing/help needed - experimental glibc version
On Thu, Oct 23, 2003 at 08:31:16AM -0400, Daniel Jacobowitz wrote: Sure, I suppose so. Send me a dpatch against the linux-kernel-headers package, please? Did you maybe mean a patch? It doesn't seem to use dpatches. -idiff -urN linux-2.6.0-test7-bk-orig/debian/patches/elf.h.patch linux-2.6.0-test7-bk/debian/patches/elf.h.patch --- linux-2.6.0-test7-bk-orig/debian/patches/elf.h.patch1970-01-01 00:00:00.0 + +++ linux-2.6.0-test7-bk/debian/patches/elf.h.patch 2003-10-24 02:43:43.247988275 + @@ -0,0 +1,12 @@ +# Stop warnings about redefined symbols in glibc +--- linux-2.6.0-test7-bk-orig/include/asm-ia64/elf.h 2003-10-24 02:26:14.622024559 + linux-2.6.0-test7-bk/include/asm-ia64/elf.h2003-10-24 02:27:33.785109526 + +@@ -42,8 +42,6 @@ + */ + #define ELF_ET_DYN_BASE (TASK_UNMAPPED_BASE + 0x8) + +-#define PT_IA_64_UNWIND 0x7001 +- + /* IA-64 relocations: */ + #define R_IA64_NONE 0x00/* none */ + #define R_IA64_IMM14 0x21/* symbol + addend, add imm14 */
Re: Testing/help needed - experimental glibc version
On Tue, Oct 21, 2003 at 01:03:02PM -0400, Daniel Jacobowitz wrote: As some of you may have seen, there's a new version of glibc in unstable. It has a couple of nice features - particularly for x86, where both i686-optimized libraries and NPTL support are included. Hi, I've been silently following this and it looks really great. I built the new packages on one of our boxes, it appears to work fine, however NPTL wasn't included. Before I look into it too much futher I thought I might do your packages support NPTL it on ia64, and are there any flags etc I need to turn it on? Thanks for your work, -i [EMAIL PROTECTED] http://www.gelato.unsw.edu.au
Re: Testing/help needed - experimental glibc version
On Wed, Oct 22, 2003 at 10:13:44PM -0400, Daniel Jacobowitz wrote: If you want to try it out, copy the relevant bits from i386.mk into ia64.mk in debian/sysdeps/; it should be pretty easy. The attached makes the build go a lot faster for me :) Also, as I mentioned in this thread http://sources.redhat.com/ml/libc-alpha/2003-09/msg00256.html IA64 gets a lot of warnings from a redefined symbol. Should this be modified with a dpatch in kernel-headers? -i--- ./patch_against/glibc-2.3.2.ds1/debian/rules.d/build.mk 2003-10-23 03:56:08.591766882 + +++ ./glibc-2.3.2.ds1/debian/rules.d/build.mk 2003-10-23 03:57:36.305632995 + @@ -3,6 +3,9 @@ # This little bit of magic makes it possible: xx=$(if $($(curpass)_$(1)),$($(curpass)_$(1)),$($(1))) +# Use as many processors as there are available +NJOBS=$(shell if [ -f /proc/cpuinfo ] ; then echo `cat /proc/cpuinfo | grep 'processor' | wc -l` ; else echo 1 ; fi) + $(patsubst %,mkbuilddir_%,$(GLIBC_PASSES)) :: mkbuilddir_% : $(stamp)mkbuilddir_% $(stamp)mkbuilddir_%: $(stamp)patch-stamp $(LINUX_HEADER_DIR) @echo Making builddir for $(curpass) @@ -45,7 +48,7 @@ $(patsubst %,build_%,$(GLIBC_PASSES)) :: build_% : $(stamp)build_% $(stamp)build_%: $(stamp)configure_% @echo Building $(curpass) - $(MAKE) -C $(DEB_BUILDDIR) 21 | tee -a $(log_build) + $(MAKE) -C $(DEB_BUILDDIR) -j $(NJOBS) 21 | tee -a $(log_build) touch $@ $(patsubst %,check_%,$(GLIBC_PASSES)) :: check_% : $(stamp)check_%
