This is the mail archive of the libc-help@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]

Re: _IO_vfscanf calling realloc


Thanks for the prompt response. So just to clarify:

PRE 2.15
    no call made to any allocation function

2.15
    realloc call introduced

2.16
    realloc call changed to either realloc/alloca depending on size of
workspace needed

-Dave

On Tue, May 15, 2012 at 12:13 PM, Carlos O'Donell
<carlos@systemhalted.org> wrote:
> On Tue, May 15, 2012 at 11:58 AM, David Chappelle <chappedm@gmail.com> wrote:
>> Hello,
>>
>> I am the maintainer of gperftools and have received a few issue
>> submissions recently regarding deadlocks due to _IO_vfscanf calling
>> realloc.
>>
>> http://code.google.com/p/gperftools/issues/detail?id=428
>>
>> This tells me that _IO_vfscanf in the past did not make a call to
>> realloc since this deadlock would have surfaced many years ago. I am
>> curious in which version GNU libc changed _IO_vfscanf to depend on
>> realloc. I am also curious if there is any way to get around this call
>> being made to realloc.
>
> In 2011-09-09 we added realloc to _IO_vfscanf. This change had a
> defect which caused realloc to *always* be used regardless of
> allocation size. This change is in 2.15.
>
> In 2012-01-09 we fixed up the bug and thus after 2.16 releases you'll
> be either using alloca or realloc depending on the size of the
> workspace needed by the function.
>
> At present you can't avoid the allocation.
>
> Does that answer your question?
>
> Cheers,
> Carlos.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]