Currently core dumps under Mac OS X

[SirVer]

$ g log
commit ae3e050dead3005e20720dc610e4f73f38f207da
Merge: e4d4a1e 12d1108
Author: ferris <yupferris@gmail.com>
Date:   Mon Feb 6 01:23:07 2017 +0100

    Merge pull request #12 from bobtwinkles/command-line

    Command line refinement

$ cargo build --release
    Finished release [optimized] target(s) in 0.0 secs

$ target/release/rustual-boy-cli wario.vb
zsh: segmentation fault (core dumped)  target/release/rustual-boy-cli wario.vb

$ shasum wario.vb
274c328fbd904f20e69172ab826bf8f94ced1bdb  wario.vb

A quick git bisect gave this sha as the first bad one: 4ee404049d749e6f1feca1a65edb619876aa480f

Everything before is good, everything after is bad.

[yupferris]

I've seen some instability with CPAL (which rodio also uses, which could explain the bisect result) on certain OS X builds. Would you mind giving cpal's and rodio's examples a shot to see if they work any better?

[yupferris]

Also, is this x86_64 or i686?

[SirVer]

CPAL, no sound :(: But no crash either!

$ cargo run --release --example beep
    Finished release [optimized] target(s) in 0.0 secs
     Running `target/release/examples/beep`
thread 'main' panicked at 'Failed to get default endpoint', /Users/rustbuild/src/rust-buildbot/slave/stable-dist-rustc-mac/build/src/libcore/option.rs:715
stack backtrace:
   1:        0x1084a102a - std::sys::imp::backtrace::tracing::imp::write::hd3b65cdfe843284c
   2:        0x1084a27cf - std::panicking::default_hook::{{closure}}::hf2b7428652613d83
   3:        0x1084a2477 - std::panicking::default_hook::h5da8f27db5582938
   4:        0x1084a2c96 - std::panicking::rust_panic_with_hook::hcef1e67c646c6802
   5:        0x1084a2b34 - std::panicking::begin_panic::hc2e8ca89533cd10d
   6:        0x1084a2a52 - std::panicking::begin_panic_fmt::h60990696c3c3a88d
   7:        0x1084a29b7 - rust_begin_unwind
   8:        0x1084c4c40 - core::panicking::panic_fmt::h10231c789bd0e97d
   9:        0x1084c4cad - core::option::expect_failed::h77d0b34eebcbdfc8
  10:        0x10849808e - beep::main::h7bcc7202bef6bbee
  11:        0x1084a382a - __rust_maybe_catch_panic
  12:        0x1084a2f06 - std::rt::lang_start::h87cb84a8b6cb187e

$ cargo run --release --example enumerate
   Compiling cpal v0.4.4 (file:///private/tmp/cpal)
    Finished release [optimized] target(s) in 0.83 secs
     Running `target/release/examples/enumerate`
Endpoints:
1. Endpoint "Default AudioUnit Endpoint" Audio formats:
1.1. Format { channels: [FrontLeft, FrontRight], samples_rate: SamplesRate(44100), data_type: F32 }

rodio: crashes. See https://github.com/tomaka/rodio/issues/94

This is a MacBookPro Retina 15 Inch, Early 2013 with Intel Core i7 running OS X El Capitan (so x86_64).

[yupferris]

Yeah that sounds like what I've seen. Need to look into what's going on in CPAL. In the mean time it should build and run with an i686 target, which you can install via rustup.

[yupferris]

Thanks for reporting/testing btw :)

[yupferris]

https://github.com/tomaka/cpal/issues/148

[yupferris]

This issue seems to have solved itself. I haven't bisected to find out exactly when, but trying local builds with i686 as well as x86_64 and I'm seeing no issues.