Valgrind runs on cpal crash

1.log

==22472== Memcheck, a memory error detector
==22472== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==22472== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==22472== Command: ./target/debug/examples/crash
==22472== 
==22472== Invalid write of size 8
==22472==    at 0x4C367E3: memmove (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==22472==    by 0x9684359: memcpy (string3.h:53)
==22472==    by 0x9684359: pulse_read (pcm_pulse.c:534)
==22472==    by 0x4ECF9F7: ioplug_priv_transfer_areas (pcm_ioplug.c:564)
==22472==    by 0x4E909C4: snd1_pcm_read_areas (pcm.c:7217)
==22472==    by 0x4ED06AA: snd_pcm_ioplug_readi (pcm_ioplug.c:603)
==22472==    by 0x13876C: cpal::cpal_impl::EventLoop::run_inner (mod.rs:552)
==22472==    by 0x1111F2: cpal::cpal_impl::EventLoop::run (mod.rs:408)
==22472==    by 0x113590: cpal::EventLoop::run (lib.rs:495)
==22472==    by 0x115FEC: crash::main (crash.rs:10)
==22472==    by 0x1150BF: std::rt::lang_start::{{closure}} (rt.rs:64)
==22472==    by 0x14A692: {{closure}} (rt.rs:49)
==22472==    by 0x14A692: std::panicking::try::do_call (panicking.rs:297)
==22472==    by 0x14C5E9: __rust_maybe_catch_panic (lib.rs:92)
==22472==  Address 0x61d8ad0 is 0 bytes after a block of size 26,112 alloc'd
==22472==    at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==22472==    by 0x13A77B: alloc::alloc::alloc (alloc.rs:72)
==22472==    by 0x13A561: <alloc::alloc::Global as core::alloc::Alloc>::alloc (alloc.rs:148)
==22472==    by 0x12594B: <alloc::raw_vec::RawVec<T, A>>::reserve_internal (raw_vec.rs:669)
==22472==    by 0x12AF31: <alloc::raw_vec::RawVec<T, A>>::reserve (raw_vec.rs:492)
==22472==    by 0x12E071: <alloc::vec::Vec<T>>::reserve (vec.rs:460)
==22472==    by 0x1308D1: <alloc::vec::Vec<T> as alloc::vec::SpecExtend<T, I>>::spec_extend (vec.rs:1852)
==22472==    by 0x131142: <alloc::vec::Vec<T> as alloc::vec::SpecExtend<T, I>>::from_iter (vec.rs:1839)
==22472==    by 0x131690: <alloc::vec::Vec<T> as core::iter::traits::FromIterator<T>>::from_iter (vec.rs:1725)
==22472==    by 0x13BE36: core::iter::iterator::Iterator::collect (iterator.rs:1468)
==22472==    by 0x1386D9: cpal::cpal_impl::EventLoop::run_inner (mod.rs:549)
==22472==    by 0x1111F2: cpal::cpal_impl::EventLoop::run (mod.rs:408)
==22472== 

valgrind: m_mallocfree.c:280 (mk_plain_bszB): Assertion 'bszB != 0' failed.
valgrind: This is probably caused by your program erroneously writing past the
end of a heap block and corrupting heap metadata.  If you fix any
invalid writes reported by Memcheck, this assertion failure will
probably go away.  Please try that before reporting this as a bug.


host stacktrace:
==22472==    at 0x580441BA: ??? (in /usr/lib/valgrind/memcheck-amd64-linux)
==22472==    by 0x580442D4: ??? (in /usr/lib/valgrind/memcheck-amd64-linux)
==22472==    by 0x58044459: ??? (in /usr/lib/valgrind/memcheck-amd64-linux)
==22472==    by 0x580531EC: ??? (in /usr/lib/valgrind/memcheck-amd64-linux)
==22472==    by 0x5800BA84: ??? (in /usr/lib/valgrind/memcheck-amd64-linux)
==22472==    by 0x5800BC66: ??? (in /usr/lib/valgrind/memcheck-amd64-linux)
==22472==    by 0x5809F785: ??? (in /usr/lib/valgrind/memcheck-amd64-linux)
==22472==    by 0x580AED50: ??? (in /usr/lib/valgrind/memcheck-amd64-linux)

sched status:
  running_tid=1

Thread 1: status = VgTs_Runnable (lwpid 22472)
==22472==    at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==22472==    by 0x59B2456: __gconv_lookup_cache (gconv_cache.c:366)
==22472==    by 0x59A9AF1: __gconv_find_transform (gconv_db.c:737)
==22472==    by 0x59A8657: __gconv_open (gconv_open.c:109)
==22472==    by 0x59A815D: iconv_open (iconv_open.c:71)
==22472==    by 0x697EB74: iconv_simple (utf8.c:201)
==22472==    by 0x6999019: pa_log_levelv_meta (log.c:486)
==22472==    by 0x69986A4: pa_log_level_meta (log.c:585)
==22472==    by 0x69A8CD0: pa_queue_push (queue.c:72)
==22472==    by 0x69A6CC2: pa_pstream_send_release (pstream.c:533)
==22472==    by 0x699D72C: memblock_free (memblock.c:635)
==22472==    by 0x699D72C: pa_memblock_unref (memblock.c:687)
==22472==    by 0x67436D4: pa_stream_drop (stream.c:1673)
==22472==    by 0x968444B: pulse_read (pcm_pulse.c:537)
==22472==    by 0x4ECF9F7: ioplug_priv_transfer_areas (pcm_ioplug.c:564)
==22472==    by 0x4E909C4: snd1_pcm_read_areas (pcm.c:7217)
==22472==    by 0x4ED06AA: snd_pcm_ioplug_readi (pcm_ioplug.c:603)
==22472==    by 0x13876C: cpal::cpal_impl::EventLoop::run_inner (mod.rs:552)
==22472==    by 0x1111F2: cpal::cpal_impl::EventLoop::run (mod.rs:408)
==22472==    by 0x113590: cpal::EventLoop::run (lib.rs:495)
==22472==    by 0x115FEC: crash::main (crash.rs:10)
==22472==    by 0x1150BF: std::rt::lang_start::{{closure}} (rt.rs:64)
==22472==    by 0x14A692: {{closure}} (rt.rs:49)
==22472==    by 0x14A692: std::panicking::try::do_call (panicking.rs:297)
==22472==    by 0x14C5E9: __rust_maybe_catch_panic (lib.rs:92)
==22472==    by 0x14B1E5: try<i32,closure> (panicking.rs:276)
==22472==    by 0x14B1E5: catch_unwind<closure,i32> (panic.rs:388)
==22472==    by 0x14B1E5: std::rt::lang_start_internal (rt.rs:48)
==22472==    by 0x115098: std::rt::lang_start (rt.rs:64)
==22472==    by 0x116049: main (in /home/mozgiii/Desktop/cpal/target/debug/examples/crash)

Thread 2: status = VgTs_WaitSys (lwpid 22486)
==22472==    at 0x5A9ABF9: poll (poll.c:29)
==22472==    by 0x6749480: poll (poll2.h:46)
==22472==    by 0x6749480: poll_func (thread-mainloop.c:69)
==22472==    by 0x673AE3F: pa_mainloop_poll (mainloop.c:844)
==22472==    by 0x673B4CF: pa_mainloop_iterate (mainloop.c:926)
==22472==    by 0x673B55F: pa_mainloop_run (mainloop.c:944)
==22472==    by 0x67493C8: thread (thread-mainloop.c:100)
==22472==    by 0x69B9317: internal_thread_func (thread-posix.c:81)
==22472==    by 0x55566DA: start_thread (pthread_create.c:463)
==22472==    by 0x5AA788E: clone (clone.S:95)


Note: see also the FAQ in the source distribution.
It contains workarounds to several common problems.
In particular, if Valgrind aborted or crashed after
identifying problems in your program, there's a good chance
that fixing those problems will prevent Valgrind aborting or
crashing, especially if it happened in m_mallocfree.c.

If that doesn't help, please report this bug to: www.valgrind.org

In the bug report, send all the above text, the valgrind
version, and what OS and version you are using.  Thanks.

2.log

==23504== Memcheck, a memory error detector
==23504== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==23504== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==23504== Command: ./target/debug/examples/crash
==23504== 
==23504== Invalid write of size 8
==23504==    at 0x4C367E3: memmove (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==23504==    by 0x9684359: memcpy (string3.h:53)
==23504==    by 0x9684359: pulse_read (pcm_pulse.c:534)
==23504==    by 0x4ECF9F7: ioplug_priv_transfer_areas (pcm_ioplug.c:564)
==23504==    by 0x4E909C4: snd1_pcm_read_areas (pcm.c:7217)
==23504==    by 0x4ED06AA: snd_pcm_ioplug_readi (pcm_ioplug.c:603)
==23504==    by 0x13876C: cpal::cpal_impl::EventLoop::run_inner (mod.rs:552)
==23504==    by 0x1111F2: cpal::cpal_impl::EventLoop::run (mod.rs:408)
==23504==    by 0x113590: cpal::EventLoop::run (lib.rs:495)
==23504==    by 0x115FEC: crash::main (crash.rs:10)
==23504==    by 0x1150BF: std::rt::lang_start::{{closure}} (rt.rs:64)
==23504==    by 0x14A692: {{closure}} (rt.rs:49)
==23504==    by 0x14A692: std::panicking::try::do_call (panicking.rs:297)
==23504==    by 0x14C5E9: __rust_maybe_catch_panic (lib.rs:92)
==23504==  Address 0x6231ac8 is 0 bytes after a block of size 2,120 alloc'd
==23504==    at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==23504==    by 0x13A77B: alloc::alloc::alloc (alloc.rs:72)
==23504==    by 0x13A561: <alloc::alloc::Global as core::alloc::Alloc>::alloc (alloc.rs:148)
==23504==    by 0x12594B: <alloc::raw_vec::RawVec<T, A>>::reserve_internal (raw_vec.rs:669)
==23504==    by 0x12AF31: <alloc::raw_vec::RawVec<T, A>>::reserve (raw_vec.rs:492)
==23504==    by 0x12E071: <alloc::vec::Vec<T>>::reserve (vec.rs:460)
==23504==    by 0x1308D1: <alloc::vec::Vec<T> as alloc::vec::SpecExtend<T, I>>::spec_extend (vec.rs:1852)
==23504==    by 0x131142: <alloc::vec::Vec<T> as alloc::vec::SpecExtend<T, I>>::from_iter (vec.rs:1839)
==23504==    by 0x131690: <alloc::vec::Vec<T> as core::iter::traits::FromIterator<T>>::from_iter (vec.rs:1725)
==23504==    by 0x13BE36: core::iter::iterator::Iterator::collect (iterator.rs:1468)
==23504==    by 0x1386D9: cpal::cpal_impl::EventLoop::run_inner (mod.rs:549)
==23504==    by 0x1111F2: cpal::cpal_impl::EventLoop::run (mod.rs:408)
==23504== 

valgrind: m_mallocfree.c:280 (mk_plain_bszB): Assertion 'bszB != 0' failed.
valgrind: This is probably caused by your program erroneously writing past the
end of a heap block and corrupting heap metadata.  If you fix any
invalid writes reported by Memcheck, this assertion failure will
probably go away.  Please try that before reporting this as a bug.


host stacktrace:
==23504==    at 0x580441BA: ??? (in /usr/lib/valgrind/memcheck-amd64-linux)
==23504==    by 0x580442D4: ??? (in /usr/lib/valgrind/memcheck-amd64-linux)
==23504==    by 0x58044459: ??? (in /usr/lib/valgrind/memcheck-amd64-linux)
==23504==    by 0x580531EC: ??? (in /usr/lib/valgrind/memcheck-amd64-linux)
==23504==    by 0x5800BA84: ??? (in /usr/lib/valgrind/memcheck-amd64-linux)
==23504==    by 0x5800BC66: ??? (in /usr/lib/valgrind/memcheck-amd64-linux)
==23504==    by 0x5809F785: ??? (in /usr/lib/valgrind/memcheck-amd64-linux)
==23504==    by 0x580AED50: ??? (in /usr/lib/valgrind/memcheck-amd64-linux)

sched status:
  running_tid=1

Thread 1: status = VgTs_Runnable (lwpid 23504)
==23504==    at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==23504==    by 0x13A77B: alloc::alloc::alloc (alloc.rs:72)
==23504==    by 0x13A561: <alloc::alloc::Global as core::alloc::Alloc>::alloc (alloc.rs:148)
==23504==    by 0x12594B: <alloc::raw_vec::RawVec<T, A>>::reserve_internal (raw_vec.rs:669)
==23504==    by 0x12AF31: <alloc::raw_vec::RawVec<T, A>>::reserve (raw_vec.rs:492)
==23504==    by 0x12E071: <alloc::vec::Vec<T>>::reserve (vec.rs:460)
==23504==    by 0x1308D1: <alloc::vec::Vec<T> as alloc::vec::SpecExtend<T, I>>::spec_extend (vec.rs:1852)
==23504==    by 0x131142: <alloc::vec::Vec<T> as alloc::vec::SpecExtend<T, I>>::from_iter (vec.rs:1839)
==23504==    by 0x131690: <alloc::vec::Vec<T> as core::iter::traits::FromIterator<T>>::from_iter (vec.rs:1725)
==23504==    by 0x13BE36: core::iter::iterator::Iterator::collect (iterator.rs:1468)
==23504==    by 0x1386D9: cpal::cpal_impl::EventLoop::run_inner (mod.rs:549)
==23504==    by 0x1111F2: cpal::cpal_impl::EventLoop::run (mod.rs:408)
==23504==    by 0x113590: cpal::EventLoop::run (lib.rs:495)
==23504==    by 0x115FEC: crash::main (crash.rs:10)
==23504==    by 0x1150BF: std::rt::lang_start::{{closure}} (rt.rs:64)
==23504==    by 0x14A692: {{closure}} (rt.rs:49)
==23504==    by 0x14A692: std::panicking::try::do_call (panicking.rs:297)
==23504==    by 0x14C5E9: __rust_maybe_catch_panic (lib.rs:92)
==23504==    by 0x14B1E5: try<i32,closure> (panicking.rs:276)
==23504==    by 0x14B1E5: catch_unwind<closure,i32> (panic.rs:388)
==23504==    by 0x14B1E5: std::rt::lang_start_internal (rt.rs:48)
==23504==    by 0x115098: std::rt::lang_start (rt.rs:64)
==23504==    by 0x116049: main (in /home/mozgiii/Desktop/cpal/target/debug/examples/crash)

Thread 2: status = VgTs_WaitSys (lwpid 23514)
==23504==    at 0x5A9ABF9: poll (poll.c:29)
==23504==    by 0x6749480: poll (poll2.h:46)
==23504==    by 0x6749480: poll_func (thread-mainloop.c:69)
==23504==    by 0x673AE3F: pa_mainloop_poll (mainloop.c:844)
==23504==    by 0x673B4CF: pa_mainloop_iterate (mainloop.c:926)
==23504==    by 0x673B55F: pa_mainloop_run (mainloop.c:944)
==23504==    by 0x67493C8: thread (thread-mainloop.c:100)
==23504==    by 0x69B9317: internal_thread_func (thread-posix.c:81)
==23504==    by 0x55566DA: start_thread (pthread_create.c:463)
==23504==    by 0x5AA788E: clone (clone.S:95)


Note: see also the FAQ in the source distribution.
It contains workarounds to several common problems.
In particular, if Valgrind aborted or crashed after
identifying problems in your program, there's a good chance
that fixing those problems will prevent Valgrind aborting or
crashing, especially if it happened in m_mallocfree.c.

If that doesn't help, please report this bug to: www.valgrind.org

In the bug report, send all the above text, the valgrind
version, and what OS and version you are using.  Thanks.