search for: end_n

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...***

...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.

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. H...

...ULL, MTX_SPIN | MTX_NOPROFILE); +} +/* + * Xen PV DELAY function + * + * When running on PVH mode we don''t have an emulated i8524, so + * make use of the Xen time info in order to code a simple DELAY + * function that can be used during early boot. + */ +void xen_delay(int n) +{ + uint64_t end_ns; + uint64_t current; + + end_ns = xen_fetch_vcpu_time(&HYPERVISOR_shared_info->vcpu_info[0]); + end_ns += n * NSEC_IN_USEC; + + for (;;) { + current = xen_fetch_vcpu_time(&HYPERVISOR_shared_info->vcpu_info[0]); + if (current >= end_ns) + break; + } +} + static device_method_t...