Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
PostgreSQL 9.3 beta: Federated databases and more
LWN.net Weekly Edition for May 9, 2013
(Nearly) full tickless operation in 3.10
Glibc change exposing bugs
Posted Nov 10, 2010 19:52 UTC (Wed) by brunowolff (guest, #71160)
Posted Nov 11, 2010 4:12 UTC (Thu) by plougher (subscriber, #21620)
The Redhat bugzilla doesn't have a description of the memcpy problem that ultimately caused the bug, but my Squashfs CVS commit does
From my experience hitting this problem I think the people insisting this is merely bad programmers using memcpy where they should have used memmove are missing the point. I quite legitimately wrote code using memcpy where it was known the areas did not overlap, but over the years code changes elsewhere happened which then caused the areas to overlap in certain circumstances, breaking design assumptions made in years old code. This was obviously a bug, but one which hitherto had been completely hidden by the behaviour of memcpy.
In other words programmers can make well meaning mistakes especially when dealing with old code or with library routines where the underlying implementation is not known. Testing with the old behaviour of memcpy won't show anything is amiss.
Flash is obviously an example where memcpy of overlapping areas occurs frequently and so it has shown up quite quickly. There may be many applications using memcpy which in rare circumstances use overlapping areas, leading to unexplained corruption and data loss, which have not yet shown up.
Posted Nov 12, 2010 6:55 UTC (Fri) by hozelda (guest, #19341)
I'm not disagreeing with the gist of what you mentioned, but this does point out that software is very complex in that the exact semantics of every interacting component has compounding effects on the overall result. This is why there is a tendency to code to achieve a pass on tests rather than by strict well defined "interface specs". However, having access to source code and working openly means problems can be identified quicker and shared quicker with other projects. If source code was not available (eg, if the library change had happened on a proprietary platform), finding the mistake would be more difficult and costly and there would be more bugs that would only come out under odd scenarios because thorough testing is impossible and certainly more difficult than analyzing even lots of source code.
An ideal wish: I want to see code assumptions be documented better on source code (assert calls and/or prose), even though we do have access to version control, peer review, and sometimes lots of testing with decent feedback. HTML can be generated from a heavily documented code to exclude all the little comments except when you want to see them (eg, before a final release or for inspection/audits). Trying to keep the source clean makes it easier to end up with problems over time. We would benefit from extensive standards for documentation, and those that like simple tools (like a simple text editor) can run simple filters on the project from the make file so that you can have all those notes not pollute a working copy.
[An extensive test suite designed to catch these problems is similar in effect but will leave holes whereas descriptive text can offer an important layer of defense.]
[Many times when you are (I am) learning a new code base, you have to make these notes anyway. Why not just formalize the effort and keep it together with the other code? We should even be able to have tests run from this documentation. Tagging precise spots can be done using any "unique" delimiter and can take an sgml approach. Then git and other tools can identify "conflicts" not just from 3-way merges with overlaps but from simple edits which overlap with a comment's scope.. triggering a requirement to update the comments whose scope were touched.]
[Another approach would be to try and keep something like a git branch of such comments/tests in sync and require that it be run before accepting commits on the main clean branch.]
[It might just be too much effort to do this in terms of bang for buck. Comments can very easily grow stale, though, that is why I suggested automatic conflict identification efforts within the workflow.]
Posted Nov 26, 2010 13:37 UTC (Fri) by SEJeff (subscriber, #51588)
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds