> I think I found my defect: my old stress tests was based on doing
> compression/encryptions/decryption/decompression passes on files of random
> sizes; so I would do about a 10 million passes or so and say...that's pretty
> good.
>
> Well...a more structured test exposed the problem and it was this:
>
> The feof() does return true until you attempt to read PAST the end of a
> file. So the code worked great until the file's length was a multiple of the
> buffer size (in my case 262,144 bytes). As you can imagine that doesn't
> happen too often in the real world.
>
> Since I assumed that a feof would return true where there wasn't any more
> data in the file, I would start another pass at reading a chunk of data
> (which wouldn't find anything) and run thru the compression/encryption code.
> The compression code worked handled it correctly, but the encryption
> required that a DWORD boundary (blowfish) and since 0 is on such a boundary
> but at the wrong end...it would fail.
>
But was causing the DB to be corrupt, but a dump to work fine?
What structure was getting damaged?
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
