Recent Features
| |||||||||||||
This isn't either/or. Phase in such changes instead!This isn't either/or. Phase in such changes instead!Posted Nov 17, 2010 15:14 UTC (Wed) by meuh (subscriber, #22042)In reply to: This isn't either/or. Phase in such changes instead! by mrshiny Parent article: Glibc change exposing bugs Remember: this bug exists for all users of glibc even if they compiled their apps a long time ago but recently updated glibc. It's not a bug. And it doesn't affect all users. Hopefully, legitimate uses (regarding to specification) of memcpy() are not affected by the optimisation in newer glibc.
(Log in to post comments)
This isn't either/or. Phase in such changes instead! Posted Nov 17, 2010 15:52 UTC (Wed) by mrshiny (subscriber, #4266) [Link] Yes, it is a bug. Sure, the application is responsible for using APIs properly. But here we have a situation where a library has worked one way for years, and then suddenly works a different way. There was no way for the apps in question to detect the bugs because the code worked perfectly before. Now, due to a library upgrade, those apps don't work. In some cases there is data corruption. The corruption might happen silently. There is no way to be sure that this change is not quietly damaging untold amounts of data without auditing every use of memcpy everywhere to ensure that it is doing the right thing. And this means that not only do you have to fix all source code which is wrong and issue new binaries, but you shouldn't upgrade to this version of Glibc because you might have an app somewhere that wasn't fixed, or isn't fixed in the version you have installed. Glibc is a critical library in the system. Almost every program uses it. As such, it is their responsibility to treat ABI changes very carefully. Sure, this is not a change in the specification, it is an unintended consequence and it's due to those stupid lazy programmers who didn't read the spec or didn't care or whatever. Or inadvertently introduced errors when their code was changed. Or changed something without realizing that this change would result, somewhere, in a call to overlapping memcpy. Given that the bug was hard to identify (at least for some cases), and given that Glibc has symbol versioning, maybe they should use it? Your last sentence sums up the problem: "Hopefully legitimate uses are not affected". I think we should expect stronger guarantees from glibc than "hopefully".
This isn't either/or. Phase in such changes instead! Posted Nov 17, 2010 16:09 UTC (Wed) by meuh (subscriber, #22042) [Link]
Hopefully, every programmer run their programs under valgrind once in a while.
This isn't either/or. Phase in such changes instead! Posted Nov 17, 2010 16:23 UTC (Wed) by xilun (subscriber, #50638) [Link]
> There is no way to be sure that this change is not quietly damaging untold amounts of data without auditing every use of memcpy everywhere to ensure that it is doing the right thing.
There is also no way to be sure that this change is not _fixing_ untold amounts of data corruption when the memcpy is done backward without auditing every use of memcpy :)
> given that Glibc has symbol versioning, maybe they should use it?
Nope. Symbol versioning is for ABI changes, and symbol versioning does not even pretend to automatically solve every problem ABI changes has been shown to cause. The memcpy implementation change is not even an ABI change.
> Your last sentence sums up the problem: "Hopefully legitimate uses are not affected". I think we should expect stronger guarantees from glibc than "hopefully".
There was a problem only in the sentence. The "hopefully" is not needed. Legitimate users of memcpy will not be affected.
|
|||||||||||||