oops error when navigating a website from facebook or twitter

I can reproduce the issue fairly easily on my frieza. I’m seeing this in the twitter webapp’s log:

[1109/202602:ERROR:oxide_user_script_slave.cc(168)] Caught exception when calling script: Uncaught TypeError: external.getUnityObject is not a function
Received signal 11 SEGV_MAPERR 000000000008
#0 0x0000f4b5a576 <unknown>
#1 0x0000f4b5a888 <unknown>
#2 0x0000f3b3f250 <unknown>
#3 0x0000f56b871a <unknown>
#4 0x0000f56bb39c <unknown>
#5 0x0000f43ec192 <unknown>
#6 0x0000f444ebfa <unknown>
#7 0x0000f444f0b2 <unknown>
[end of stack trace]

I was able to reproduce the same error on Krillin with the silo
Using Facebook, navigating to a link which opens another website, then navigating on that website

Seeing this in fb log:
[1109/155229:ERROR:oxide_user_script_slave.cc(168)] Caught exception when calling script: Uncaught TypeError: external.getUnityObject is not a function
qml: [JS] (https://dmb3ount55sfc.cloudfront.net/webapp/static-0-138-1/js/vendor.min.js:10) TypeError: Cannot read property 'getItem' of null
    at t.value (https://dmb3ount55sfc.cloudfront.net/webapp/static-0-138-1/js/app.min.js:2642:2236)
    at https://dmb3ount55sfc.cloudfront.net/webapp/static-0-138-1/js/app.min.js:4178:1860
    at https://dmb3ount55sfc.cloudfront.net/webapp/static-0-138-1/js/vendor.min.js:11:695
    at g (https://dmb3ount55sfc.cloudfront.net/webapp/static-0-138-1/js/vendor.min.js:9:10939)
    at https://dmb3ount55sfc.cloudfront.net/webapp/static-0-138-1/js/vendor.min.js:9:13050
A Parser-blocking, cross-origin script, https://cdn.optimizely.com/js/4566010044.js, is invoked via document.write. This may be blocked by the browser if the device has poor network connectivity.
qml: [JS] (https://tags.tiqcdn.com/utag/peloton/main/prod/utag.sync.js:4) A Parser-blocking, cross-origin script, https://cdn.optimizely.com/js/4566010044.js, is invoked via document.write. This may be blocked by the browser if the device has poor network connectivity.
A Parser-blocking, cross-origin script, https://cdn.optimizely.com/js/4566010044.js, is invoked via document.write. This may be blocked by the browser if the device has poor network connectivity.
qml: [JS] (https://tags.tiqcdn.com/utag/peloton/main/prod/utag.sync.js:4) A Parser-blocking, cross-origin script, https://cdn.optimizely.com/js/4566010044.js, is invoked via document.write. This may be blocked by the browser if the device has poor network connectivity.
A Parser-blocking, cross-origin script, https://www.google.com/uds/api/visualization/1.0/1195ca6324d5ce101c2f520f3c62c843/format+en,default+en,ui+en,corechart+en.I.js, is invoked via document.write. This may be blocked by the browser if the device has poor network connectivity.
qml: [JS] (https://www.google.com/jsapi?autoload={%22modules%22:[{%22name%22:%22visualization%22,%22version%22:%221%22,%22packages%22:[%22corechart%22]}]}:22) A Parser-blocking, cross-origin script, https://www.google.com/uds/api/visualization/1.0/1195ca6324d5ce101c2f520f3c62c843/format+en,default+en,ui+en,corechart+en.I.js, is invoked via document.write. This may be blocked by the browser if the device has poor network connectivity.
A Parser-blocking, cross-origin script, https://www.google.com/uds/api/visualization/1.0/1195ca6324d5ce101c2f520f3c62c843/format+en,default+en,ui+en,corechart+en.I.js, is invoked via document.write. This may be blocked by the browser if the device has poor network connectivity.
qml: [JS] (https://www.google.com/jsapi?autoload={%22modules%22:[{%22name%22:%22visualization%22,%22version%22:%221%22,%22packages%22:[%22corechart%22]}]}:22) A Parser-blocking, cross-origin script, https://www.google.com/uds/api/visualization/1.0/1195ca6324d5ce101c2f520f3c62c843/format+en,default+en,ui+en,corechart+en.I.js, is invoked via document.write. This may be blocked by the browser if the device has poor network connectivity.
Received signal 11 SEGV_MAPERR 000000000008
#0 0x000...

When attaching with gdb to the render process, I’m seeing this:

Program received signal SIGSEGV, Segmentation fault.
0xf5ac171a in IsEmpty () at ../../v8/include/v8.h:502
502 ../../v8/include/v8.h: No such file or directory.
(gdb) bt
#0 0xf5ac171a in IsEmpty () at ../../v8/include/v8.h:502
#1 NewHandle () at ../../oxide/shared/renderer/oxide_v8_scoped_persistent.h:56
#2 NewInstance ()
    at ../../oxide/shared/renderer/oxide_object_backed_native_handler.cc:208
#3 0xf5ac439c in SendMessageInner ()
    at ../../oxide/shared/renderer/oxide_script_message_manager.cc:223
#4 0xf47f5192 in Call () at ../../v8/src/api-arguments.cc:21
#5 0xf4857bfa in HandleApiCallHelper<false> ()
    at ../../v8/src/builtins/builtins-api.cc:106
#6 0xf48580b2 in Builtin_Impl_HandleApiCall ()
    at ../../v8/src/builtins/builtins-api.cc:135
#7 Builtin_HandleApiCall () at ../../v8/src/builtins/builtins-api.cc:123
#8 0x49a0a33c in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

After applying Chris’ patch (attached here for reference), I’m still seeing the renderer crash, but the trace is now different:

(gdb) bt
#0 0xf5c545f2 in oxide::ObjectBackedNativeHandler::NewInstance() ()
   from /usr/lib/arm-linux-gnueabihf/libOxideQtCore.so.0
#1 0xf5c56ffa in oxide::ScriptMessageManager::SendMessageInner(v8::FunctionCallbackInfo<v8::Value> const&) ()
   from /usr/lib/arm-linux-gnueabihf/libOxideQtCore.so.0
#2 0xf498c71a in v8::internal::FunctionCallbackArguments::Call(void (*)(v8::FunctionCallbackInfo<v8::Value> const&)) ()
   from /usr/lib/arm-linux-gnueabihf/libOxideQtCore.so.0
#3 0xf49ef182 in v8::internal::MaybeHandle<v8::internal::Object> v8::internal::(anonymous namespace)::HandleApiCallHelper<false>(v8::internal::Isolate*, v8::internal::Handle<v8::internal::HeapObject>, v8::internal::Handle<v8::internal::HeapObject>, v8::internal::Handle<v8::internal::FunctionTemplateInfo>, v8::internal::Handle<v8::internal::Object>, v8::internal::BuiltinArguments) ()
   from /usr/lib/arm-linux-gnueabihf/libOxideQtCore.so.0
#4 0xf49ef63a in v8::internal::Builtin_HandleApiCall(int, v8::internal::Object**, v8::internal::Isolate*) ()
   from /usr/lib/arm-linux-gnueabihf/libOxideQtCore.so.0
#5 0x4290a33c in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

I’ve instrumented my local build, and the message that triggers the renderer crash is the one with msgid "UnityWebappApi-Message":

  args : "[null]"
  callback : null
  name : "ContentHub.onShareRequested"
  target : "ubuntu-webapps-binding-call"

In ObjectBackedNativeHandler::NewInstance(), 'manager_' is null, so dereferencing it triggers the crash.

And indeed I’m seeing the destructor for the corresponding ScriptMessageManager being called prior to SendMessageInner() being invoked.

so trying to get a clean stack trace, I repeatedly saw indication of dandling manager pointer,

I had the crashes actually in the main view too,

the specific context that seems to make it more easily reproducible with omgubuntu is the amount of frames that it contains and the amount of frame reloads/redirections that happen there,

this is the amount of scripts context being freed during a load:

https://pastebin.canonical.com/170795/

this is without any navigation (the number indicate the world id, 0 being the main world),

For the record I also experienced some crashes while re-testing the 1.17.9 build, and using the overlay window in Twitter to sites like OMGUbuntu.

As I was returning from an overlay window navigation on Twitter to an OMBUbuntu page, the webapp crashed :

Program received signal SIGSEGV, Segmentation fault.
0xabfffc56 in ?? () from /usr/lib/arm-linux-gnueabihf/libOxideQtCore.so.0
(gdb) bt
#0 0xabfffc56 in ?? () from /usr/lib/arm-linux-gnueabihf/libOxideQtCore.so.0
#1 0xabfffeb6 in ?? () from /usr/lib/arm-linux-gnueabihf/libOxideQtCore.so.0
#2 0xac000128 in ?? () from /usr/lib/arm-linux-gnueabihf/libOxideQtCore.so.0
#3 0xaa307018 in ?? () from /usr/lib/arm-linux-gnueabihf/libOxideQtCore.so.0
#4 0xaa1a2a8a in ?? () from /usr/lib/arm-linux-gnueabihf/libOxideQtCore.so.0
#5 0xaa27adb6 in ?? () from /usr/lib/arm-linux-gnueabihf/libOxideQtCore.so.0
#6 0xabbc39f6 in ?? () from /usr/lib/arm-linux-gnueabihf/libOxideQtCore.so.0
#7 0xab5ab4f6 in ?? () from /usr/lib/arm-linux-gnueabihf/libOxideQtCore.so.0
#8 0xab5be5d2 in ?? () from /usr/lib/arm-linux-gnueabihf/libOxideQtCore.so.0
#9 0xab5be834 in ?? () from /usr/lib/arm-linux-gnueabihf/libOxideQtCore.so.0
#10 0xab5bec5e in ?? () from /usr/lib/arm-linux-gnueabihf/libOxideQtCore.so.0
#11 0xa9f2107e in ?? () from /usr/lib/arm-linux-gnueabihf/libOxideQtCore.so.0
#12 0xb6dd9a2a in QObject::event(QEvent*) () from /usr/lib/arm-linux-gnueabihf/libQt5Core.so.5
#13 0xb62c9ef4 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/arm-linux-gnueabihf/libQt5Widgets.so.5
#14 0xb62cdde4 in QApplication::notify(QObject*, QEvent*) () from /usr/lib/arm-linux-gnueabihf/libQt5Widgets.so.5
#15 0x01426130 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

This was using 1.17.9

So I think the bug has been there for a while. It is just easier to trigger in 1.18, not so much in 1.17 (it took me ~10 mins. of browsing in the Twitter webapp), and even less so in 1.16

@dbarth this is the result of
https://bugs.launchpad.net/oxide/+bug/1570828

I still can't make any test case trigger this bug, but this fixes it in any case: https://git.launchpad.net/oxide/commit/?id=8c6ebc3f5b827652236438632a5434a5e20aa5cc