Glibc change exposing bugs

Posted Nov 10, 2010 20:56 UTC (Wed) by clugstj (subscriber, #4020)
In reply to: Glibc change exposing bugs by corbet
Parent article: Glibc change exposing bugs

Even if there isn't currently-demonstrable benefit, there could be in the future, so why not get the buggy code fixed now instead of later? Yes, it's a very fine line, but, just my opinion, I don't have a problem w/ GlibC not reverting the change.

Glibc change exposing bugs

Posted Nov 10, 2010 22:24 UTC (Wed) by lmb (subscriber, #39048) [Link] (6 responses)

Because the user whose data has just been corrupted or whose important business meeting presentation just crashed or whose mail has been eaten no longer cares, and has switched to a less hostile platform.

That behavior is undefined makes one only right as far as technicality is concerned; it does not imply that changing it silently is good software engineering practice, nor that it is right in terms of software providing a service to users.

Glibc change exposing bugs

Posted Nov 10, 2010 23:58 UTC (Wed) by nix (subscriber, #2304) [Link] (4 responses)

But the compiler makes undefined stuff break all the time, and the set of undefined stuff which is broken is changed by all sorts of things. Nobody complained when LTO came in, although it surely broke programs relying on numerous instances of undefined behaviour which had been harmless before due to wider optimization opportunities when optimizing across translation units. So why complain about this? Just because Flash was affected?

Glibc change exposing bugs

Posted Nov 11, 2010 2:29 UTC (Thu) by foom (subscriber, #14868) [Link] (3 responses)

Because changes in the compiler don't break already-installed working binaries. They break newly compiled versions of software. Presumably such newly-compiled software gets tested, and if there's a problem, the program is perhaps recompiled with an older version of the compiler until the issue is fixed.

Glibc change exposing bugs

Posted Nov 11, 2010 7:29 UTC (Thu) by nix (subscriber, #2304) [Link] (2 responses)

That's a very large assumption indeed. When glibc gets recompiled, is everything on the distro tested? When libpng gets recompiled (every other week), is everything that uses it tested? I doubt it.

Glibc change exposing bugs

Posted Nov 11, 2010 17:30 UTC (Thu) by foom (subscriber, #14868) [Link] (1 responses)

Shrug, yet still, even if it was only discovered sometime later...if there was a bug in the new libpng binary that only appeared because it was compiled with a new gcc, it's still a bug in the new libpng binary that can be fixed by uploading yet another new libpng binary.

Here we have a new bug in flash which appeared without a new version of the flash binary being uploaded. It's a substantively different situation.

Glibc change exposing bugs

Posted Nov 12, 2010 7:12 UTC (Fri) by hozelda (guest, #19341) [Link]

If you update your libpng then the corruption already happened just as if you update glibc. [But the odds grow problems will arise when you update glibc because of its vast use]

If you are that worried, you should work off stable versions or off a stable distributor that will manage this for you. You should not change key parts of the system if possible. glibc is a very key part. You should not update for optimizations, at least not without significant tests and only if you think it's worthwhile the gains. Stick to security updates or when a crucial problem has been solved.

Anyway, when an important "bug" like this comes up, projects should audit the code. In this case, the possible entry points to potential problems can be identified quickly for many projects (just search for memcpy).

The case of glibc involves well-defined standards. Most libraries do not have such carefully defined semantics, and we must rely on access to source code for the juicy bits.

OK, despite what I just said, if the gains here are not that useful, glibc should revert, at least for the time being. Reverting should not hurt those that adjusted already and will save those that have not. On the other hand, when will be the right time to change? Will people remember to fix this problem or will we just have a repeat later on? [Again, if the gains are negligible, the change in glibc should probably be avoided.]

Glibc change exposing bugs

Posted Nov 11, 2010 0:50 UTC (Thu) by MattPerry (guest, #46341) [Link]

> That behavior is undefined makes one only right as far as technicality
> is concerned;

But it is defined. The man page says not to use that function on overlapping regions. That applications ignored that and still functioned for so long is more a matter of good luck. That luck has run out due to their poor implementations and they should now be fixed.

Glibc change exposing bugs

Posted Nov 11, 2010 1:15 UTC (Thu) by Lovechild (guest, #3592) [Link]

Perhaps if somehow one could get it to emit a warning message instead of crashing that might work. For now it might be best done in testing environments such as being enabled perhaps during the development cycle of a distribution.