Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Error sending from webFrameMain: Error: Render frame was disposed before WebFrameMain could be accessed #834

Open
t-klein1 opened this issue Dec 15, 2023 · 1 comment

Comments

@t-klein1
Copy link

Tropy crashs with this error when I import more than ~10 photos at once:

Error sending from webFrameMain:  Error: Render frame was disposed before WebFrameMain could be accessed
    at s.send (node:electron/js2c/browser_init:2:94175)
    at _.send (node:electron/js2c/browser_init:2:79325)
    at BrowserWindow.<anonymous> (/opt/tropy/resources/app.asar/lib/browser/main-8pZe55Aw.js:16954:23)
    at BrowserWindow.emit (node:events:525:35)
Error sending from webFrameMain:  Error: Render frame was disposed before WebFrameMain could be accessed
    at s.send (node:electron/js2c/browser_init:2:94175)
    at _.send (node:electron/js2c/browser_init:2:79325)
    at /opt/tropy/resources/app.asar/lib/browser/main-8pZe55Aw.js:16310:38
    at Function.from (<anonymous>)
    at WindowManager.map (/opt/tropy/resources/app.asar/lib/browser/main-8pZe55Aw.js:16580:18)
    at WindowManager.each (/opt/tropy/resources/app.asar/lib/browser/main-8pZe55Aw.js:16449:17)
    at WindowManager.broadcast (/opt/tropy/resources/app.asar/lib/browser/main-8pZe55Aw.js:16310:10)
    at Object.observe (/opt/tropy/resources/app.asar/lib/browser/main-8pZe55Aw.js:20404:17)
    at IOQ.idle (/opt/tropy/resources/app.asar/lib/browser/main-8pZe55Aw.js:17043:13)
    at Timeout._onTimeout (/opt/tropy/resources/app.asar/lib/browser/main-8pZe55Aw.js:17008:32)
Error sending from webFrameMain:  Error: Render frame was disposed before WebFrameMain could be accessed
    at s.send (node:electron/js2c/browser_init:2:94175)
    at _.send (node:electron/js2c/browser_init:2:79325)
    at /opt/tropy/resources/app.asar/lib/browser/main-8pZe55Aw.js:16310:38
    at Function.from (<anonymous>)
    at WindowManager.map (/opt/tropy/resources/app.asar/lib/browser/main-8pZe55Aw.js:16580:18)
    at WindowManager.each (/opt/tropy/resources/app.asar/lib/browser/main-8pZe55Aw.js:16449:17)
    at WindowManager.broadcast (/opt/tropy/resources/app.asar/lib/browser/main-8pZe55Aw.js:16310:10)
    at Object.observe (/opt/tropy/resources/app.asar/lib/browser/main-8pZe55Aw.js:20404:17)
    at IOQ.activate (/opt/tropy/resources/app.asar/lib/browser/main-8pZe55Aw.js:17029:27)
    at Timeout._onTimeout (/opt/tropy/resources/app.asar/lib/browser/main-8pZe55Aw.js:17007:31)
Error sending from webFrameMain:  Error: Render frame was disposed before WebFrameMain could be accessed
    at s.send (node:electron/js2c/browser_init:2:94175)
    at _.send (node:electron/js2c/browser_init:2:79325)
    at BrowserWindow.<anonymous> (/opt/tropy/resources/app.asar/lib/browser/main-8pZe55Aw.js:16954:23)
    at BrowserWindow.emit (node:events:525:35)
Error sending from webFrameMain:  Error: Render frame was disposed before WebFrameMain could be accessed
    at s.send (node:electron/js2c/browser_init:2:94175)
    at _.send (node:electron/js2c/browser_init:2:79325)
    at BrowserWindow.<anonymous> (/opt/tropy/resources/app.asar/lib/browser/main-8pZe55Aw.js:16954:23)
    at BrowserWindow.emit (node:events:525:35)

The OS is Ubuntu 22.04.3 and it gets used via RDP over SSH

The version is 1.15.2 x64, I downloaded the release from the the website, it has worked before but stopped a week ago

@inukshuk
Copy link
Member

I've seen this crash on some Linux distros before. My guess is that it happens due to some incompatibility of the system libraries and the static libvips build that's bundled with Tropy (this contains a lot of libs which are also dynamically linked to by Electron and so it's likely that the crash is caused in some way by different versions of these libraries clashing somehow). We haven't been able to track it down, but one workaround would be to use the flatpak version instead -- this comes with libvips dynamically linked against the system libs in the container and doesn't have this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants