Package: libc6
Version: 2.7-3
Severity: grave
Justification: renders system (mostly) unusable
Hi, I upgraded libc6 to 2.7-3 using apt-get on a system running kernel
2.6.9 with SMP (unfortunately I don't have the option of changing this
kernel, it's provided by my colo provider), and dpkg crashed
Hi, I read the description of #256725 with interest, as I have just
experienced exactly the same segfault on my machine! Running 'sed m'
as the bug submitter suggests causes a segfault. Using gdb, I found
out that the bug looks like a buffer overflow bug:
#0 0x40092d23 in mallopt () from
reassign 100986 libc6-dev,manpages-dev
thanks
All bugs related to libc function calls belong to manpages-dev. The
original bug is related to a *binary* shipped with libc6-dev, so it
belongs to libc6-dev.
T
--
Computers aren't intelligent; they only think they are.
--
To UNSUBSCRIBE, email
I just confirmed that tail doesn't segfault anymore. This is on:
ii libc6 2.3.2-5GNU C Library: Shared libraries and Timezone
ii coreutils 5.0.90-3 The GNU core utilities
Can the bug submitter confirm that this has been fixed?
T
--
Life is all a great joke, but
tags 185649 + patch
thanks
T
--
What's a hot crossed bun? An angry rabbit.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
tags 185649 + patch
thanks
T
--
What's a hot crossed bun? An angry rabbit.
Just wondering... is this bug still alive? It's been sitting here with
patches for a long time now. If there's any problem with the patches, I'd
love to help iron it out. Thanks!
T
--
If you look at a thing nine hundred and ninety-nine times, you are perfectly
safe; if you look at it the
Hi, just wondering... has this bug been fixed with the inclusion of the
pthread manpages in glibc-doc? (Cf. #155794, fixed in a recent upload).
T
--
Life goes on...
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
On Mon, Jan 27, 2003 at 05:17:38PM +0100, Johan Walles wrote:
H. S. Teoh wrote:
Could this be an architecture-specific problem? I'm on an i386 FYI.
Yes, this is IA64 specific.
[snip]
Actually, I just checked on sparc: it shows a similar peculiarity,
although not as pronounced:
% grep -r
On Tue, Jan 28, 2003 at 01:59:48AM +0900, GOTO Masanori wrote:
At Mon, 27 Jan 2003 11:25:25 -0500,
H. S. Teoh [EMAIL PROTECTED] wrote:
On Mon, Jan 27, 2003 at 05:17:38PM +0100, Johan Walles wrote:
H. S. Teoh wrote:
Could this be an architecture-specific problem? I'm on an i386 FYI
On Thu, Jan 09, 2003 at 02:34:40PM -0500, Lee Bradshaw wrote:
Thanks for the quick response Bart. I stripped my ~/.muttrc down to the
single line that was causing the problem. Do you see anything wrong with
this?
freefall ~ $ cat .muttrc
# Change Re: Re: ... to Re: ...
set
while running in gdb and brovide us with the backtrace
(gdb command 'bt')?
On Thu, Jan 09, 2003 at 03:35:05PM -0500, H. S. Teoh wrote:
This looks like a regex bug in libc. See #175163.
Yes, there seems to be an infinite recursion in re_comp(). When I just
kept Enter pressed in gdb, it kept
I don't see this bug either. I'm using mutt (1.4.0-5) and libc6 (2.3.1-8),
and mutt works fine. Maybe it's an architecture-specific bug? Which
architecture are you using? I'm on i386.
T
--
Roasting my brains over a slow fire. Please do not interrupt this process.
--
To UNSUBSCRIBE, email
I don't see this bug either. I'm using mutt (1.4.0-5) and libc6 (2.3.1-8),
and mutt works fine. Maybe it's an architecture-specific bug? Which
architecture are you using? I'm on i386.
T
--
Roasting my brains over a slow fire. Please do not interrupt this process.
On Tue, Dec 31, 2002 at 06:36:53PM +0900, GOTO Masanori wrote:
At Mon, 30 Dec 2002 09:21:26 -0500,
H. S. Teoh [EMAIL PROTECTED] wrote:
[snip]
So I propose just applying the attached patch and closing this bug.
Thanks!
Thanks for your patch!
I applied it into debian-glibc cvs: debian
On Sun, Dec 29, 2002 at 12:20:01AM +0900, GOTO Masanori wrote:
At Thu, 26 Dec 2002 18:01:10 -0500,
H. S. Teoh [EMAIL PROTECTED] wrote:
[snip]
At any rate, I tried this with xterm, and got:
xterm: unable to access pty device: Permission denied
I'm not sure if Branden worked around
On Tue, Dec 31, 2002 at 06:36:53PM +0900, GOTO Masanori wrote:
At Mon, 30 Dec 2002 09:21:26 -0500,
H. S. Teoh [EMAIL PROTECTED] wrote:
[snip]
So I propose just applying the attached patch and closing this bug.
Thanks!
Thanks for your patch!
I applied it into debian-glibc cvs: debian
On Mon, Dec 30, 2002 at 12:16:40PM +0900, GOTO Masanori wrote:
At Fri, 27 Dec 2002 12:10:19 -0500,
H. S. Teoh [EMAIL PROTECTED] wrote:
[snip]
BTW, from manpages umount(2):
HISTORY
The original umount function was called as umount(device) and would
return ENOTBLK when
On Sun, Dec 29, 2002 at 12:20:01AM +0900, GOTO Masanori wrote:
At Thu, 26 Dec 2002 18:01:10 -0500,
H. S. Teoh [EMAIL PROTECTED] wrote:
[snip]
At any rate, I tried this with xterm, and got:
xterm: unable to access pty device: Permission denied
I'm not sure if Branden worked around
merge 106253 164571
thanks
Hi, these bugs appear to be at least related, if not identical. #106253
appears to be no longer valid, given the description in #164571.
T
--
A mathematician is a device for turning coffee into theorems. -- P. Erdos
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
tags 117680 + patch
thanks
Hi, does the attached patch qualify as a fix for this bug? :-) Personally
I don't see a need for ispell'ing C header files. (Doing an ispell on C
*strings* in a file might be a different story, because users may actually
see that stuff. But comments? IMNSHO, it's a
On Sat, Dec 28, 2002 at 12:53:28PM +, Ian Jackson wrote:
H. S. Teoh writes (Bug#12411: [PATCH] A better Directory Lister example):
...
I have declined to address this, since this example is mainly concerned
with using the libc directory reading functions, not with handling stdout
Hi, I just confirmed that trunc() is missing from /usr/include/math.h.
Furthermore, the following are also missing (referenced from the manpage
of trunc()):
- lrint
- nearbyint
- round
Oddly, these functions do *not* appear in the libc info pages.
Nevertheless, they are definitely in libm:
%
On Mon, Dec 30, 2002 at 10:57:47AM -0500, Daniel Jacobowitz wrote:
On Mon, Dec 30, 2002 at 10:23:16AM -0500, H. S. Teoh wrote:
Hi, I just confirmed that trunc() is missing from /usr/include/math.h.
Furthermore, the following are also missing (referenced from the manpage
of trunc
+, Ian Jackson wrote:
H. S. Teoh writes (Bug#12411: [PATCH] A better Directory Lister example):
...
I have declined to address this, since this example is mainly concerned
with using the libc directory reading functions, not with handling stdout
errors.
I actually think it's a libc
retitle 134097 drem(): need to document rounding to even number when quotient==0.5
thanks
IMHO, drem() *is* behaving as documented, just as the previous comment has
stated. The manpage for drem() describes the rounding to the nearest even
number when the quotient is exactly 0.5.
However, the
Hi, /usr/include/error.h is now documented in the info pages, under the
Error Messages node. This is on glibc-doc 2.3.1-8. And according to
the info page, these functions are GNU extensions.
So I propose this bug should be closed, or re-assigned to manpages-dev if
the bug submitter deems it
Hi, /usr/include/elf.h in libc6-dev (2.3.1-8) seems to have already fixed
this problem:
% grep SHN_UNDEF /usr/include/elf.h
#define SHN_UNDEF 0 /* Undefined section */
%
Unless this file contains architecture-dependent contents, I propose this
bug should be closed.
T
--
A
Hi, this bug has already been fixed in glibc-doc 2.3.1-8. The relevent
section from the info pages read:
[snip]
- Macro: int O_READ
Open the file for reading. Same as `O_RDONLY'; only defined on
GNU.
- Macro: int O_WRITE
Open the file for writing. Same as `O_WRONLY'; only
merge 106253 164571
thanks
Hi, these bugs appear to be at least related, if not identical. #106253
appears to be no longer valid, given the description in #164571.
T
--
A mathematician is a device for turning coffee into theorems. -- P. Erdos
tags 117680 + patch
thanks
Hi, does the attached patch qualify as a fix for this bug? :-) Personally
I don't see a need for ispell'ing C header files. (Doing an ispell on C
*strings* in a file might be a different story, because users may actually
see that stuff. But comments? IMNSHO, it's a
On Sat, Dec 28, 2002 at 12:53:28PM +, Ian Jackson wrote:
H. S. Teoh writes (Bug#12411: [PATCH] A better Directory Lister example):
...
I have declined to address this, since this example is mainly concerned
with using the libc directory reading functions, not with handling stdout
Hi, I just confirmed that trunc() is missing from /usr/include/math.h.
Furthermore, the following are also missing (referenced from the manpage
of trunc()):
- lrint
- nearbyint
- round
Oddly, these functions do *not* appear in the libc info pages.
Nevertheless, they are definitely in libm:
%
On Mon, Dec 30, 2002 at 10:57:47AM -0500, Daniel Jacobowitz wrote:
On Mon, Dec 30, 2002 at 10:23:16AM -0500, H. S. Teoh wrote:
Hi, I just confirmed that trunc() is missing from /usr/include/math.h.
Furthermore, the following are also missing (referenced from the manpage
of trunc
On Mon, Dec 30, 2002 at 11:21:37AM -0500, Daniel Jacobowitz wrote:
On Mon, Dec 30, 2002 at 11:19:32AM -0500, H. S. Teoh wrote:
[snip]
Aha. That explains it. So these functions are only defined for ISO C99?
Yes. Declaring something named round when it isn't part of the
relevant language
+, Ian Jackson wrote:
H. S. Teoh writes (Bug#12411: [PATCH] A better Directory Lister example):
...
I have declined to address this, since this example is mainly concerned
with using the libc directory reading functions, not with handling stdout
errors.
I actually think it's a libc
retitle 134097 drem(): need to document rounding to even number when
quotient==0.5
thanks
IMHO, drem() *is* behaving as documented, just as the previous comment has
stated. The manpage for drem() describes the rounding to the nearest even
number when the quotient is exactly 0.5.
However, the
Hi, I've just tested this bug, and observed something rather interesting:
% cpp /usr/include/unistd.h |grep fsync
extern int fsync (int __fd) ;
% cpp -D_POSIX_SOURCE /usr/include/unistd.h | grep fsync
%
So it gets included in the default header file, but not when _POSIX_SOURCE
is defined. Now
On Sat, Dec 28, 2002 at 07:23:06PM -0500, Daniel Jacobowitz wrote:
[snip]
It's guarded by:
#if defined __USE_BSD || defined __USE_XOPEN
_POSIX_SOURCE is:
_POSIX_SOURCEIEEE Std 1003.1.
i.e. not 1b.
Ahh, that explains it.
On the other hand, given:
_POSIX_C_SOURCE If
Hi, I've just tested this bug, and observed something rather interesting:
% cpp /usr/include/unistd.h |grep fsync
extern int fsync (int __fd) ;
% cpp -D_POSIX_SOURCE /usr/include/unistd.h | grep fsync
%
So it gets included in the default header file, but not when _POSIX_SOURCE
is defined. Now
On Sat, Dec 28, 2002 at 07:23:06PM -0500, Daniel Jacobowitz wrote:
[snip]
It's guarded by:
#if defined __USE_BSD || defined __USE_XOPEN
_POSIX_SOURCE is:
_POSIX_SOURCEIEEE Std 1003.1.
i.e. not 1b.
Ahh, that explains it.
On the other hand, given:
_POSIX_C_SOURCE If
Hi, it looks like the patch submitted for this bug got lost somewhere
between upstream CVS and Debian source. I'm looking at the source for
glibc 2.3.1-8, and it seems that the patch never got applied. Here is the
result of grep -nr SHMLBA */bits in glibc-2.3.1/sysdeps/unix/sysv/linux:
Hi, this bug has been fixed:
1) The info pages state:
- Function: void * tfind (const void *KEY, void *const *ROOTP,
comparison_fn_t COMPAR)
2) The man page states:
void *tfind(const void *key, const void **rootp,
int(*compar)(const void *, const void
tags 129550 + patch
thanks
Attached is a patch that re-words the description in the info file to
document the additional requirement that umount() can only take the mount
point, not the mount device, as argument.
T
--
No! I'm not in denial!
--- sysinfo.texi.ORIG 2002-12-27
reassign 88644 manpages-dev
thanks
Ben, apparently you forgot to also send your message to [EMAIL PROTECTED]
This should take care of it. :-)
T
--
We've all heard that a million monkeys banging on a million typewriters will
eventually reproduce the entire works of Shakespeare. Now, thanks to
In glibc-doc (2.3.1-6), the tags now look like:
TITLEThe GNU C Library: Introduction/TITLE
Furthermore, 'grep Untitled /usr/share/doc/glibc-doc/html/*' turns up
nothing. So I propose this bug be closed.
T
--
Acid falls with the rain; with love comes the pain.
--
To UNSUBSCRIBE, email to
tags 86220 + unreproducible
thanks
Should this bug be closed altogether? The submitter himself can't
reproduce it, and judging from the fact that tolower() *is* being used, I
think this is just a mistake on the part of the submitter. (Besides, the
bug is almost 2 years old and the submitter
reassign 94288 manpages-dev
thanks
The original reassignment didn't get sent to [EMAIL PROTECTED], so it never
happened. This should fix it.
T
--
MACINTOSH: Most Applications Crash, If Not, The Operating System Hangs
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of
Hi, it looks like the patch submitted for this bug got lost somewhere
between upstream CVS and Debian source. I'm looking at the source for
glibc 2.3.1-8, and it seems that the patch never got applied. Here is the
result of grep -nr SHMLBA */bits in glibc-2.3.1/sysdeps/unix/sysv/linux:
Hi, this bug has been fixed:
1) The info pages state:
- Function: void * tfind (const void *KEY, void *const *ROOTP,
comparison_fn_t COMPAR)
2) The man page states:
void *tfind(const void *key, const void **rootp,
int(*compar)(const void *, const void
reassign 16 glibc-doc,manpages-dev
thanks
The manpage termios(3) also claims it returns int:
int cfmakeraw(struct termios *termios_p);
And /usr/include/termios.h (libc6-dev 2.3.1-3) still defines it as
returning void. Neither the info page nor the manpage makes any mention of
what
tags 129550 + patch
thanks
Attached is a patch that re-words the description in the info file to
document the additional requirement that umount() can only take the mount
point, not the mount device, as argument.
T
--
No! I'm not in denial!
--- sysinfo.texi.ORIG 2002-12-27
reassign 88644 manpages-dev
thanks
Ben, apparently you forgot to also send your message to [EMAIL PROTECTED]
This should take care of it. :-)
T
--
We've all heard that a million monkeys banging on a million typewriters will
eventually reproduce the entire works of Shakespeare. Now, thanks to
In glibc-doc (2.3.1-6), the tags now look like:
TITLEThe GNU C Library: Introduction/TITLE
Furthermore, 'grep Untitled /usr/share/doc/glibc-doc/html/*' turns up
nothing. So I propose this bug be closed.
T
--
Acid falls with the rain; with love comes the pain.
tags 86220 + unreproducible
thanks
Should this bug be closed altogether? The submitter himself can't
reproduce it, and judging from the fact that tolower() *is* being used, I
think this is just a mistake on the part of the submitter. (Besides, the
bug is almost 2 years old and the submitter
reassign 94288 manpages-dev
thanks
The original reassignment didn't get sent to [EMAIL PROTECTED], so it never
happened. This should fix it.
T
--
MACINTOSH: Most Applications Crash, If Not, The Operating System Hangs
At least, it's not surprising that the minimal case Branden provided in
BTS segfaults. It's nothing to do with getpt(); the code is using in
uninitialized pointer *pts.
Barring that, however, I have just confirmed that on libc6 (2.3.1-3),
getpt() does not return an error if /dev/pts is chmod'd to
tags 12411 + patch
thanks
Hi, attached is a patch that gives a better Directory Lister example.
Ian's concerns are addressed as follows:
* it does not check the return values from closedir or puts;
Now it does.
* it does not fflush stdout (so that errors writing stdout will not be
Jeff Bailey wrote:
The original bug seems to be for manpages not correctly documenting
strsignal needs _GNU_SOURCE defined. That appears to now be
corrected.
Confirmed.
Is there still a bug here?
IMHO, this bug should be closed. The other issues raised seems to be
fairly unanimously
Should this bug be downgraded to wishlist? The bug submitter did say it
would be useful if Moreover, according to glibc info docs:
- Macro: int EPIPE
Broken pipe; there is no process reading from the other end of a
pipe. Every library function that returns this error code also
At least, it's not surprising that the minimal case Branden provided in
BTS segfaults. It's nothing to do with getpt(); the code is using in
uninitialized pointer *pts.
Barring that, however, I have just confirmed that on libc6 (2.3.1-3),
getpt() does not return an error if /dev/pts is chmod'd to
tags 12411 + patch
thanks
Hi, attached is a patch that gives a better Directory Lister example.
Ian's concerns are addressed as follows:
* it does not check the return values from closedir or puts;
Now it does.
* it does not fflush stdout (so that errors writing stdout will not be
Jeff Bailey wrote:
The original bug seems to be for manpages not correctly documenting
strsignal needs _GNU_SOURCE defined. That appears to now be
corrected.
Confirmed.
Is there still a bug here?
IMHO, this bug should be closed. The other issues raised seems to be
fairly unanimously
I've just confirmed that glob() does exhibit problems dealing with escaped
*'s. Attached is the test program I used (adapted and enhanced from
Herbert's version to allow easier testing). I ran my tests in a directory
with the structure:
drwx-- hsteoh/hsteoh 0 2002-12-26 23:02:43 ./
Hi, I've also been unable to reproduce this bug. Currently, I have
ii libc6 2.3.1-3GNU C Library: Shared libraries and Timezone
The test program and the input file are attached. Here are some test runs:
% a.out '^ {0,3}([|:}#] ?){3}.*' test.in
blah fasel
blah fasel
blah
Hi, I've also been unable to reproduce this bug. Currently, I have
ii libc6 2.3.1-3GNU C Library: Shared libraries and Timezone
The test program and the input file are attached. Here are some test runs:
% a.out '^ {0,3}([|:}#] ?){3}.*' test.in
blah fasel
blah fasel
blah
On Sat, Nov 16, 2002 at 08:58:48AM +1100, Herbert Xu wrote:
On Fri, Nov 15, 2002 at 01:22:44PM -0800, Jeff Bailey wrote:
On Sat, Nov 16, 2002 at 08:10:22AM +1100, Herbert Xu wrote:
Sure, but it would also be reasonable to flush the buffer to the screen
every (screensize/2) so that a
On Sun, Nov 17, 2002 at 12:12:44PM +1100, Herbert Xu wrote:
On Sat, Nov 16, 2002 at 08:02:43PM -0500, H. S. Teoh wrote:
I guess the question is, at what point do we say, this is enough for
practical purposes, we'll stop here? Or is it OK to let tail consume
resources until it eats up
On Sat, Nov 16, 2002 at 08:58:48AM +1100, Herbert Xu wrote:
On Fri, Nov 15, 2002 at 01:22:44PM -0800, Jeff Bailey wrote:
On Sat, Nov 16, 2002 at 08:10:22AM +1100, Herbert Xu wrote:
Sure, but it would also be reasonable to flush the buffer to the screen
every (screensize/2) so that a
On Sun, Nov 17, 2002 at 12:12:44PM +1100, Herbert Xu wrote:
On Sat, Nov 16, 2002 at 08:02:43PM -0500, H. S. Teoh wrote:
I guess the question is, at what point do we say, this is enough for
practical purposes, we'll stop here? Or is it OK to let tail consume
resources until it eats up
On Fri, Nov 15, 2002 at 08:23:24AM -0500, Jeff Bailey wrote:
On Fri, 2002-11-15 at 04:00, Herbert Xu wrote:
But the original bug seems to be more of an issue: shouldn't it be a bug
that tail chews up infinite amounts of memory when it can't find an
end-of-line char? IMHO, tail should
On Fri, Nov 15, 2002 at 08:23:24AM -0500, Jeff Bailey wrote:
On Fri, 2002-11-15 at 04:00, Herbert Xu wrote:
But the original bug seems to be more of an issue: shouldn't it be a bug
that tail chews up infinite amounts of memory when it can't find an
end-of-line char? IMHO, tail should
72 matches
Mail list logo
