This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
Hi OndÅej, Thanks for prompt answer. I've forgot to attach my libc version:GNU C Library (Ubuntu EGLIBC 2.13-0ubuntu13) stable release version 2.13, by Roland McGrath et al.
Copyright (C) 2011 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiled by GNU CC version 4.5.2. Compiled on a Linux 2.6.38 system on 2011-04-11. Available extensions: crypt add-on version 2.1 by Michael Glad and others GNU Libidn by Simon Josefsson Native POSIX Threads Library by Ulrich Drepper et al BIND-8.2.3-T5B libc ABIs: UNIQUE IFUNCAnyway, I am seeing several additional problems with getaddrinfo_a in this version:
1. Documentation says: "The gai_cancel() function cancels the request req. If the request has been canceled successfully, the error status of the request will be set to EAI_CANCELLED and normal asynchronous notification will be performed." What I see in the reality is that no async notification is performed in this case.
2. There are memory leaks, as mentioned above.3. Documentation mentioned EAI_CANCELLED and EAI_NOTCANCELLED whereas header files define EAI_CANCELED and EAI_NOTCANCELED.
So, my overall question is: Given the above, is getaddrinfo_a considered an unstable/experimental functionality that I should not even try to use? Or is it that I am using an old version of the library and getaddrinfo_a in new versions should actually work as expected?
Martin On 2013-05-31 10:49, OndÅej BÃlka wrote:
On Fri, May 31, 2013 at 10:27:51AM +0200, Martin Sustrik wrote:Hi all, Just a quick question: Is getaddrinfo_a supposed to leak memory?It should not.When run with valgrind following leaks are reported: ==1959== 3,200 bytes in 50 blocks are definitely lost in loss record 3 of 4 ==1959== at 0x4C28FAC: malloc (vg_replace_malloc.c:236) ==1959== by 0x573D00E: gaih_inet (getaddrinfo.c:1001)Code at line 1001 is following which is out of sync with info above. malloc_canonbuf = true; } char *s; if (DL_CALL_FCT (cfct, (at->name ?: name, canonbuf, max_fqdn_len, &s, &rc, &herrno)) == NSS_STATUS_SUCCESS)==1959== by 0x57406B1: getaddrinfo (getaddrinfo.c:2161) ==1959== by 0x5262ED8: handle_requests (gai_misc.c:321) ==1959== by 0x546CD8B: start_thread (pthread_create.c:304) ==1959== by 0x576A04C: clone (clone.S:112) ==1959== ==1959== 5,200 bytes in 50 blocks are possibly lost in loss record 4 of 4 ==1959== at 0x4C28FAC: malloc (vg_replace_malloc.c:236) ==1959== by 0x5263C08: getaddrinfo_a (getaddrinfo_a.c:150) ==1959== my application stack follows here Thanks! Martin
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |