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 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.

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.  (It's not clear to me whether
there is a group of binaries which do in fact call longjmp and were
previously working due to some quirk of ordering but are now also being
prevented from loading.)

It's slightly debatable which is worse.  The code as it stands today
certainly gives a more meaningful error message (rather than just
branching to address zero) and the corrective action that it suggests,
although not perfect, probably would indeed work around the bug in at
least most cases.  But on the other hand, there do appear to be at
least some programs which were not in fact crashing before and are now
unusable, so this is a functional regression.

One common library that contains relocations against longjmp() but does
not link with libpthread is libpng.  As far as I can tell any
multithreaded library which links itself with libpng is liable to run
into this problem with the code as it stands.

p.


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