One more data point: I recompiled aMule 1.2.4 with
--enable-debug --disable-optimise, I'm running it now under gdb,
and I seem to be getting considerably less corruption.
This smells like either a compiler or library problem (*), or some
other data corruption in aMule that only hits vital data under
certain circumstances.
(*) E.g.
https://rhn.redhat.com/errata/RHSA-2003-325.htmSystem configuration:
aMule 1.2.4
wxWindows 2.4.1
GTK 1.2.10
gcc 3.2 20020903 (Red Hat Linux 8.0 3.2-7)
libc 2.2.93
libstdc++ 3.2 (libstdc++.so.5.0.1)
File system ext3
I've added some instrumentation to track the relative frequency of
corruption. Patch attached. (It's for 1.2.4, but is offset by one line,
because of some other changes not relevant to the issue at hand.)
Output so far (that's for about four hours of relatively low traffic,
around Jan 23, 03-07 UTC, with an increase of on-disk data of
about 20-50 MB/h):
bad 1 good 0 ich 0 other 175
bad 2 good 5 ich 0 other 648
bad 3 good 6 ich 0 other 745
bad 4 good 10 ich 0 other 1026
bad 5 good 10 ich 0 other 1040
bad 6 good 10 ich 0 other 1047
(The last three occurred within 5 minutes between "bad 4" and
"bad 6". After that, things were quiet for 30 minutes, at which time
I stopped the test.)
- Werner