[Bug 1179281] Re: Data corruption with eglibc 2.17
Julian Taylor
jtaylor.debian at googlemail.com
Sun May 12 19:40:06 UTC 2013
I have uploaded the fix, thanks for the patch
** Changed in: s3ql (Ubuntu Raring)
Assignee: Julian Taylor (jtaylor) => (unassigned)
--
You received this bug notification because you are a member of Ubuntu
Sponsors Team, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1179281
Title:
Data corruption with eglibc 2.17
Status in “s3ql” package in Ubuntu:
Fix Released
Status in “s3ql” source package in Raring:
New
Status in “s3ql” package in Debian:
Unknown
Bug description:
[Impact]
The S3QL package in raring destroys user data.
There is a bug in src/s3ql/_deltadump.pyx, which repositions a file descriptor associated with a FILE* stream without first calling
fflush(). When using eglibc 2.17, this means that s3ql will store malformed metadata that cannot be loaded again (with prior eglibc versions the bug does not appear, which is probably why it hasn't been found until now).
The problem is made worse because this affects only the metadata
uploaded to the remote server, but not the locally cached copy. So
unless the user explicitly tests reloading the metadata from the
server, the corruption will not show up until it's too late.
The attached patch fixes the problem by adding the missing fflush()
call.
[Test Case]
* The bug is detected by S3QL unit tests, so running "setup.py test"
will fail with
$ ./setup.py test
[...]
======================================================================
ERROR: test_1_vals_1 (__main__.DumpTests)
----------------------------------------------------------------------
Traceback (most recent call last):
File "t1_dump.py", line 36, in test_1_vals_1
self.compare_tables(self.src, self.dst)
File "t1_dump.py", line 155, in compare_tables
(id2, buf2) = i2.next()
File "/usr/lib/s3ql/s3ql/database.py", line 250, in next
for col in self.cur.next() ]
StopIteration
The unit tests are run automatically by debian/rules. This bug only
made it into the release because (presumably) S3QL was build before
eglibc was updated to 2.17.
[Regression Potential]
* The patch effects the writing and reading of data from a binary
dump file into an SQLite database. Any regression would thus be
restricted to the initial reading, or final dumping of the data. While
this makes testing easier, it also means that any regressions will
probably make the entire program unusable.
[Other Info]
* The same patch has already been applied to the S3QL 1.11 debian
package.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/s3ql/+bug/1179281/+subscriptions
More information about the Ubuntu-sponsors
mailing list