[Bug malloc/16641] New: feature request: add process/size details to memory error messages

[Bug malloc/16641] New: feature request: add process/size details to memory error messages

[pchilcot at cisco dot com]

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.

[Bug malloc/16641] feature request: add process/size details to memory error messages

[pchilcot at cisco dot com]

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.

[Bug malloc/16641] feature request: add process/size details to memory error messages

[bugdal at aerifal dot cx]

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.

[Bug malloc/16641] feature request: add process/size details to memory error messages

[pchilcot at cisco dot com]

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.

[Bug malloc/16641] feature request: add process/size details to memory error messages

[bugdal at aerifal dot cx]

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.

[Bug malloc/16641] feature request: add process/size details to memory error messages

[pchilcot at cisco dot com]

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.

[Bug malloc/16641] feature request: add process/size details to memory error messages

[fweimer at redhat dot com]

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.