* [Bug libc/18493] Infinite loop/deadlock? in __libc_recv (fd=fd@entry=300, buf=buf@entry=0x7f6042880600, n=n@entry=5, flags=-1, flags@entry=258) at ../sysdeps/unix/sysv/linux/x86_64/recv.c:33
2015-06-05 11:12 [Bug libc/18493] New: Infinite loop/deadlock? in __libc_recv (fd=fd@entry=300, buf=buf@entry=0x7f6042880600, n=n@entry=5, flags=-1, flags@entry=258) at ../sysdeps/unix/sysv/linux/x86_64/recv.c:33 dan at censornet dot com
@ 2015-06-05 11:13 ` dan at censornet dot com
2015-06-05 11:17 ` dan at censornet dot com
` (7 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: dan at censornet dot com @ 2015-06-05 11:13 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=18493
Dan Searle <dan at censornet dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Severity|normal |critical
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug libc/18493] Infinite loop/deadlock? in __libc_recv (fd=fd@entry=300, buf=buf@entry=0x7f6042880600, n=n@entry=5, flags=-1, flags@entry=258) at ../sysdeps/unix/sysv/linux/x86_64/recv.c:33
2015-06-05 11:12 [Bug libc/18493] New: Infinite loop/deadlock? in __libc_recv (fd=fd@entry=300, buf=buf@entry=0x7f6042880600, n=n@entry=5, flags=-1, flags@entry=258) at ../sysdeps/unix/sysv/linux/x86_64/recv.c:33 dan at censornet dot com
2015-06-05 11:13 ` [Bug libc/18493] " dan at censornet dot com
@ 2015-06-05 11:17 ` dan at censornet dot com
2015-06-05 11:44 ` schwab@linux-m68k.org
` (6 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: dan at censornet dot com @ 2015-06-05 11:17 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=18493
--- Comment #1 from Dan Searle <dan at censornet dot com> ---
Typo, original: "I've even tried adding a poll() call for POLLRDNORM on the
socket before calling recv() with MSG_PEEK | MSG_WAITALL flags to try to make
sure there's data available on the socket before calling poll(), but it makes
no difference."
Should have been: "I've even tried adding a poll() call for POLLRDNORM on the
socket before calling recv() with MSG_PEEK | MSG_WAITALL flags to try to make
sure there's data available on the socket before calling *recv()*, but it makes
no difference."
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug libc/18493] Infinite loop/deadlock? in __libc_recv (fd=fd@entry=300, buf=buf@entry=0x7f6042880600, n=n@entry=5, flags=-1, flags@entry=258) at ../sysdeps/unix/sysv/linux/x86_64/recv.c:33
2015-06-05 11:12 [Bug libc/18493] New: Infinite loop/deadlock? in __libc_recv (fd=fd@entry=300, buf=buf@entry=0x7f6042880600, n=n@entry=5, flags=-1, flags@entry=258) at ../sysdeps/unix/sysv/linux/x86_64/recv.c:33 dan at censornet dot com
2015-06-05 11:13 ` [Bug libc/18493] " dan at censornet dot com
2015-06-05 11:17 ` dan at censornet dot com
@ 2015-06-05 11:44 ` schwab@linux-m68k.org
2015-06-05 11:52 ` dan at censornet dot com
` (5 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: schwab@linux-m68k.org @ 2015-06-05 11:44 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=18493
Andreas Schwab <schwab@linux-m68k.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |MOVED
--- Comment #2 from Andreas Schwab <schwab@linux-m68k.org> ---
The __libc_recv function is just a thin wrapper around the recvfrom system
call. Please report this to the kernel people.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug libc/18493] Infinite loop/deadlock? in __libc_recv (fd=fd@entry=300, buf=buf@entry=0x7f6042880600, n=n@entry=5, flags=-1, flags@entry=258) at ../sysdeps/unix/sysv/linux/x86_64/recv.c:33
2015-06-05 11:12 [Bug libc/18493] New: Infinite loop/deadlock? in __libc_recv (fd=fd@entry=300, buf=buf@entry=0x7f6042880600, n=n@entry=5, flags=-1, flags@entry=258) at ../sysdeps/unix/sysv/linux/x86_64/recv.c:33 dan at censornet dot com
` (2 preceding siblings ...)
2015-06-05 11:44 ` schwab@linux-m68k.org
@ 2015-06-05 11:52 ` dan at censornet dot com
2015-06-10 14:00 ` fweimer at redhat dot com
` (4 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: dan at censornet dot com @ 2015-06-05 11:52 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=18493
--- Comment #3 from Dan Searle <dan at censornet dot com> ---
by "kernel people", you mean https://bugzilla.kernel.org/ ?
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug libc/18493] Infinite loop/deadlock? in __libc_recv (fd=fd@entry=300, buf=buf@entry=0x7f6042880600, n=n@entry=5, flags=-1, flags@entry=258) at ../sysdeps/unix/sysv/linux/x86_64/recv.c:33
2015-06-05 11:12 [Bug libc/18493] New: Infinite loop/deadlock? in __libc_recv (fd=fd@entry=300, buf=buf@entry=0x7f6042880600, n=n@entry=5, flags=-1, flags@entry=258) at ../sysdeps/unix/sysv/linux/x86_64/recv.c:33 dan at censornet dot com
` (3 preceding siblings ...)
2015-06-05 11:52 ` dan at censornet dot com
@ 2015-06-10 14:00 ` fweimer at redhat dot com
2015-06-11 8:00 ` dan at censornet dot com
` (3 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: fweimer at redhat dot com @ 2015-06-10 14:00 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=18493
Florian Weimer <fweimer at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |fweimer at redhat dot com
--- Comment #4 from Florian Weimer <fweimer at redhat dot com> ---
(In reply to Dan Searle from comment #3)
> by "kernel people", you mean https://bugzilla.kernel.org/ ?
More like one of the mailing lists, either linux-kernel or netdev. You will
need to provide a proper test case, though. It's also not quite clear what you
mean by “the threads lock up chewing as much CPU as they can”. Does recv
actually return from the kernel?
--
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-28492-listarch-glibc-bugs=sources.redhat.com@sourceware.org Wed Jun 10 18:43:36 2015
Return-Path: <glibc-bugs-return-28492-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 119315 invoked by alias); 10 Jun 2015 18:43:36 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 119284 invoked by uid 48); 10 Jun 2015 18:43:32 -0000
From: "carlos at redhat dot com" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug build/18512] make install failure with overridden prefix
Date: Wed, 10 Jun 2015 18:43:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: build
X-Bugzilla-Version: 2.21
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: carlos at redhat dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: security-
X-Bugzilla-Changed-Fields:
Message-ID: <bug-18512-131-IeKcS7UJJx@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-18512-131@http.sourceware.org/bugzilla/>
References: <bug-18512-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-06/txt/msg00103.txt.bz2
Content-length: 1352
https://sourceware.org/bugzilla/show_bug.cgi?id\x18512
--- Comment #1 from Carlos O'Donell <carlos at redhat dot com> ---
(In reply to Martin Sebor from comment #0)
> Attempting to install glibc configured with --prefix=/usr into a
> non-standard directory specified by the prefix make variable fails with the
> error below:
>
> $ /src/glibc-trunk/configure --prefix=/usr
> ...
> $ nice make install prefix=/build/glibc-trunk-install-prefix-override-usr
> make[3]: Leaving directory `/src/glibc-trunk/elf'
> /usr/bin/install -c /build/glibc-trunk/elf/ld.so /lib64/ld-2.21.90.so.new
> /usr/bin/install: cannot create regular file '/lib64/ld-2.21.90.so.new':
> Permission denied
> make[2]: *** [/lib64/ld-2.21.90.so] Error 1
> make[2]: Leaving directory `/src/glibc-trunk/elf'
> make[1]: *** [elf/ldso_install] Error 2
> make[1]: Leaving directory `/src/glibc-trunk'
> make: *** [install] Error 2
>
> However, with glibc configured with a different prefix the same installation
> succeeds.
>
> (Setting the DESTDIR variable works as one would expect.)
This is an unsupported use case.
The prefix is a part of the ABI for glibc, and you can't change it at install
time, only at configure time.
My preference would be to have it error out that you've changed the prefix.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug libc/18493] Infinite loop/deadlock? in __libc_recv (fd=fd@entry=300, buf=buf@entry=0x7f6042880600, n=n@entry=5, flags=-1, flags@entry=258) at ../sysdeps/unix/sysv/linux/x86_64/recv.c:33
2015-06-05 11:12 [Bug libc/18493] New: Infinite loop/deadlock? in __libc_recv (fd=fd@entry=300, buf=buf@entry=0x7f6042880600, n=n@entry=5, flags=-1, flags@entry=258) at ../sysdeps/unix/sysv/linux/x86_64/recv.c:33 dan at censornet dot com
` (4 preceding siblings ...)
2015-06-10 14:00 ` fweimer at redhat dot com
@ 2015-06-11 8:00 ` dan at censornet dot com
2015-06-11 8:07 ` fweimer at redhat dot com
` (2 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: dan at censornet dot com @ 2015-06-11 8:00 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=18493
--- Comment #5 from Dan Searle <dan at censornet dot com> ---
There is a tracker for this bug with a test case here:
https://bugzilla.redhat.com/show_bug.cgi?id=1205258
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug libc/18493] Infinite loop/deadlock? in __libc_recv (fd=fd@entry=300, buf=buf@entry=0x7f6042880600, n=n@entry=5, flags=-1, flags@entry=258) at ../sysdeps/unix/sysv/linux/x86_64/recv.c:33
2015-06-05 11:12 [Bug libc/18493] New: Infinite loop/deadlock? in __libc_recv (fd=fd@entry=300, buf=buf@entry=0x7f6042880600, n=n@entry=5, flags=-1, flags@entry=258) at ../sysdeps/unix/sysv/linux/x86_64/recv.c:33 dan at censornet dot com
` (5 preceding siblings ...)
2015-06-11 8:00 ` dan at censornet dot com
@ 2015-06-11 8:07 ` fweimer at redhat dot com
2015-06-11 8:08 ` fweimer at redhat dot com
2015-06-11 8:15 ` dan at censornet dot com
8 siblings, 0 replies; 10+ messages in thread
From: fweimer at redhat dot com @ 2015-06-11 8:07 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=18493
Florian Weimer <fweimer at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
See Also| |https://bugzilla.redhat.com
| |/show_bug.cgi?id=1205258
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug libc/18493] Infinite loop/deadlock? in __libc_recv (fd=fd@entry=300, buf=buf@entry=0x7f6042880600, n=n@entry=5, flags=-1, flags@entry=258) at ../sysdeps/unix/sysv/linux/x86_64/recv.c:33
2015-06-05 11:12 [Bug libc/18493] New: Infinite loop/deadlock? in __libc_recv (fd=fd@entry=300, buf=buf@entry=0x7f6042880600, n=n@entry=5, flags=-1, flags@entry=258) at ../sysdeps/unix/sysv/linux/x86_64/recv.c:33 dan at censornet dot com
` (6 preceding siblings ...)
2015-06-11 8:07 ` fweimer at redhat dot com
@ 2015-06-11 8:08 ` fweimer at redhat dot com
2015-06-11 8:15 ` dan at censornet dot com
8 siblings, 0 replies; 10+ messages in thread
From: fweimer at redhat dot com @ 2015-06-11 8:08 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=18493
Florian Weimer <fweimer at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
See Also| |https://bugzilla.kernel.org
| |/show_bug.cgi?id=99461
--- Comment #6 from Florian Weimer <fweimer at redhat dot com> ---
(In reply to Dan Searle from comment #5)
> There is a tracker for this bug with a test case here:
> https://bugzilla.redhat.com/show_bug.cgi?id=1205258
Also <https://bugzilla.kernel.org/show_bug.cgi?id=99461>. This clearly is a
kernel bug.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug libc/18493] Infinite loop/deadlock? in __libc_recv (fd=fd@entry=300, buf=buf@entry=0x7f6042880600, n=n@entry=5, flags=-1, flags@entry=258) at ../sysdeps/unix/sysv/linux/x86_64/recv.c:33
2015-06-05 11:12 [Bug libc/18493] New: Infinite loop/deadlock? in __libc_recv (fd=fd@entry=300, buf=buf@entry=0x7f6042880600, n=n@entry=5, flags=-1, flags@entry=258) at ../sysdeps/unix/sysv/linux/x86_64/recv.c:33 dan at censornet dot com
` (7 preceding siblings ...)
2015-06-11 8:08 ` fweimer at redhat dot com
@ 2015-06-11 8:15 ` dan at censornet dot com
8 siblings, 0 replies; 10+ messages in thread
From: dan at censornet dot com @ 2015-06-11 8:15 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=18493
--- Comment #7 from Dan Searle <dan at censornet dot com> ---
Agreed, it's a kernel bug, it doesn't handle symultanious use of both MSG_PEEK
and MSG_WAITALL flags in recvfrom SYSCALL in certain edge case(s).
I have worked around the issue for now by not using MSG_WAITALL (while still
using MSG_PEEK) with an outer loop around recv() with a sleep() and a counter
to retry the recv() call a set number of times before timing out.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 10+ messages in thread