Bug 193826 - [WPE] Inspector server crashes because libWPEWebInspectorResources.so is looked up in an installed location
Summary: [WPE] Inspector server crashes because libWPEWebInspectorResources.so is look...
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: WPE WebKit (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-01-25 08:47 PST by Charlie Turner
Modified: 2019-01-25 08:56 PST (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Charlie Turner 2019-01-25 08:47:00 PST
Using trunk WPE, I run a WPE minibrowser like so,

% WEBKIT_INSPECTOR_SERVER='localhost:9998' run-minibrowser --wpe --debug

And then connect to it from Epiphany 3.30.2 I see a crash, the backtrace is attached for completeness,

#0  WTFCrash () at ../../Source/WTF/wtf/Assertions.cpp:255
#1  0x00007f3a3ab2e5ec in _ZN9Inspector15backendCommandsEv () at ../../Source/JavaScriptCore/inspector/remote/glib/RemoteInspectorUtils.cpp:54
#2  0x00007f3a3ab2e678 in _ZN9Inspector19backendCommandsHashEv () at ../../Source/JavaScriptCore/inspector/remote/glib/RemoteInspectorUtils.cpp:62
#3  0x00007f3a3ab1bb0d in _ZN9Inspector21RemoteInspectorServer20setupInspectorClientEP16_GDBusConnectionPKc (
    this=0x7f3a406025c0 <_ZZN9Inspector21RemoteInspectorServer9singletonEvE6server>, clientConnection=0x243c790, 
    clientBackendCommandsHash=0x7f39b400a2f0 "01F73C9BE6930FD0F80D63D575FA3C703BA803AC")
    at ../../Source/JavaScriptCore/inspector/remote/glib/RemoteInspectorServer.cpp:277
#4  0x00007f3a3ab1ac6b in Inspector::RemoteInspectorServer::<lambda(GDBusConnection*, const gchar*, const gchar*, const gchar*, const gchar*, GVariant*, GDBusMethodInvocation*, gpointer)>::operator()(GDBusConnection *, const gchar *, const gchar *, const gchar *, const gchar *, GVariant *, GDBusMethodInvocation *, gpointer) const (__closure=0x0, connection=0x243c790, methodName=0x7f39b4009190 "SetupInspectorClient", parameters=0x7f39b0003d80, 
    invocation=0x243f1c0, userData=0x7f3a406025c0 <_ZZN9Inspector21RemoteInspectorServer9singletonEvE6server>)
    at ../../Source/JavaScriptCore/inspector/remote/glib/RemoteInspectorServer.cpp:120
#5  0x00007f3a3ab1b0f2 in Inspector::RemoteInspectorServer::<lambda(GDBusConnection*, const gchar*, const gchar*, const gchar*, const gchar*, GVariant*, GDBusMethodInvocation*, gpointer)>::_FUN(GDBusConnection *, const gchar *, const gchar *, const gchar *, const gchar *, GVariant *, GDBusMethodInvocation *, gpointer) () at ../../Source/JavaScriptCore/inspector/remote/glib/RemoteInspectorServer.cpp:156
#6  0x00007f3a2b279bf9 in call_in_idle_cb (user_data=<optimized out>) at ../../Source/glib-2.58.1/gio/gdbusconnection.c:4842
#7  0x00007f3a2b05c998 in g_main_dispatch (context=0x204c190) at ../../Source/glib-2.58.1/glib/gmain.c:3182
#8  g_main_context_dispatch (context=context@entry=0x204c190) at ../../Source/glib-2.58.1/glib/gmain.c:3847
#9  0x00007f3a2b05cd58 in g_main_context_iterate (context=0x204c190, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>)
    at ../../Source/glib-2.58.1/glib/gmain.c:3920
#10 0x00007f3a2b05d042 in g_main_loop_run (loop=0x204c6e0) at ../../Source/glib-2.58.1/glib/gmain.c:4116
#11 0x000000000040dcca in main (argc=1, argv=0x7ffee2141348) at ../../Tools/MiniBrowser/wpe/main.cpp:203


The problematic function in RemoteInspectorUtils.cpp:54 is like this,

GRefPtr<GBytes> backendCommands()
{
#if PLATFORM(WPE)
    static std::once_flag flag;
    std::call_once(flag, [] {
        GModule* resourcesModule = g_module_open(PKGLIBDIR G_DIR_SEPARATOR_S "libWPEWebInspectorResources.so", G_MODULE_BIND_LAZY);
        if (!resourcesModule) {
            WTFLogAlways("Error loading libWPEWebInspectorResources.so: %s", g_module_error());
            return;
        }

        g_module_make_resident(resourcesModule);
    });
#endif
    GRefPtr<GBytes> bytes = adoptGRef(g_resources_lookup_data(INSPECTOR_BACKEND_COMMANDS_PATH, G_RESOURCE_LOOKUP_FLAGS_NONE, nullptr));
    ASSERT(bytes);
    return bytes;
}

Here, g_resources_lookup_data returns a nullptr, which causes the crash.

After discussing with Adrian offline about this, some options are,

 1) Provide an env var with a location to the libWPEWebInspectorResources.so file in the WebKitBuild dir
 2) Move the path information into a gresources file

As a workaround, I tried creating a symlink to the WebKitBuild directory from the assumed system-wide install dir like so,

'/usr/local/lib64/wpe-webkit-0.1/libWPEWebInspectorResources.so' -> '/home/cturner/webkit/webkit-wpe/WebKitBuild/Debug/lib/libWPEWebInspectorResources.so'

Then a crash is not observed, but I get instead a Connection reset by peer,

RemoteInspector failed to connect to inspector server at: localhost:9998: Error receiving data: Connection reset by peer
Comment 1 Michael Catanzaro 2019-01-25 08:49:07 PST
(In reply to Charlie Turner from comment #0)
>  2) Move the path information into a gresources file

This seems like the better solution....
Comment 2 Adrian Perez 2019-01-25 08:52:32 PST
(In reply to Michael Catanzaro from comment #1)
> (In reply to Charlie Turner from comment #0)
> >  2) Move the path information into a gresources file
> 
> This seems like the better solution....

I would go with this option as well. It would allow to use the resource
relocation support in GLib (using G_RESOURCE_OVERLAYS) as well, which
may come in handy in some situations.
Comment 3 Adrian Perez 2019-01-25 08:53:59 PST
(In reply to Adrian Perez from comment #2)
> (In reply to Michael Catanzaro from comment #1)
> > (In reply to Charlie Turner from comment #0)
> > >  2) Move the path information into a gresources file
> > 
> > This seems like the better solution....
> 
> I would go with this option as well. It would allow to use the resource
> relocation support in GLib (using G_RESOURCE_OVERLAYS) as well, which
> may come in handy in some situations.

Also, I was having a déja-vù when going over the idea of using
GResource... and yes, it was me who filed bug #186594 a while ago
precisely for this :D