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]

Re: 2.25 freeze status


On Mon, Jan 30, 2017 at 10:55 AM, Carlos O'Donell <carlos@redhat.com> wrote:
> On 01/30/2017 05:48 AM, Florian Weimer wrote:
>> On 01/30/2017 11:25 AM, Phil Blundell wrote:
>>> On Sat, 2017-01-28 at 19:00 -0500, Carlos O'Donell wrote:
>>>>
>>>> Whatever we might think about the seriousness of the issue, it has
>>>> existed
>>>> for 4 or 5 releases and few people have run into it, which means we
>>>> have
>>>> time to fix it i.e. not a blocker.
>>>
>>> That's not an entirely accurate characterisation.  Bug 20019 has indeed
>>> existed for several releases without anybody noticing, but bug 21041 is
>>> new.
>>
>> Phil, thanks for spelling this out explicitly.
>>
>>> The effect of the older bug 20019 is that affected programs would be at
>>> risk of crashing if they called longjmp().  But the effect of the newer
>>> bug 21041 is that such programs cannot start up at all, even if they
>>> never in fact call longjmp() at runtime.
>>
>> I share this concern.
>
> This is enough concern that I now propose we back out the fix for 20019
> until we can find an acceptable fix in glibc 2.26.
>
> H.J.,
>
> Could you please back out the fix for bug 20019?
>
> We will continue to try and fix this in 2.26 with a solution that moves
> IFUNC design towards a better documented set of semantics.
>

Since calling longjmp will segfault in this case, shouldn't it be
fixed first by reverting IFUNC implementation in libpthread?


-- 
H.J.


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