[[!meta copyright="Copyright © 2008, 2009, 2010 Free Software Foundation,
Inc."]]
[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
id="license" text="Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version 1.2 or
any later version published by the Free Software Foundation; with no Invariant
Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license
is included in the section entitled [[GNU Free Documentation
License|/fdl]]."]]"""]]
[[!tag open_issue_hurd]]
Every now and then, new locking issues are discovered in
[[hurd/libdiskfs]] or [[hurd/translator/ext2fs]], for example. Nowadays
these in fact seem to be the most often encountered cause of Hurd crashes
/ lockups.
One of these could be traced
recently, and turned out to be a lock inside [[hurd/libdiskfs]] that was taken
and not released in some cases. There is reason to believe that there are more
faulty paths causing these lockups.
The task is systematically checking the [[hurd/libdiskfs]] code for this kind of locking
issues. To achieve this, some kind of test harness has to be implemented: For
example instrumenting the code to check locking correctness constantly at
runtime. Or implementing a [[unit testing]] framework that explicitly checks
locking in various code paths. (The latter could serve as a template for
implementing unit tests in other parts of the Hurd codebase...)
(A systematic code review would probably suffice to find the existing locking
issues; but it wouldn't document the work in terms of actual code produced, and
thus it's not suitable for a GSoC project...)
This task requires experience with debugging locking issues in multithreaded
applications.
Tools have been written for static code analysis, than can help to locate
and fix such errors.
* Coccinelle
*
*
* clang
*
* Linux' sparse
*