Version: 9ad4e4212152 (reproduced 2026-08-27, macOS/arm64).
Separate from the wav-splicer container-overflow I filed as #83: a 7.1.4 Dolby-mode bed crashes
under the base profile — the only bed in my corpus that crashes under base — and it is a
different fault.
SUMMARY: AddressSanitizer: SEGV vector:529 in
std::__1::vector<std::__1::basic_string<char>>::__destroy_vector::operator()()
AddressSanitizer can not provide additional info.
Same summary on both runs. ASan reports no redzone and no allocation context, which is what a
wild pointer during destruction looks like rather than a heap overflow.
Reproduce
python3 adm_corpus_gen.py ./corpus
bazel build -c dbg --copt=-fsanitize=address --copt=-fno-omit-frame-pointer \
--linkopt=-fsanitize=address //iamf/cli:encoder_main
bazel-bin/iamf/cli/encoder_main --adm_filename=./corpus/dlb_bed_7dot1dot4.wav \
--adm_profile_version=base --output_iamf_directory=./outWhy I think this is separate rather than a duplicate of #83: #83's fault is on the enhanced
path through SeparateLfeAndConvertTo3OA; this one is base, where that conversion is not
reached. The fault class and location differ.
I have not proved independence. The obvious experiment — repair #83 locally, then re-run this
input — is inconclusive, because the repaired build does not complete on the enhanced inputs at
all, so there is no clean before/after to read. I am filing both on the assumption that two
distinct fault classes are worth two reports; if you find they share a root cause, consider this a
belt and suspenders filing for #83.
Version:
9ad4e4212152(reproduced 2026-08-27, macOS/arm64).Separate from the wav-splicer container-overflow I filed as #83: a 7.1.4 Dolby-mode bed crashes
under the
baseprofile — the only bed in my corpus that crashes underbase— and it is adifferent fault.
Same summary on both runs. ASan reports no redzone and no allocation context, which is what a
wild pointer during destruction looks like rather than a heap overflow.
Reproduce
python3 adm_corpus_gen.py ./corpus bazel build -c dbg --copt=-fsanitize=address --copt=-fno-omit-frame-pointer \ --linkopt=-fsanitize=address //iamf/cli:encoder_main bazel-bin/iamf/cli/encoder_main --adm_filename=./corpus/dlb_bed_7dot1dot4.wav \ --adm_profile_version=base --output_iamf_directory=./outWhy I think this is separate rather than a duplicate of #83: #83's fault is on the
enhancedpath through
SeparateLfeAndConvertTo3OA; this one isbase, where that conversion is notreached. The fault class and location differ.
I have not proved independence. The obvious experiment — repair #83 locally, then re-run this
input — is inconclusive, because the repaired build does not complete on the
enhancedinputs atall, so there is no clean before/after to read. I am filing both on the assumption that two
distinct fault classes are worth two reports; if you find they share a root cause, consider this a
belt and suspenders filing for #83.