This is the mail archive of the
mailing list for the glibc project.
- From: Florian Weimer <fweimer at redhat dot com>
- To: Phil Blundell <pb at pbcl dot net>
- Cc: libc-alpha at sourceware dot org
- Date: Mon, 19 Jun 2017 13:51:06 +0200
- Subject: Re: gai_cancel()
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx04.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx04.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=fweimer at redhat dot com
- Dkim-filter: OpenDKIM Filter v2.11.0 mx1.redhat.com C0E8F8047B
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com C0E8F8047B
- References: <email@example.com> <firstname.lastname@example.org> <email@example.com>
On 06/19/2017 01:04 PM, Phil Blundell wrote:
> On Fri, 2017-06-16 at 17:52 +0200, Florian Weimer wrote:
>> On 06/16/2017 05:46 PM, Phil Blundell wrote:
>> Is this related to bug 20874?
> No, I don't think it's related. I poked at that bug a bit and I am
> fairly sure that the problem there is specifically in gai_suspend().
> Under conditions that I don't entirely understand yet, we seem to be
> somehow returning from gai_suspend while its waitlist entry is still
> linked into requestlist->waiting. Since gai_suspend() allocated its
> waitlist on the stack, this leads rapidly to disaster when gai_notify
> subsequently tries to traverse the linked list.
Okay, thanks for investigating.
How does the memory leak happen? Would another notification eventually
deallocate the struct async_waitlist object?