Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Segfault when run from child thread.

See original GitHub issue

Hello! Thank you for building this, first of all! I’ve had alright success running this from the main thread, but it seems to die when run from a child. Here’s the segfault:

1   0x7fdcc656c247 /usr/lib/x86_64-linux-gnu/libjavascriptcoregtk-4.0.so.18(WTFCrash+0x17) [0x7fdcc656c247]
2   0x7fdcc7ced999 /usr/lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37(+0x67d999) [0x7fdcc7ced999]
3   0x7fdcc7d31d9a /usr/lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37(+0x6c1d9a) [0x7fdcc7d31d9a]
4   0x7fdcc7d32219 /usr/lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37(+0x6c2219) [0x7fdcc7d32219]
5   0x7fdcc7faf0d0 /usr/lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37(+0x93f0d0) [0x7fdcc7faf0d0]
6   0x7fdcc6833e72 /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_object_unref+0x1a2) [0x7fdcc6833e72]
7   0x7fdcc48f0041 /lib/x86_64-linux-gnu/libc.so.6(+0x43041) [0x7fdcc48f0041]
8   0x7fdcc48f013a /lib/x86_64-linux-gnu/libc.so.6(+0x4313a) [0x7fdcc48f013a]
9   0x7fdcc48ceb9e /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xee) [0x7fdcc48ceb9e]
10  0x55777992389a target/debug/rust_ksl_uploader(+0x889a) [0x55777992389a]
Segmentation fault (core dumped)

And here’s the minimal code to reproduce:

extern crate web_view;

use web_view::*;
use std::thread::spawn;

const INDEX: &str = r#"<!DOCTYPE html>
<html lang="en" dir="ltr">
  <head>
    <meta charset="utf-8">
    <title></title>
  </head>
  <body>
    This is a test.
  </body>
</html>
"#;

fn main() {
    let size = (800, 800);
    let resizable = true;
    let debug = true;
    let init_cb = |_webview| {};
    let frontend_cb = |_webview: &mut _, _arg: &_, _userdata: &mut _| {};
    let userdata = ();
    let view = spawn(move || {
        run("test thread", Content::Html(INDEX), Some(size), resizable, debug, init_cb, frontend_cb, userdata);
    });

    view.join().expect("Join Error");
}

Issue Analytics

State:
Created 5 years ago
Comments:7

Top GitHub Comments

2reactions

Zenniicommented, Jun 25, 2019

I’ve come across this issue as well. Ubuntu 18.04 and libwebkit2gtk-4.0 package is installed (If that’s even necessary or useful). Here is the minimal code that consistently produces the issue for me with the current API (With sleep to show the window hangs):

use web_view::*;
use std::time::Duration;

fn main() {
    std::thread::spawn(|| {
        let mut wv = web_view::builder()
            .content(web_view::Content::Url(""))
            .user_data(0)
            .invoke_handler(|wv, arg| {
                // terminate in here causes free(): invalid pointer
                Ok(())
            })
            .build().expect("Build Error");
        wv.run().expect("Run Error");
    });
    std::thread::sleep(Duration::from_secs(7));
}

I did some of my own snooping around by running it through valgrind and found that when I placed mem::forget(_lock); near the bottom of the _into_inner(&mut self) function in a local copy of the crate, a ton of errors reported by valgrind go away during the drop and malloc_consolidate(): invalid chunk size stops happening and thus the program doesn’t crash, but the window will hang until the main thread is done and the entire program still closes with signal 6 SIGABRT when it’s done. You can circumvent the hanging by waiting an indeterminate amount of time after the window thinks it’s dead and returns None to step a few times, like this:

std::thread::spawn(|| {
    let mut wv = web_view::builder()
        .content(web_view::Content::Url(""))
        .user_data(0)
        .invoke_handler(|wv, arg| {Ok(())})
        .build().unwrap();
    let mut looped = 0;
    loop {
        match wv.step() {
            Some(Ok(a)) => (),
            Some(Err(e)) => (),
            None => {
                looped += 1;
                if looped > 4 {
                    println!("Closed");
                    return;
                }
            }
        }
    }
});

but it’s a very ugly magical workaround and I’m really unsure as to why it works exactly. It feels like some kind of race condition, but I’m not sure how the window manager works. Hope this helps deduce what’s wrong.

0reactions

quadrupleslapcommented, Jan 30, 2019

Note: You could never run this on a non-main thread on macOS anyway, because macOS is weird like that.

Top Results From Across the Web

Segmentation fault occurring with child pthreads

I'm currently working on custom thread scheduler project that uses pthreads in C. I have been struggling conceptually with it but am finally ......

Segmentation fault when accessing thread local data [Multi ...

While running the shared library as a shadow-plugin, segmentation fault appears when a thread local variable is being accessed. ... Then load the ......

Segmentation faults - Geos-chem

If your simulation dies with a segmentation fault error, this means that GEOS-Chem tried to ... Cause: The stack size for child threads...

Segmentation Fault (SIGSEGV) vs Bus Error (SIGBUS)

The main difference between Segmentation Fault and Bus Error is that Segmentation Fault indicates an invalid access to a valid memory, while Bus ......

Thread: [Gambas-user] Segmentation fault (core dumped)

SVN 2722 (did a reconf and configure), not sure how to help, don't get much console output and can't get gambas3 to run...