Processing commands for cont...@bugs.debian.org:
tags 709992 + patch
Bug #709992 [src:eglibc] eglibc: FTBFS: Assembler messages: Error: bad register
expression
Ignoring request to alter tags of bug #709992 to the same tags previously set
thanks
Stopping processing here.
Please contact me if
Processing commands for cont...@bugs.debian.org:
tags 709992 + patch
Bug #709992 [src:eglibc] eglibc: FTBFS: Assembler messages: Error: bad register
expression
Added tag(s) patch.
thanks
Stopping processing here.
Please contact me if you need assistance.
--
709992:
Package: libc6
Version: 2.17-6
Severity: important
Hi,
GNU libc6 in sid is breaking GNU CVS; some operations can
cause a segfault. I’ve tracked it down to:
tglase@tglase:~ $ cat x.c
#define _GNU_SOURCE
#include errno.h
#include stdio.h
#include string.h
#include unistd.h
void tst(const char *,
From the 2.17 NEWS:
* The `crypt' function now fails if passed salt bytes that violate the
specification for those values. On Linux, the `crypt' function will
consult /proc/sys/crypto/fips_enabled to determine if FIPS mode is
enabled, and fail on encrypted strings using the MD5 or DES
Debian Bug Tracking System dixit:
If you wish to submit further information on this problem, please
send it to 714...@bugs.debian.org.
Oh well, a '%' is not in the list of DES inputs, so differing
is permitted, but returning NULL is so very not nice.
Shortening the string shows “DES” can be
Hi eglibc maintainers,
the attached crash in eperl looks like a bug in getopt_long of libc6
to me:
[ 18.024562] eperl[2718]: segfault at 1 ip b74b0d4f sp bf9457ec error 4 in
libc-2.17.so[b7433000+1a9000]
Backtrace:
Program received signal SIGSEGV, Segmentation fault.
__strlen_sse2 () at
On Thu, Jun 27, 2013 at 01:07:13AM +0200, Axel Beckert wrote:
#3 0x770e5783 in getopt_long (argc=1, argv=0x7fffe228,
options=0x0, long_options=0x1, opt_index=0x0)
at getopt1.c:66
Why are the options and long_options arguments shown with nonsense
contents?
Bastian
--
In the
found 2.17-1
thanks
On Tue, Jun 25, 2013 at 11:06:17AM +, Debian Bug Tracking System wrote:
Processing commands for cont...@bugs.debian.org:
notfound 713035 2.17-5
Bug #713035 [libc6] FTBFS on amd64/ia64 testsuite fails
No longer marked as found in versions eglibc/2.17-5.
This is
On Thu, Jun 27, 2013 at 01:07:13AM +0200, Axel Beckert wrote:
Hi eglibc maintainers,
the attached crash in eperl looks like a bug in getopt_long of libc6
to me:
[ 18.024562] eperl[2718]: segfault at 1 ip b74b0d4f sp bf9457ec error 4 in
libc-2.17.so[b7433000+1a9000]
Backtrace:
On Wed, Jun 26, 2013 at 10:48:55PM +, Thorsten Glaser wrote:
Debian Bug Tracking System dixit:
If you wish to submit further information on this problem, please
send it to 714...@bugs.debian.org.
Oh well, a '%' is not in the list of DES inputs, so differing
is permitted, but returning
Hi Aurelien!
Aurelien Jarno wrote:
I object. The problem is clearly on the eperl side, which passes to
getopt_long an option structure not ended by { 0, 0, 0, 0 }.
Thanks for that hint!
Regards, Axel
--
,''`. | Axel Beckert a...@debian.org, http://people.debian.org/~abe/
:
Aurelien Jarno dixit:
As the function is POSIX compliant, it looks like to me a documentation
issue. Should this bug be reassigned to manpages-dev to mention the fact
that the function might return NULL in case of error?
The NULL-in-case-of-error mentioned by POSIX is when the
function is not
On Wed, Jun 26, 2013 at 11:53:39PM +, Thorsten Glaser wrote:
Aurelien Jarno dixit:
As the function is POSIX compliant, it looks like to me a documentation
issue. Should this bug be reassigned to manpages-dev to mention the fact
that the function might return NULL in case of error?
The
Your message dated Thu, 27 Jun 2013 01:37:07 +0200
with message-id 20130626233707.gb13...@hall.aurel32.net
and subject line Re: Bug#712047: libc6-dev: cannot build C programs
has caused the Debian Bug report #712047,
regarding libc6-dev: cannot build C programs
to be marked as done.
This means
Processing commands for cont...@bugs.debian.org:
tag 713836 + unreproducible
Bug #713836 [libc6] regcomp(3) writes past end of regex_t; breaks kernel compile
Added tag(s) unreproducible.
tag 713836 + moreinfo
Bug #713836 [libc6] regcomp(3) writes past end of regex_t; breaks kernel compile
Added
Aurelien Jarno dixit:
ambiguity that crypt can return NULL for any failure (i.e. not
successful completion):
Indeed, but, one, it doesn’t list any other error code (nor do
the glibc manpages) and two, there _is_ something called common
law: it’s been like this for decades.
This is *your*
On Thu, Jun 27, 2013 at 12:28:22AM +, Thorsten Glaser wrote:
Aurelien Jarno dixit:
ambiguity that crypt can return NULL for any failure (i.e. not
successful completion):
Indeed, but, one, it doesn’t list any other error code (nor do
the glibc manpages) and two, there _is_ something
tag 713836 + unreproducible
tag 713836 + moreinfo
thanks
On Sun, Jun 23, 2013 at 02:59:20AM -0400, sacrificial-spam-addr...@horizon.com
wrote:
Package: libc6
Version: 2.17-6
Architecture: i386
Severity: important
This problem cropped up while compiling the kernel; it breaks
On Sun, Jun 23, 2013 at 07:18:39PM +0200, Tomas Janousek wrote:
Hi,
On Sun, Jun 23, 2013 at 03:13:43AM -0400,
sacrificial-spam-addr...@horizon.com wrote:
Although this doesn't break anything else, it renders the package useless.
It does break stuff. The nvidia driver for example -- it
Aurelien Jarno dixit:
Please provide a patch, and I will add it in the next upload. If you
don't, you will sign responsible for all security holes introduced into
previously-working code in the archive.
It's freaking late at night, and I just spent hours fighting
with gnulib and *then* hours I'd
I am personally not able to to reproduce the issue with your test
program on an up to date i386 sid system. Could you please provide us
the command you are using to compile the test code and the locale you
are using?
Very interesting! I'm also using an up-to-date sid system.
No locale is
Okay, I did a bit of comparison. The machine the binary was *compiled*
on seemed to matter, not the one it was *run* on. A bit of extra
printing revealed the obvious culprit:
[539]$ ./a.out
sizeof regex_t = 28
array[1] confirmed all-zero
J'accuse! buf[0] = 0x18
Bug! array[1] has been
22 matches
Mail list logo
