Processed: found 1017030 in 2.34-7
Processing commands for cont...@bugs.debian.org: > found 1017030 2.34-7 Bug #1017030 [libc6] libc6 should restart dictd on upgrade Marked as found in versions glibc/2.34-7. > thanks Stopping processing here. Please contact me if you need assistance. -- 1017030: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1017030 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: Re: Bug#1017030: dictd: yields "client_read_status: Connection reset by peer" in the client
Processing commands for cont...@bugs.debian.org: > retitle 1017030 libc6 should restart dictd on upgrade Bug #1017030 [dictd] dictd closes the connection immediately, yielding "client_read_status: Connection reset by peer" in the client Changed Bug title to 'libc6 should restart dictd on upgrade' from 'dictd closes the connection immediately, yielding "client_read_status: Connection reset by peer" in the client'. > severity 1017030 normal Bug #1017030 [dictd] libc6 should restart dictd on upgrade Severity set to 'normal' from 'grave' > reassign 1017030 libc6 Bug #1017030 [dictd] libc6 should restart dictd on upgrade Bug reassigned from package 'dictd' to 'libc6'. No longer marked as found in versions dictd/1.13.0+dfsg-1. Ignoring request to alter fixed versions of bug #1017030 to the same values previously set > End of message, stopping processing here. Please contact me if you need assistance. -- 1017030: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1017030 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#798691: marked as done (libc6-i686: sin() sometimes broken)
Your message dated Tue, 6 Sep 2022 22:56:15 +0200 with message-id and subject line Re: Bug#798691: libc6-i686: sin() sometimes broken has caused the Debian Bug report #798691, regarding libc6-i686: sin() sometimes broken to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 798691: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=798691 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: libc6-i686 Version: 2.19-18+deb8u1 Severity: important Hi, I was trying to create a local backport of python-cffi onto jessie/i386. On a system with libc6-i686 installed, I get a failure in the self test of the build: > assert library.sin(12.3) == math.sin(12.3) E assert 0.8444952930965295 == -0.26323179136580094 Uninstalling libc6-i686 lets the full build and tests run through. Something very related has already happened before: https://www.sourceware.org/bugzilla/show_bug.cgi?id=16625 This suggests a compiler bug in gcc 4.8. But jessie is compiled with 4.9, so it must be something a bit different. Severity: important as giving wrong results to math functions isn't something trivial, really and can affect multiple unrelated components/packages. Cheers Christian -- www.cosmokey.com --- End Message --- --- Begin Message --- Version: 2.21-0experimental0 On 2015-09-13 16:26, Aurelien Jarno wrote: > On 2015-09-11 20:33, Christian Tacke wrote: > > Package: libc6-i686 > > Version: 2.19-18+deb8u1 > > Severity: important > > > > Hi, > > Hi, > > > I was trying to create a local backport of python-cffi onto > > jessie/i386. > > > > On a system with libc6-i686 installed, I get a failure in > > the self test of the build: > > > > > assert library.sin(12.3) == math.sin(12.3) > > E assert 0.8444952930965295 == -0.26323179136580094 > > > > Uninstalling libc6-i686 lets the full build and tests run > > through. > > > > Something very related has already happened before: > > https://www.sourceware.org/bugzilla/show_bug.cgi?id=16625 > > > > This suggests a compiler bug in gcc 4.8. But jessie is > > compiled with 4.9, so it must be something a bit different. > > No, the glibc on jessie is actually built with gcc 4.8, as gcc 4.9 > introduces some regression on the pthread cleanup functions. This > means it's very likely to be the same bug. This is a bug in gcc 4.8 that has been fixed in gcc 4.9, which is used to build the glibc since version 2.21-0experimental0. I am therefore closing the bug accordingly. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net--- End Message ---
Bug#710439: marked as done (pixman fails testsuite on powerpc due to glibc)
Your message dated Tue, 6 Sep 2022 21:21:58 +0200 with message-id and subject line Re: More info has caused the Debian Bug report #710439, regarding pixman fails testsuite on powerpc due to glibc to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 710439: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=710439 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: eglibc Version: 2.13-38 When I try to build pixman (0.26.0-4) in my powerpc wheezy chroot, the testsuite fails. The failure usually looks like: *** glibc detected *** /tmp/pixman-0.26.0/build/test/.libs/lt-scaling-test: corrupted double-linked list: 0x10068e80 *** === Backtrace: = /lib/powerpc-linux-gnu/libc.so.6(+0x86ef4)[0xfd4fef4] /lib/powerpc-linux-gnu/libc.so.6(+0x88b24)[0xfd51b24] /lib/powerpc-linux-gnu/libc.so.6(cfree+0x8c)[0xfd554cc] /tmp/pixman-0.26.0/build/test/.libs/lt-scaling-test[0x10001ba0] /tmp/pixman-0.26.0/build/test/.libs/lt-scaling-test[0x100024dc] /usr/lib/powerpc-linux-gnu/libgomp.so.1(+0xb5e0)[0xfe975e0] /lib/powerpc-linux-gnu/libpthread.so.0(+0x67b0)[0xfe577b0] /lib/powerpc-linux-gnu/libc.so.6(clone+0x84)[0xfdbd960] === Memory map: 0010-00103000 r-xp 00:00 0 [vdso] 0fca-0fca8000 r-xp fd:01 4211711 /lib/powerpc-linux-gnu/librt-2.13.so 0fca8000-0fcb7000 ---p 8000 fd:01 4211711 /lib/powerpc-linux-gnu/librt-2.13.so 0fcb7000-0fcb8000 r--p 7000 fd:01 4211711 /lib/powerpc-linux-gnu/librt-2.13.so 0fcb8000-0fcb9000 rw-p 8000 fd:01 4211711 /lib/powerpc-linux-gnu/librt-2.13.so 0fcc9000-0fe39000 r-xp fd:01 4211720 /lib/powerpc-linux-gnu/libc-2.13.so 0fe39000-0fe3d000 r--p 0017 fd:01 4211720 /lib/powerpc-linux-gnu/libc-2.13.so 0fe3d000-0fe3e000 rw-p 00174000 fd:01 4211720 /lib/powerpc-linux-gnu/libc-2.13.so 0fe3e000-0fe41000 rw-p 00:00 0 0fe51000-0fe69000 r-xp fd:01 4211733 /lib/powerpc-linux-gnu/libpthread-2.13.so ... Also: *** glibc detected *** /tmp/pixman-0.26.0/build/test/.libs/lt-affine-test: corrupted double-linked list: 0x45f00760 *** === Backtrace: = /lib/powerpc-linux-gnu/libc.so.6(+0x86ef4)[0xfd4fef4] /lib/powerpc-linux-gnu/libc.so.6(+0x88b24)[0xfd51b24] /lib/powerpc-linux-gnu/libc.so.6(cfree+0x8c)[0xfd554cc] /tmp/pixman-0.26.0/build/test/.libs/lt-affine-test[0x10001a0c] /tmp/pixman-0.26.0/build/test/.libs/lt-affine-test[0x10002188] /usr/lib/powerpc-linux-gnu/libgomp.so.1(+0xb5e0)[0xfe975e0] /lib/powerpc-linux-gnu/libpthread.so.0(+0x67b0)[0xfe577b0] /lib/powerpc-linux-gnu/libc.so.6(clone+0x84)[0xfdbd960] === Memory map: ... If I install libc6 and libc6-dev 2.17-3, the problem goes away and all tests pass. Hence why I am assigning blame to glibc for this. Of course this makes me rather concerned about the glibc in wheezy for use on powerpc. Any idea what could be broken in 2.13 and how to fix it, since I would prefer to stick with stable. A patch to 2.13 would seem rather preferable for wheezy than having to start mixing in other bits, especially glibc. I am building on an IBM p710 with 6 cores, so lots of parallelism is certainly possible and likely, which may help to trigger bugs like this. I would think this qualifies as a severity for FTBFS, even though it isn't glibc that is failing to build, but it is causing other things to fail to build. -- Len Sorensen --- End Message --- --- Begin Message --- Version: 2.17-1 On 2013-09-16 15:57, Lennart Sorensen wrote: > So I have tried some more attempts. > > If I disable vmx use in pixman, the crashes go away. > If I disable use of openMP in pixman, the crashes go away. > If I run on a power6 rather than power7, the crashes go away. > If I use strace, the crashes go away. > If I use gdb, the crashes go away. > If I install libc 2.17 instead of 2.13 (without recompiling anything), > the crashes go away. > > So somehow it seems to be in interaction between vmx instructions and > openMP on power7, probably to due with memory barriers (or lack of > them somewhere between threads), with very specific timing (which gdb, > strace both affect), which has either been fixed in libc 2.17, or the > timing is somehow different again masking the problem. Since the problem is not reproducible starting with glibc 2.17 and that we do not support glibc 2.13 shipped (in Wheezy) anymore, I
Processed: bug 884075 is forwarded to https://sourceware.org/bugzilla/show_bug.cgi?id=10844
Processing commands for cont...@bugs.debian.org: > forwarded 884075 https://sourceware.org/bugzilla/show_bug.cgi?id=10844 Bug #884075 [glibc] glibc: Wrong results with regex backreferences Changed Bug forwarded-to-address to 'https://sourceware.org/bugzilla/show_bug.cgi?id=10844' from 'https://sourceware.org/bugzilla/show_bug.cgi?id=11053'. > thanks Stopping processing here. Please contact me if you need assistance. -- 884075: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=884075 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: bug 884075 is forwarded to https://sourceware.org/bugzilla/show_bug.cgi?id=10844
Processing commands for cont...@bugs.debian.org: > forwarded 884075 https://sourceware.org/bugzilla/show_bug.cgi?id=10844 Bug #884075 [glibc] glibc: Wrong results with regex backreferences Ignoring request to change the forwarded-to-address of bug#884075 to the same value > thanks Stopping processing here. Please contact me if you need assistance. -- 884075: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=884075 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#865469: marked as done (libc6-dev: a program crashes if it is statically linked against OpenSSL)
Your message dated Tue, 6 Sep 2022 21:13:03 +0200
with message-id
and subject line Re: Bug#865469: libc6-dev: a program crashes if it is
statically linked against OpenSSL
has caused the Debian Bug report #865469,
regarding libc6-dev: a program crashes if it is statically linked against
OpenSSL
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
865469: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=865469
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: libc6-dev
Severity: normal
Dear Maintainer,
*** Reporter, please consider answering these questions, where appropriate ***
* What led up to the situation?
Programs can't be statically linked against OpenSSL in Debian Stretch.
* What exactly did you do (or not do) that was effective (or
ineffective)?
Try to compile this program with this command:
gcc -static hello.c -lssl -lcrypto -ldl -pthread
#include
#include
#include
int main(void)
{
OpenSSL_add_ssl_algorithms();
printf("Hello World!\n");
return 0;
}
* What was the outcome of this action?
If you run the statically linked program, you get a crash in glibc startup
code:
#0 0x in ?? ()
#1 0x006296c6 in __register_frame_info.part.4 ()
#2 0x004017fd in frame_dummy ()
#3 0x0058c2d7 in __libc_csu_init ()
#4 0x0058b95b in generic_start_main ()
#5 0x0058bc3e in __libc_start_main ()
#6 0x0040172a in _start ()
* What outcome did you expect instead?
The compiled program should work.
-- System Information:
Debian Release: 9.0
APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.4.72 (SMP w/12 CPU cores; PREEMPT)
Locale: LANG=cs_CZ.utf8, LC_CTYPE=cs_CZ.utf8 (charmap=UTF-8),
LANGUAGE=cs_CZ.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
--- End Message ---
--- Begin Message ---
Version: 2.34-1
On 2017-08-20 19:12, Aurelien Jarno wrote:
> control: forcemerge 872727 -1
>
> On 2017-06-21 20:48, Mikulas Patocka wrote:
> > Package: libc6-dev
> > Severity: normal
> >
> > Dear Maintainer,
> >
> > *** Reporter, please consider answering these questions, where appropriate
> > ***
> >
> >* What led up to the situation?
> >
> > Programs can't be statically linked against OpenSSL in Debian Stretch.
> >
> >* What exactly did you do (or not do) that was effective (or
> > ineffective)?
> >
> > Try to compile this program with this command:
> > gcc -static hello.c -lssl -lcrypto -ldl -pthread
> >
> > #include
> > #include
> > #include
> >
> > int main(void)
> > {
> > OpenSSL_add_ssl_algorithms();
> > printf("Hello World!\n");
> > return 0;
> > }
> >
> >* What was the outcome of this action?
> >
> > If you run the statically linked program, you get a crash in glibc startup
> > code:
> > #0 0x in ?? ()
> > #1 0x006296c6 in __register_frame_info.part.4 ()
> > #2 0x004017fd in frame_dummy ()
> > #3 0x0058c2d7 in __libc_csu_init ()
> > #4 0x0058b95b in generic_start_main ()
> > #5 0x0058bc3e in __libc_start_main ()
> > #6 0x0040172a in _start ()
> >
> >* What outcome did you expect instead?
> >
> > The compiled program should work.
>
> This is an upstream issue, due to two changes:
> 1) libssl is now linked with pthread
> 2) libssl now try to run getaddrinfo or gethostbyname
>
> This trigger the following bug:
> https://sourceware.org/bugzilla/show_bug.cgi?id=21975
>
> As a workaround you might want to link your binary against libssl1.0
> instead and without -pthread.
Since glibc 2.34, libpthread has been integrated into libc. As a side
effect this fixes this bug. I am therefore closing this bug.
Regards
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net--- End Message ---
Bug#872727: marked as done (Bug#872727: libc6-dev: gethostbyname segfaults with libnss_resolve.so.2 for static binaries)
Your message dated Tue, 6 Sep 2022 21:13:03 +0200
with message-id
and subject line Re: Bug#865469: libc6-dev: a program crashes if it is
statically linked against OpenSSL
has caused the Debian Bug report #865469,
regarding Bug#872727: libc6-dev: gethostbyname segfaults with
libnss_resolve.so.2 for static binaries
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
865469: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=865469
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: libc6-dev
Version: 2.24-11+deb9u1
Severity: normal
Dear Maintainer,
with glibc 2.24 (reproducible on 64-bit Debian 9 or Ubuntu 17.04),
gethostbyname() always segfaults if the binary was linked statically:
$ echo -e "#include \nint main(void){gethostbyname(\"foo\");}" >foo.c
&& \
gcc -g -static foo.c && ./a.out
/tmp/ccp8JNGC.o: In function `main':
/tmp/foo.c:2: warning: Using 'gethostbyname' in statically linked applications
requires at runtime the shared libraries from the glibc version used for linking
Segmentation fault
$ gdb a.out
GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
[...]
Reading symbols from a.out...done.
(gdb) run
Starting program: /tmp/a.out
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Program received signal SIGSEGV, Segmentation fault.
0x in ?? ()
(gdb) bt
#0 0x in ?? ()
#1 0x772ac040 in __pthread_initialize_minimal_internal () at
nptl-init.c:460
#2 0x772ab5e1 in _init () at ../sysdeps/x86_64/crti.S:72
#3 0x776cc830 in ?? () from
/lib/x86_64-linux-gnu/libnss_myhostname.so.2
#4 0x00478a7a in call_init.part ()
#5 0x00478c35 in _dl_init ()
#6 0x0047089e in dl_open_worker ()
#7 0x0046e0f4 in _dl_catch_error ()
#8 0x0047024c in _dl_open ()
#9 0x00439ba2 in do_dlopen ()
#10 0x0046e0f4 in _dl_catch_error ()
#11 0x00439bd7 in dlerror_run ()
#12 0x00439da3 in __libc_dlopen_mode ()
#13 0x00436b3b in __nss_lookup_function ()
#14 0x00436d45 in __nss_next2 ()
#15 0x0043504a in gethostbyname_r ()
#16 0x00434d93 in gethostbyname ()
#17 0x00400b2e in main () at foo.c:2
In my upstream bug report, a commenter noted that this weren't reproducible in
Fedora's glibc 2.24 or 2.25, suggesting this "could be a Debian or Ubuntu
patch": https://sourceware.org/bugzilla/show_bug.cgi?id=21975
-- System Information:
Debian Release: 9.1
APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.9.0-3-amd64 (SMP w/64 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages libc6-dev depends on:
ii libc-dev-bin2.24-11+deb9u1
ii libc6 2.24-11+deb9u1
ii linux-libc-dev 4.9.30-2+deb9u3
libc6-dev recommends no packages.
Versions of packages libc6-dev suggests:
pn glibc-doc
ii manpages-dev 4.10-2
-- no debconf information
--- End Message ---
--- Begin Message ---
Version: 2.34-1
On 2017-08-20 19:12, Aurelien Jarno wrote:
> control: forcemerge 872727 -1
>
> On 2017-06-21 20:48, Mikulas Patocka wrote:
> > Package: libc6-dev
> > Severity: normal
> >
> > Dear Maintainer,
> >
> > *** Reporter, please consider answering these questions, where appropriate
> > ***
> >
> >* What led up to the situation?
> >
> > Programs can't be statically linked against OpenSSL in Debian Stretch.
> >
> >* What exactly did you do (or not do) that was effective (or
> > ineffective)?
> >
> > Try to compile this program with this command:
> > gcc -static hello.c -lssl -lcrypto -ldl -pthread
> >
> > #include
> > #include
> > #include
> >
> > int main(void)
> > {
> > OpenSSL_add_ssl_algorithms();
> > printf("Hello World!\n");
> > return 0;
> > }
> >
> >* What was the outcome of this action?
> >
> > If you run the statically linked program, you get a crash in glibc startup
> > code:
> > #0 0x in ?? ()
> > #1 0x006296c6 in __register_frame_info.part.4 ()
> > #2 0x004017fd in frame_dummy ()
> > #3 0x0058c2d7 in __libc_csu_init ()
> > #4 0x0058b95b in generic_start_main ()
> > #5 0x0058bc3e in __libc_start_main ()
> > #6 0x0040172a in _start ()
> >
> >* What outcome did you expect
