humm.. well a small thing about minor issues.. its the minor issues which if left unchecked can quite easily cause a cascading effect and snow ball out of control. your correct in the fact about this issue being shared across *most* cryptos (but not all) as if you checked Aero-qt-anon-rev2 build this issue was fixed and thus, my previous point about being able to nail down the exact dependency and methods in the code which is the crux of this problem a much easier proposition to tackle as i know how to reproduce and how to test against it.

Unfortunately AM uses a different codebase from AERO codebase not quite its sibling from the pull request of the main AERO branch but very close to the private MASTER branch which is on my machine. This fix never made it into this initial AM release but will find its way in during the next iteration of the AM build. After which point, once confirmed as "fixed" i will submit to the leveldb project as an "issue" have it confirmed as an issue and then apply the fix to the public MASTER AM branch. SO, if this fix is accepted and resolves the issue no more cryptos based of the latest leveldb deps will have this problem well most that exploit leveldb for that matter.

This issue also goes deeper than a simple dependency issue it also has the makings of problematic compile time issues, meaning some of the library's used in the build process do not play nice with gcc 4.2 this is something which again is the result of many inter-processes reliant on shared library resources at compile time built with linux binaries are that are also created using gcc 4.2.. like i said its more than a minor issue. The work-around to this issue may indeed be minor/simple however the issue is not minor nor will be the fix.

FYI: The closest race condition i can reproduce is found in the following git issue tracker which most closely resembles this issue.  https://github.com/google/leveldb/issues/203
It all steams from how the deps use fcntl F_FULLFSYNC when fsync() maybe a better approach.