Re: [Squashfs-devel] unsquashed file doesn't match original

[Bruno W. I. <br...@wo...>]

On Thu, Sep 18, 2014 at 03:55:31 +0100,
  Phillip Lougher <ph...@lo...> wrote:
>
>You should not be getting leaks with Valgrind.  I frequently run Valgrind,
>and in the last release of Mksquashfs/Unsquashfs I removed all the (minor)
>leaks that Valgrind identified - this was part of the massive buffer space
>hardening of the code.

I'll see if they still happen after I apply the race condition patch. And 
if so, that they aren't in a Fedora library.

>==27610== LEAK SUMMARY:
>==27610==    definitely lost: 0 bytes in 0 blocks
>==27610==    indirectly lost: 0 bytes in 0 blocks
>==27610==      possibly lost: 4,352 bytes in 16 blocks
>==27610==    still reachable: 66,263,321 bytes in 13,645 blocks
>==27610==         suppressed: 0 bytes in 0 blocks
>==27610== Rerun with --leak-check=full to see details of leaked memory

Mostly I got something like the above. Occasionally I got numbers other 
than 0 for definitely lost and indirectly lost. I haven't run with 
--leak-check=full yet to see where the problem is reported.

>The failure strongly suggests there is a rare race condition in fragment
>writing in Mksquashfs.  Reviewing the code changes in the latest release
>of Mksquashfs around fragment writing, I discovered I have inadvertently
>put back a race condition fixed in 2009.  This race condition could
>generate the filesystem corruption seen.

Hopefully that was what I was seeing.

>I have pushed the fix to git, and the commit is here:

Thanks I'll try this out over the weekend.

I noticed that the incorrect type patch (for the 2+ GB file issue) hasn't 
shown up in master yet. I just wanted to make sure that it eventually 
made it there, I'm not actually waiting on it.

Thanks.