Malloc issues with webview

**edit: the problem seems to be in the c library that this crate wraps.**
old edit: I have added an example program that demonstrates the bug in the first comment (also the standard examples also display the error when run under valgrind).

I've been getting malloc crashes which I think are associated with rust webview. The crashes only happen later during app cleanup but when I run my code under valgrind I get the following messages (excerpt only, but the rest is more of the same). The actual final crash is in the sqlite3 deallocation.

**Context**

* web-view = "0.5.2"
* Linux starnova 4.4.154-59-rockchip-g5e70f14 #4 SMP Fri Dec 14 20:55:41 CST 2018 aarch64 aarch64 aarch64 GNU/Linux
* rustc 1.37.0 (eae3437df 2019-08-13)

**Messages**

> main thread is ThreadId(1)
> main running engine with webview...
> main building webview...
> engine initial html took 0.024s
> ==9220== Warning: set address range perms: large range [0x59c04000, 0x999c04000) (defined)
> ==9220== Warning: set address range perms: large range [0x59c04000, 0x80000000) (noaccess)
> ==9220== Warning: set address range perms: large range [0x940000000, 0x999c04000) (noaccess)
> main webview built.
> main web view ready
> main running...
> ==9220== Thread 9 ReceiveQueue:
> ==9220== Syscall param sendmsg(msg.msg_iov[0]) points to uninitialised byte(s)
> ==9220== at 0x494C66C: sendmsg (sendmsg.c:28)
> ==9220== by 0x51D4EA7: ??? (in /usr/lib/aarch64-linux-gnu/libwebkit2gtk-4.0.so.37.37.6)
> ==9220== Address 0x1a9ff261 is on thread 9's stack
> ==9220==
> ==9220== Thread 1:
> ==9220== Invalid read of size 8
> ==9220== at 0x170BDC: as core::ops::drop::Drop>::drop (rwlock.rs:554)
> ==9220== by 0x172DF7: core::ptr::real_drop_in_place (mod.rs:197)
> ==9220== by 0x177C47: web_view::WebView::_into_inner (lib.rs:466)
> ==9220== by 0x177AB7: web_view::WebView::into_inner (lib.rs:448)
> ==9220== by 0x178167: web_view::WebView::run (lib.rs:440)
> ==9220== by 0x16C687: fanling10::run_engine_with_webview (main.rs:145)
> ==9220== by 0x16BCFB: fanling10::actual_main (main.rs:85)
> ==9220== by 0x16B4E3: fanling10::main (main.rs:56)
> ==9220== by 0x175407: std::rt::lang_start::{{closure}} (rt.rs:64)
> ==9220== by 0x79BDEB: {{closure}} (rt.rs:49)
> ==9220== by 0x79BDEB: std::panicking::try::do_call (panicking.rs:296)
> ==9220== by 0x7A10BB: __rust_maybe_catch_panic (lib.rs:82)
> ==9220== by 0x79C733: try (panicking.rs:275)
> ==9220== by 0x79C733: catch_unwind (panic.rs:394)
> ==9220== by 0x79C733: std::rt::lang_start_internal (rt.rs:48)
> ==9220== Address 0xcbdd930 is 16 bytes inside a block of size 32 free'd
> ==9220== at 0x4845D58: free (in /usr/lib/valgrind/vgpreload_memcheck-arm64-linux.so)
> ==9220== Block was alloc'd at
> ==9220== at 0x4844BFC: malloc (in /usr/lib/valgrind/vgpreload_memcheck-arm64-linux.so)
> ==9220==
> ==9220== Invalid write of size 1
> ==9220== at 0x176130: std::sys::unix::rwlock::RWLock::write_unlock (rwlock.rs:115)
> ==9220== by 0x17152B: std::sys_common::rwlock::RWLock::write_unlock (rwlock.rs:64)
> ==9220== by 0x170BE3: as core::ops::drop::Drop>::drop (rwlock.rs:554)
> ==9220== by 0x172DF7: core::ptr::real_drop_in_place (mod.rs:197)
> ==9220== by 0x177C47: web_view::WebView::_into_inner (lib.rs:466)
> ==9220== by 0x177AB7: web_view::WebView::into_inner (lib.rs:448)
> ==9220== by 0x178167: web_view::WebView::run (lib.rs:440)
> ==9220== by 0x16C687: fanling10::run_engine_with_webview (main.rs:145)
> ==9220== by 0x16BCFB: fanling10::actual_main (main.rs:85)
> ==9220== by 0x16B4E3: fanling10::main (main.rs:56)
> ==9220== by 0x175407: std::rt::lang_start::{{closure}} (rt.rs:64)
> ==9220== by 0x79BDEB: {{closure}} (rt.rs:49)
> ==9220== by 0x79BDEB: std::panicking::try::do_call (panicking.rs:296)
> ==9220== Address 0xcbdd8d0 is 64 bytes inside a block of size 72 free'd
> ==9220== at 0x4845D58: free (in /usr/lib/valgrind/vgpreload_memcheck-arm64-linux.so)
> ==9220== Block was alloc'd at
> ==9220== at 0x4844BFC: malloc (in /usr/lib/valgrind/vgpreload_memcheck-arm64-linux.so)

Start with lib.rs at WebView::run, into_inner, and _into_inner, which appear in the Valgrind stack, then reproduce the example program or standard examples under Valgrind. Done means identifying the cleanup path causing the invalid reads and writes and confirming that the malloc and sqlite3 deallocation errors no longer occur.

Written by the indexing model from the issue text.