public inbox for glibc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug malloc/16641] New: feature request: add process/size details to memory error messages
@ 2014-02-26 20:35 pchilcot at cisco dot com
2014-02-27 17:35 ` [Bug malloc/16641] " pchilcot at cisco dot com
` (5 more replies)
0 siblings, 6 replies; 7+ messages in thread
From: pchilcot at cisco dot com @ 2014-02-26 20:35 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=16641
Bug ID: 16641
Summary: feature request: add process/size details to memory
error messages
Product: glibc
Version: unspecified
Status: NEW
Severity: enhancement
Priority: P2
Component: malloc
Assignee: unassigned at sourceware dot org
Reporter: pchilcot at cisco dot com
A google search shows many documented cases of errors like:
mmap: Cannot allocate memory
On a real production system with lots of running processes, it can be very
difficult to pinpoint which process to troubleshoot with the above error. It
would be very valuable to our troubleshooting errors to give a clue about which
process is involved and how much memory they are trying to allocate. This
doesn't necessarily apply only to mmap, but perhaps any ENOMEM related error.
Any improvement, I think, will help users of glibc for troubleshooting.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug malloc/16641] feature request: add process/size details to memory error messages
2014-02-26 20:35 [Bug malloc/16641] New: feature request: add process/size details to memory error messages pchilcot at cisco dot com
@ 2014-02-27 17:35 ` pchilcot at cisco dot com
2014-02-28 1:36 ` bugdal at aerifal dot cx
` (4 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: pchilcot at cisco dot com @ 2014-02-27 17:35 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=16641
Preston Chilcote <pchilcot at cisco dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |pchilcot at cisco dot com
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug malloc/16641] feature request: add process/size details to memory error messages
2014-02-26 20:35 [Bug malloc/16641] New: feature request: add process/size details to memory error messages pchilcot at cisco dot com
2014-02-27 17:35 ` [Bug malloc/16641] " pchilcot at cisco dot com
@ 2014-02-28 1:36 ` bugdal at aerifal dot cx
2014-02-28 17:48 ` pchilcot at cisco dot com
` (3 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: bugdal at aerifal dot cx @ 2014-02-28 1:36 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=16641
Rich Felker <bugdal at aerifal dot cx> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |bugdal at aerifal dot cx
--- Comment #1 from Rich Felker <bugdal at aerifal dot cx> ---
I don't think this message is printed by glibc. It's an application calling
perror("mmap"), whose output is ending up in a log that doesn't indicate the
application/process that produced the message. The only way glibc could make
any difference here is by including in strerror output lots of details about
the caller; this seems highly inappropriate.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug malloc/16641] feature request: add process/size details to memory error messages
2014-02-26 20:35 [Bug malloc/16641] New: feature request: add process/size details to memory error messages pchilcot at cisco dot com
2014-02-27 17:35 ` [Bug malloc/16641] " pchilcot at cisco dot com
2014-02-28 1:36 ` bugdal at aerifal dot cx
@ 2014-02-28 17:48 ` pchilcot at cisco dot com
2014-02-28 18:10 ` bugdal at aerifal dot cx
` (2 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: pchilcot at cisco dot com @ 2014-02-28 17:48 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=16641
--- Comment #2 from Preston Chilcote <pchilcot at cisco dot com> ---
Thanks Rich. If the application wanted more information, then I think glibc
would have to provide it somehow right? Just passing ENOMEM around as a return
value seems to be of minimal value to me in terms of troubleshooting.
I don't think it's reasonable for glibc to pass "lots of details" either. But
do you think there is a reasonable middle ground that wouldn't impact
performance?
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug malloc/16641] feature request: add process/size details to memory error messages
2014-02-26 20:35 [Bug malloc/16641] New: feature request: add process/size details to memory error messages pchilcot at cisco dot com
` (2 preceding siblings ...)
2014-02-28 17:48 ` pchilcot at cisco dot com
@ 2014-02-28 18:10 ` bugdal at aerifal dot cx
2014-03-11 20:42 ` pchilcot at cisco dot com
2014-06-13 6:45 ` fweimer at redhat dot com
5 siblings, 0 replies; 7+ messages in thread
From: bugdal at aerifal dot cx @ 2014-02-28 18:10 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=16641
--- Comment #3 from Rich Felker <bugdal at aerifal dot cx> ---
In that case, I believe this issue report is a duplicate of an old one where
this topic was discussed in detail. I don't know the issue number right off;
perhaps someone else can find it.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug malloc/16641] feature request: add process/size details to memory error messages
2014-02-26 20:35 [Bug malloc/16641] New: feature request: add process/size details to memory error messages pchilcot at cisco dot com
` (3 preceding siblings ...)
2014-02-28 18:10 ` bugdal at aerifal dot cx
@ 2014-03-11 20:42 ` pchilcot at cisco dot com
2014-06-13 6:45 ` fweimer at redhat dot com
5 siblings, 0 replies; 7+ messages in thread
From: pchilcot at cisco dot com @ 2014-03-11 20:42 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=16641
--- Comment #4 from Preston Chilcote <pchilcot at cisco dot com> ---
I've googled ENOMEM, glibc, \x10Rich Felker in every permutation but can't find a
thread about this issue. I'm very interested in reading it if anyone can find
that discussion.
--
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-21884-listarch-glibc-bugs=sources.redhat.com@sourceware.org Tue Mar 11 22:11:34 2014
Return-Path: <glibc-bugs-return-21884-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 14306 invoked by alias); 11 Mar 2014 22:11:34 -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 14251 invoked by uid 48); 11 Mar 2014 22:11:28 -0000
From: "jdthood at gmail dot com" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug network/15726] getaddrinfo() returns incorrect status
Date: Tue, 11 Mar 2014 22:11:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: network
X-Bugzilla-Version: 2.17
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jdthood at gmail dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-15726-131-mZO8M504vD@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-15726-131@http.sourceware.org/bugzilla/>
References: <bug-15726-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: 2014-03/txt/msg00075.txt.bz2
Content-length: 1303
https://sourceware.org/bugzilla/show_bug.cgi?id\x15726
--- Comment #32 from Thomas Hood <jdthood at gmail dot com> ---
>From the point of view of the user of getaddrinfo() it is mainly going to be
important to distinguish the following three outcomes of the getaddrinfo()
call.
A. Success => Go ahead and use the returned address
B. Temporary failure => Retry
C. Permanent failure => Abort
Although there is ambiguity in the specs, variability in the implementations
and lack of consensus in this discussion, am I right in saying that it is
correct to program the application as follows?
0 => Success => Go ahead and use the returned address
EAI_AGAIN => Temporary failure => Retry
EAI_FAIL | EAI_NONAME => Permanent failure => Abort
With reference to the last line: EAI_FAIL is explicitly specified to indicate a
permanent failure. The "bad parameters" cause of EAI_NONAME is also a permanent
failure. And whether it should result in EAI_FAIL or EAI_NONAME or EAI_NODATA,
the absence of the hostname from the name service or absence of addresses for
that hostname in the name service is also a permanent condition which can be
regarded as a permanent failure to obtain an address for that name.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug malloc/16641] feature request: add process/size details to memory error messages
2014-02-26 20:35 [Bug malloc/16641] New: feature request: add process/size details to memory error messages pchilcot at cisco dot com
` (4 preceding siblings ...)
2014-03-11 20:42 ` pchilcot at cisco dot com
@ 2014-06-13 6:45 ` fweimer at redhat dot com
5 siblings, 0 replies; 7+ messages in thread
From: fweimer at redhat dot com @ 2014-06-13 6:45 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=16641
Florian Weimer <fweimer at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
CC| |fweimer at redhat dot com
Resolution|--- |WONTFIX
Flags| |security-
--- Comment #5 from Florian Weimer <fweimer at redhat dot com> ---
See Comment #1: glibc does not print this messages (and it does not generally
abort on ENOMEM), and it cannot change application error messages.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2014-06-13 6:45 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-02-26 20:35 [Bug malloc/16641] New: feature request: add process/size details to memory error messages pchilcot at cisco dot com
2014-02-27 17:35 ` [Bug malloc/16641] " pchilcot at cisco dot com
2014-02-28 1:36 ` bugdal at aerifal dot cx
2014-02-28 17:48 ` pchilcot at cisco dot com
2014-02-28 18:10 ` bugdal at aerifal dot cx
2014-03-11 20:42 ` pchilcot at cisco dot com
2014-06-13 6:45 ` fweimer at redhat dot com
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).