Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Qt Development
  3. Qt for WebAssembly
  4. "Cannot have multiple async operations in flight at once" during QApplication initialization
Forum Updated to NodeBB v4.3 + New Features

"Cannot have multiple async operations in flight at once" during QApplication initialization

Scheduled Pinned Locked Moved Unsolved Qt for WebAssembly
2 Posts 1 Posters 585 Views
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • F Offline
    F Offline
    fwcd
    wrote on 8 Mar 2024, 01:23 last edited by
    #1

    I am currently porting a moderately-sized Qt app to the web (Mixxx) and have found that enabling -sASSERTIONS (with Qt 6.6.2) will crash the app at launch with

    mixxx.js:12662 Aborted(Assertion failed: Cannot have multiple async operations in flight at once)
    

    The issue seems to be that Mixxx's own asynchronous operations (mostly QDialog::exec) seem to clash with QWasmClipboard::initClipboardPermissions, which is invoked internally during QApplication's initialization:

    abort
    assert
    whenDone
    promiseCallbackFinally2
    Promise.finally (async)		
    methodCaller<(emscripten::val) => emscripten::val>
    __emval_call_method
    imports.<computed>
    $std::__2::__function::__func<qstdweb::(anonymous namespace)::WebPromiseManager::adoptPromise(emscripten::val, qstdweb::PromiseCallbacks)::$_0, std::__2::allocator<qstdweb::(anonymous namespace)::WebPromiseManager::adoptPromise(emscripten::val, qstdweb::PromiseCallbacks)::$_0>, void (std::__2::unique_ptr<qstdweb::(anonymous namespace)::ThunkPool::ThunkAllocation, std::__2::default_delete<qstdweb::(anonymous namespace)::ThunkPool::ThunkAllocation>>)>::operator()(std::__2::unique_ptr<qstdweb::(anonymous namespace)::ThunkPool::ThunkAllocation, std::__2::default_delete<qstdweb::(anonymous namespace)::ThunkPool::ThunkAllocation>>&&)
    $qstdweb::Promise::adoptPromise(emscripten::val, qstdweb::PromiseCallbacks)
    $void qstdweb::Promise::make<emscripten::val>(emscripten::val, QString, qstdweb::PromiseCallbacks, emscripten::val)
    $QWasmClipboard::initClipboardPermissions()
    $QWasmClipboard::QWasmClipboard()
    $QWasmIntegration::QWasmIntegration()
    $QWasmIntegrationPlugin::create(QString const&, QList<QString> const&)
    $QPlatformIntegrationPlugin::create(QString const&, QList<QString> const&, int&, char**)
    $QPlatformIntegrationFactory::create(QString const&, QList<QString> const&, int&, char**, QString const&)
    $init_platform(QString const&, QString const&, QString const&, int&, char**)
    $QGuiApplicationPrivate::createPlatformIntegration()
    $QGuiApplicationPrivate::createEventDispatcher()
    $QApplicationPrivate::createEventDispatcher()
    $QCoreApplicationPrivate::init()
    $QGuiApplicationPrivate::init()
    $QApplicationPrivate::init()
    $QApplication::QApplication(int&, char**, int)
    $MixxxApplication::MixxxApplication(int&, char**)
    $main
    

    My question is whether there is some way to avoid having QApplication perform such async operations internally, specifically if e.g. the clipboard initialization could be deferred or disabled, ideally without having to rearchitect the Mixxx side too much?

    I am pretty new to the Qt/Wasm backend, so any help would be greatly appreciated.

    F 1 Reply Last reply 8 Mar 2024, 03:29
    0
    • F fwcd
      8 Mar 2024, 01:23

      I am currently porting a moderately-sized Qt app to the web (Mixxx) and have found that enabling -sASSERTIONS (with Qt 6.6.2) will crash the app at launch with

      mixxx.js:12662 Aborted(Assertion failed: Cannot have multiple async operations in flight at once)
      

      The issue seems to be that Mixxx's own asynchronous operations (mostly QDialog::exec) seem to clash with QWasmClipboard::initClipboardPermissions, which is invoked internally during QApplication's initialization:

      abort
      assert
      whenDone
      promiseCallbackFinally2
      Promise.finally (async)		
      methodCaller<(emscripten::val) => emscripten::val>
      __emval_call_method
      imports.<computed>
      $std::__2::__function::__func<qstdweb::(anonymous namespace)::WebPromiseManager::adoptPromise(emscripten::val, qstdweb::PromiseCallbacks)::$_0, std::__2::allocator<qstdweb::(anonymous namespace)::WebPromiseManager::adoptPromise(emscripten::val, qstdweb::PromiseCallbacks)::$_0>, void (std::__2::unique_ptr<qstdweb::(anonymous namespace)::ThunkPool::ThunkAllocation, std::__2::default_delete<qstdweb::(anonymous namespace)::ThunkPool::ThunkAllocation>>)>::operator()(std::__2::unique_ptr<qstdweb::(anonymous namespace)::ThunkPool::ThunkAllocation, std::__2::default_delete<qstdweb::(anonymous namespace)::ThunkPool::ThunkAllocation>>&&)
      $qstdweb::Promise::adoptPromise(emscripten::val, qstdweb::PromiseCallbacks)
      $void qstdweb::Promise::make<emscripten::val>(emscripten::val, QString, qstdweb::PromiseCallbacks, emscripten::val)
      $QWasmClipboard::initClipboardPermissions()
      $QWasmClipboard::QWasmClipboard()
      $QWasmIntegration::QWasmIntegration()
      $QWasmIntegrationPlugin::create(QString const&, QList<QString> const&)
      $QPlatformIntegrationPlugin::create(QString const&, QList<QString> const&, int&, char**)
      $QPlatformIntegrationFactory::create(QString const&, QList<QString> const&, int&, char**, QString const&)
      $init_platform(QString const&, QString const&, QString const&, int&, char**)
      $QGuiApplicationPrivate::createPlatformIntegration()
      $QGuiApplicationPrivate::createEventDispatcher()
      $QApplicationPrivate::createEventDispatcher()
      $QCoreApplicationPrivate::init()
      $QGuiApplicationPrivate::init()
      $QApplicationPrivate::init()
      $QApplication::QApplication(int&, char**, int)
      $MixxxApplication::MixxxApplication(int&, char**)
      $main
      

      My question is whether there is some way to avoid having QApplication perform such async operations internally, specifically if e.g. the clipboard initialization could be deferred or disabled, ideally without having to rearchitect the Mixxx side too much?

      I am pretty new to the Qt/Wasm backend, so any help would be greatly appreciated.

      F Offline
      F Offline
      fwcd
      wrote on 8 Mar 2024, 03:29 last edited by
      #2

      For testing I have patched out QWasmClipboard::initClipboardPermissions and bootstrapCheckPermissions (which also spawns async operations), now I am getting the same error for qtStdWebEventCallbackActivate, which looks like this bug:

      • https://github.com/emscripten-core/emscripten/issues/18412
      • https://bugreports.qt.io/browse/QTBUG-102827
      1 Reply Last reply
      0

      1/2

      8 Mar 2024, 01:23

      • Login

      • Login or register to search.
      1 out of 2
      • First post
        1/2
        Last post
      0
      • Categories
      • Recent
      • Tags
      • Popular
      • Users
      • Groups
      • Search
      • Get Qt Extensions
      • Unsolved