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
Martijn van Beurden wrote:> 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 issueApplied. Thanks. Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/
Martijn van Beurden wrote:> 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 issueBy the way, FLAC__window_punchout_tukey() calls FLAC__window_partial_tukey(), not itself. Is it intended? If yes, then probably it's better to add a small comment about this (for future readers).
Martijn van Beurden wrote:> I still wonder how it is possible > that this didn't trigger anything on x86_64?Different memory allocation routines? After all, it's different architectures. Also configure.ac defines FLAC__ALIGN_MALLOC_DATA only for ia32 and x86_64.
Op 14-11-14 om 17:16 schreef lvqcl:> By the way, FLAC__window_punchout_tukey() calls > FLAC__window_partial_tukey(), not itself. Is it intended? If > yes, then probably it's better to add a small comment about > this (for future readers).I feel really bad about not thoroughly checking this code before sending in a patch. I just spotted another mistake, when choosing a tukey p of 1.0 or larger, the function gets stuck in an infinite loop. The patch fixes both. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-libFLAC-fix-more-problems-with-new-window-functions.patch Type: text/x-patch Size: 0 bytes Desc: not available Url : http://lists.xiph.org/pipermail/flac-dev/attachments/20141116/02d138d9/attachment.bin