|
|
Subscribe / Log in / New account

Glibc change exposing bugs

Glibc change exposing bugs

Posted Nov 10, 2010 19:25 UTC (Wed) by brunowolff (guest, #71160)
Parent article: Glibc change exposing bugs

Actually I think we may have first seen this with squashfs. Problems showed up right before the F14 alpha. Phillip found the cause of the problem was using memcpy instead of memmove.


to post comments

Glibc change exposing bugs

Posted Nov 10, 2010 19:52 UTC (Wed) by brunowolff (guest, #71160) [Link] (3 responses)

The bugzilla entry for this issue is: https://bugzilla.redhat.com/show_bug.cgi?id=619020

Glibc change exposing bugs

Posted Nov 11, 2010 4:12 UTC (Thu) by plougher (guest, #21620) [Link] (2 responses)

Thanks Bruno,

The Redhat bugzilla doesn't have a description of the memcpy problem that ultimately caused the bug, but my Squashfs CVS commit does

http://squashfs.cvs.sourceforge.net/viewvc/squashfs/squas...

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.

Glibc change exposing bugs

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

>> where the underlying implementation is not known

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

Glibc change exposing bugs

Posted Nov 26, 2010 13:37 UTC (Fri) by SEJeff (guest, #51588) [Link]

cvs for a filesystem? wow


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds