Bug
chatterbox/models/s3gen/utils/mask.py at line 162 calls logging.warning(...), but the module does not import logging. The safety fixup is dead code that would crash with NameError: name 'logging' is not defined if the all-False chunk_masks edge case ever fires.
Location
src/chatterbox/models/s3gen/utils/mask.py, around line 160-163:
if (chunk_masks.sum(dim=-1) == 0).sum().item() != 0:
logging.warning('get chunk_masks all false at some timestep, force set to true, make sure they are masked in futuer computation!')
chunk_masks[chunk_masks.sum(dim=-1)==0] = True
Suggested fix
Add import logging at the top of mask.py.
Also note: there's a typo in the warning message — futuer should be future. Optional, but might be worth fixing in the same PR.
How we found it
Discovered while doing a CoreML export of Chatterbox Multilingual for an iOS-native voice synthesis project. The if-branch on a data-dependent condition causes torch.export strict-mode to fail with GuardOnDataDependentSymNode. While building a torch.where semantic-equivalent replacement, ran a verification harness comparing upstream vs. refactor across cases where the condition does and does not fire — and the upstream function crashes with NameError instead of the intended warning + fixup behavior when the condition fires.
For typical valid inputs the condition shouldn't fire, so this hasn't caused observable failures in normal use — but a malformed token_len input would produce a confusing NameError instead of either the intended warning or a clean fallback.
Happy to send a PR if helpful.
Bug
chatterbox/models/s3gen/utils/mask.pyat line 162 callslogging.warning(...), but the module does notimport logging. The safety fixup is dead code that would crash withNameError: name 'logging' is not definedif the all-False chunk_masks edge case ever fires.Location
src/chatterbox/models/s3gen/utils/mask.py, around line 160-163:Suggested fix
Add
import loggingat the top ofmask.py.Also note: there's a typo in the warning message —
futuershould befuture. Optional, but might be worth fixing in the same PR.How we found it
Discovered while doing a CoreML export of Chatterbox Multilingual for an iOS-native voice synthesis project. The
if-branch on a data-dependent condition causestorch.exportstrict-mode to fail withGuardOnDataDependentSymNode. While building atorch.wheresemantic-equivalent replacement, ran a verification harness comparing upstream vs. refactor across cases where the condition does and does not fire — and the upstream function crashes withNameErrorinstead of the intended warning + fixup behavior when the condition fires.For typical valid inputs the condition shouldn't fire, so this hasn't caused observable failures in normal use — but a malformed token_len input would produce a confusing
NameErrorinstead of either the intended warning or a clean fallback.Happy to send a PR if helpful.