Hi, Apparently the new presets are triggering an invalid free in some code. I was running the test suite on ARM, and it gets stuck with small blocksizes.> Testing blocksize variations... > noise8m32 (--channels=1 --bps=8 -8 -p -e -l 0 --lax > --blocksize=16 ): encode...decode...compare...OK > noise8m32 (--channels=1 --bps=8 -8 -p -e -l 1 --lax > --blocksize=16 ): encode...*** Error in > `/home/pi/bin/flac/src/flac/.libs/lt-flac': free(): invalid > pointer: 0x018a41d0 ***This error shows up consistently with blocksizes of 16 and 17, but never with bigger blocksizes. I'm not too familiar with these things, where should I start looking? I haven't been able to reproduce this on x86_64, so using Valgrind is not possible I guess?
Martijn van Beurden <mvanb1 at gmail.com> ?????(?) ? ????? ?????? Thu, 13 Nov 2014 17:47:53 +0300:> Apparently the new presets are triggering an invalid free in > some code. I was running the test suite on ARM, and it gets > stuck with small blocksizes. > >> Testing blocksize variations... >> noise8m32 (--channels=1 --bps=8 -8 -p -e -l 0 --lax >> --blocksize=16 ): encode...decode...compare...OK >> noise8m32 (--channels=1 --bps=8 -8 -p -e -l 1 --lax >> --blocksize=16 ): encode...*** Error in >> `/home/pi/bin/flac/src/flac/.libs/lt-flac': free(): invalid >> pointer: 0x018a41d0 ***FLAC__window_partial_tukey(): Np = (FLAC__int32)(p / 2.0f * N) - 1; and Np can be equal to -1. So later in the code for (; n < (end_n-Np); n++) window[n] = 1.0f; libFLAC writes outside of window[] memory.
On 2014-11-13 6:47 AM, Martijn van Beurden wrote:> I haven't been able to reproduce this on x86_64, so > using Valgrind is not possible I guess?Valgrind does have some armv7 support now, so it's possible to use it to track down these things. -fsanitize=address has some arm support as well. FWIW, -r
Op 13-11-14 om 17:45 schreef lvqcl:> FLAC__window_partial_tukey(): > > Np = (FLAC__int32)(p / 2.0f * N) - 1; > > and Np can be equal to -1. So later in the code > > for (; n < (end_n-Np); n++) > window[n] = 1.0f; > > libFLAC writes outside of window[] memory.That does the trick indeed. I still wonder how it is possible that this didn't trigger anything on x86_64? Now that I've taken a better look, there are a few other problems with that code actually. Here's a patch to fix the issue -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-more-checks-to-partial_tukey-and-punchout_tukey-.patch Type: text/x-patch Size: 0 bytes Desc: not available Url : http://lists.xiph.org/pipermail/flac-dev/attachments/20141113/2a8f3df2/attachment.bin