This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: gai_cancel()
- 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: <1497627984.6717.32.camel@pbcl.net> <f23933e1-28fc-f100-5086-8e7de984fb35@redhat.com> <1497870281.6717.37.camel@pbcl.net>
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:
>>> Opinions?
>>
>> Is this related to bug 20874?
>>
>> https://sourceware.org/bugzilla/show_bug.cgi?id=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?
Thanks,
Florian