Recent Features
| |||||||||||||
On breaking thingsOn breaking thingsPosted Nov 26, 2010 20:22 UTC (Fri) by dlang (✭ supporter ✭, #313)In reply to: On breaking things by oak Parent article: On breaking things
Valgrind will only report the problem if the particular run of the program happens to produce overlapping regions.
If the work is something like defragmenting memory by moving things around, it's very possible for one particular run to not have overlaps, but another run to have overlaps. Any time you have the pointers calculated in the program, you have a case where they may or may not overlap on a particular run.
and while you are chastising Adobe for not having tested with Valgrind, make sure you chastise everyone else (including glibc maintainers) for the same thing.
this is unfortunantly a very easy mistake to make, and unless a change like this is made, it's unlikely to some to light.
(Log in to post comments)
On breaking things Posted Nov 26, 2010 20:46 UTC (Fri) by jengelh (subscriber, #33263) [Link]
Well if this many users run into the problem that have, surely the chance for Adobe employess would be reasonably high to encounter it too at least once.
On breaking things Posted Nov 26, 2010 21:01 UTC (Fri) by mrshiny (subscriber, #4266) [Link]
Naturally, now that glibc has changed this bug from hypothetical to actual, the Adobe maintainers will have no problem at all reproducing it. But prior to this change nobody experienced the bug.
On breaking things Posted Nov 26, 2010 21:43 UTC (Fri) by jengelh (subscriber, #33263) [Link]
Which would hint towards Adobe not having run Valgrind. Because, seriously, Youtube is not exactly new nor a small unimportant site.
On breaking things Posted Nov 26, 2010 22:16 UTC (Fri) by oak (guest, #2786) [Link]
> If the work is something like defragmenting memory by moving things around, it's very possible for one particular run to not have overlaps, but another run to have overlaps.
One should of course understand that tools can give only positive proof of bugs existence, not proof of them not existing. Things like running Valgrind (and static checkers) should be part of the development process, so that over SW life time & changes one gets better coverage. It's not some one-off, instantly forgotten thing.
> and while you are chastising Adobe for not having tested with Valgrind, make sure you chastise everyone else (including glibc maintainers) for the same thing.
Sure.
Btw. If calls to a function are within the same library where the function is implemented, function wrappers don't catch that unless it also goes through .plt. And as to Glibc FORTIFY utility, I'm not sure whether Glibc enables that for itself...?
With Duma I've seen also another "issue" in Glibc, memmove() calling memcpy() because it has inherent knowledge about in which direction memcpy() works. Because Duma doesn't have that info, it complains (Duma has now a variable for this)...
|
|||||||||||||