martinellison
commented
4 years ago Here is a reasonably short example that exhibits the behaviour that I have described in the original post. It is a simplified form of the code that generated the previous error. Also, I have added the Cargo.toml file. To display the bug, you can
- run the example, and close the window it displays. It displays a malloc error,
- run the example using valgrind memcheck and note the many error messages,
Text of example
/*! Test of webview */
extern crate web_view;
use ansi_term::Colour::*;
use ansi_term::Style;
use std::path::PathBuf;
use std::thread;
use std::time::SystemTime;
use web_view::*;
#[macro_use]
extern crate quick_error;
quick_error! {
#[derive(Debug)]
/** Error found in test case */
pub enum WebviewTestError {
/// internal error
WebviewTestError(msg: String) {from()}
/// internal IO error
Io(err: std::io::Error) {from() cause(err) description(err.description())}
/// webview error
Web(err: web_view::Error) {from() cause(err) description(err.description())}
/// system time error
Time(err:std::time::SystemTimeError) {from() cause(err) description(err.description())}
}}
impl WebviewTestError {
pub fn new(txt: &str) -> Self {
Self::WebviewTestError(txt.to_string())
}
}
type NullResult = Result<(), WebviewTestError>;
/** used by [web_view::WebView] */
struct UserData {}
impl Drop for UserData {
fn drop(&mut self) {
trace(Blue.on(White), "dropping userdata");
}
}
fn main() {
let mark = Mark::new();
actual_main().expect("internal error");
trace(Blue.on(White), "really ending main.");
mark.touch();
}
fn actual_main() -> NullResult {
trace(Blue.on(White), "starting main");
trace(
Blue.on(White),
&format!("thread is {:?}", thread::current().id(),),
);
trace(Blue.on(White), "running with webview...");
run_with_webview()?;
trace(Blue.on(White), "finished running with webview");
Ok(())
}
fn run_with_webview() -> NullResult {
trace(Blue.on(White), "building webview...");
let p = UserData {};
{
let now = SystemTime::now();
let mut webview = web_view::builder()
.title("Test")
.content(web_view::Content::Html("hello webview"))
.size(640, 960)
.resizable(true)
.debug(false)
.user_data(p)
.invoke_handler(invoke_handler)
.build()?;
trace(Blue.on(White), "webview built.");
webview.set_color((156, 39, 176));
trace(
Black.on(White),
&format!("web view ready, thread is {:?}", thread::current().id()),
);
trace(
Blue.on(White),
&format!(
"building webview took {}s ",
now.elapsed()?.as_millis() as f64 / 1000.0,
),
);
let _res = webview.run()?;
trace(Blue.on(White), "run.");
}
trace(Blue.on(White), "run, ending main.");
Ok(())
}
fn invoke_handler(webview: &mut WebView<UserData>, arg: &str) -> WVResult {
trace(
Black.on(White),
&format!(
"main handler, arg {}, thread is {:?}",
arg,
thread::current().id()
),
);
webview.set_title(&format!("Webview test"))?;
let response = Ok(()); //webview.user_data_mut().engine.execute(arg);
handle_response(webview, &response, arg);
Ok(())
}
fn handle_response(webview: &mut WebView<UserData>, response: &NullResult, arg: &str) {
match response {
Ok(_) => trace(Black.on(White), "normal response"),
Err(e) => {
trace(
Black.on(White),
&format!("could not handle execution: {}/{:?}", arg, e),
);
}
}
}
fn trace(style: Style, s: &str) {
println!("main {}", style.paint(s));
}
/** for debugging */
struct Mark {}
impl Mark {
fn new() -> Mark {
trace(Yellow.on(Cyan), "making mark in main");
Self {}
}
fn touch(&self) {
trace(Yellow.on(Cyan), "touching mark in main");
}
}
impl Drop for Mark {
fn drop(&mut self) {
trace(Yellow.on(Cyan), "dropping mark in main");
}
}Cargo.toml [package] name = "webview-test" version = "0.1.0" authors = ["martin m.e@acm.org"] edition = "2018"
[dependencies]
ansi_term = "0.12.1" rust-embed = "5.1.0" web-view = "0.5.2" quick-error = "1.2.2"
richardhozak
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
Messages