Crash on initiailizing with AVFoundation backend

[leecbaker]

Using version 0.22.1 on Mac OS 12.4, a crash occurs. Details, and the relevant part of the backtrace are below:

thread '<unnamed>' panicked at 'called `Option::unwrap()` on a `None` value', /Users/lee/.cargo/registry/src/github.com-1ecc6299db9ec823/tts-0.22.1/src/backends/av_foundation.rs:34:90
stack backtrace:
   0: rust_begin_unwind
             at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/std/src/panicking.rs:584:5
   1: core::panicking::panic_fmt
             at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/core/src/panicking.rs:143:14
   2: core::panicking::panic
             at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/core/src/panicking.rs:48:5
   3: core::option::Option<T>::unwrap
             at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/core/src/option.rs:755:21
   4: tts::backends::av_foundation::AvFoundation::new
             at /Users/lee/.cargo/registry/src/github.com-1ecc6299db9ec823/tts-0.22.1/src/backends/av_foundation.rs:34:24
   5: tts::Tts::new
             at /Users/lee/.cargo/registry/src/github.com-1ecc6299db9ec823/tts-0.22.1/src/lib.rs:305:17
   6: tts::Tts::default
             at /Users/lee/.cargo/registry/src/github.com-1ecc6299db9ec823/tts-0.22.1/src/lib.rs:351:17

[leecbaker]

Similar crash with Appkit backend:

thread '<unnamed>' panicked at 'called `Option::unwrap()` on a `None` value', /Users/lee/.cargo/registry/src/github.com-1ecc6299db9ec823/tts-0.22.1/src/backends/appkit.rs:20:83
stack backtrace:
   0: rust_begin_unwind
             at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/std/src/panicking.rs:584:5
   1: core::panicking::panic_fmt
             at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/core/src/panicking.rs:143:14
   2: core::panicking::panic
             at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/core/src/panicking.rs:48:5
   3: core::option::Option<T>::unwrap
             at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/core/src/option.rs:755:21
   4: tts::backends::appkit::AppKit::new
             at /Users/lee/.cargo/registry/src/github.com-1ecc6299db9ec823/tts-0.22.1/src/backends/appkit.rs:20:17
   5: tts::Tts::new
             at /Users/lee/.cargo/registry/src/github.com-1ecc6299db9ec823/tts-0.22.1/src/lib.rs:301:26
   6: <pccommon::speech::SpeechEngineVoice as core::default::Default>::default
             at /Users/lee/projects/project-rs/pccommon/src/speech.rs:29:23

[ndarilek]

Very odd, that unwrap shouldn't be failing, and I can't duplicate this on my 2018 mac mini running `12.4.

If anyone else can duplicate and has insights, they'd be welcome. Apple platforms have been some of the most difficult to support with tts-rs, up to and including dealing with undocumented Apple bugs that only surface in odd configurations I've never been able to pin down, but magically vanish in the macOS 13 beta.

Thanks.

[ndarilek]

V0.22.3, releasing soon, makes this an error rather than a crash. But I can't duplicate it here, and have even gotten assurances that macOS 13 fixes some long-standing bugs in Apple's TTS that this library uncovered, so I'm not sure what else to do.

I'll leave this open in case anyone else experiences it or has a proposed fix, but given that these lines essentially create objc classes, I don't know why they'd fail like this. Sorry about that!

[leecbaker]

Thanks for the quick response! I think I figured out what was causing the crash.

My application inadvertently initialized multiple instances of Tts, and the second instance's initialization seems to be where the problem is. This is pretty simple, and I should have figured this out earlier 😞.

Here's code to reproduce:

use tts::*;

fn main() {
    let tts = Tts::default().unwrap();
    let tts2 = Tts::default().unwrap();
}

Ideally, this is how I think it should work:

• If the backend allows multiple instances, then multiple instances of Tts should be allowed; or
• If the backend doesn't allow multiple instances, an error communicating that limit should be returned from the second and subsequent Tts instantiations.

[ndarilek]

Ideally none of these backends should fail if you need to initialize multiple versions of them. You should just have another instance.

I'd accept a PR fixing this if you could figure it out. TBH, and nothing personal, but I'm really sick of fixing stupid Apple/macOS bugs and writing code in this odd Rust/ObjC hybrid style. I'll only be initializing one instance in my apps for the foreseeable future, and writing any more macOS speech code is pretty far down the list of things I want to be doing.

I'm not even clear on why those lines failed. IIRC they're just creating a generic delegate class, but it seems like that shouldn't just fail if you do it multiple times, especially scoped to separate struct instances. But VoiceOver is a completely different screen reader that I'm not used to using, and Apple won't let me debug over SSH, so I'm pretty much over working with such a hostile system when I don't need to. Sorry.

[leecbaker]

I'd accept a PR fixing this if you could figure it out. TBH, and nothing personal, but I'm really sick of fixing stupid Apple/macOS bugs and writing code in this odd Rust/ObjC hybrid style. I'll only be initializing one instance in my apps for the foreseeable future, and writing any more macOS speech code is pretty far down the list of things I want to be doing.

I totally understand; I have no expectation that you'll fix this bug. I likely won't either, as I intent to only initialize one instance in my application, and this doesn't seem like fun at all.

Hopefully if somebody else runs into a similar problem one day, they'll find this thread helpful.

I greatly appreciate everything that you've done with this library so far. Thanks!