Inspiring

Critical Issue: Photoshop 2025 Crashes When Using Web Assembly-Based Plugins

Forum|Forum|1 year ago
November 17, 2024
17 replies
4255 views

System Details:

Operating System: Windows 10 Home, Version 22H2 (Build 19045.5131)
Photoshop Version: 26.0.0
UXP Developer Tools Version: 2.0.2.3

I am writing to report a significant issue with Photoshop 2025 that renders it non-operative for WebAssembly-based plugin development. As a developer with newly acquired experience in Adobe UXP and significant investment in plugin creation, I must express my deep frustration regarding this problem.

Description of the Issue

I have developed a complex plugin where the core functional code is written in C++ and compiled to WebAssembly using Emscripten to run within the UXP environment. To verify the issue, I have also created a simplified plugin that reproduces the crash consistently.

While the (simple) plugin loads successfully in UXP Developer Tools, and the application panel appears as expected, clicking the "Process" button in Photoshop 2025 causes the application to crash. This issue is specific to Photoshop 2025, as the same plugin functions without any problems in Photoshop 2024. If the plugin is developed and packaged under Photoshop 2024 then it still crashes when loaded and initiated under 2025.

The details of the crash are included below for reference.

Impact

This issue has severe implications for WebAssembly-based plugin developers:

After months of dedicated effort, I find myself unable to deliver a functional plugin for the latest version of Photoshop.
The inability to support Photoshop 2025 undermines my ability to market the plugin effectively once development has been completed.
This situation discourages innovation and development within the Adobe plugin ecosystem.

Supporting Evidence

This issue is corroborated by reports from another developer:

Related discussion: UXP Plugin Crashes with WASM in Photoshop 2025
Related technical problem I raised: Dependency Wasm.Instantiate Error

Crash Report Summary

The crash is identified as EXCEPTION_ACCESS_VIOLATION with exception code 0xc0000005. Key details from the crash report are listed, highlighting repeated instances of napi_unwrap in the stack trace, which appears to be a critical point of failure.

Request for Resolution

I urge Adobe to prioritize resolving this issue promptly. Developers like myself rely on Photoshop’s stability and forward compatibility to bring innovative solutions to the market.

Despite my frustration, I appreciate Adobe's commitment to supporting its developer community and hope this issue can be addressed swiftly to restore confidence in the platform.

Thank you for your attention to this matter.

Details of crash:

Adobe Photoshop has encountered a problem and needs to close.

Report;

<?xml version="1.0"?>

<!DOCTYPE AdobeCrashReport SYSTEM "AdobeCrashReporter.dtd">

<gpu>

</gpu>

</thread>

</backtrace>

</registerSet>

M

Michele3207419270yy

Participant

Yes, the emscripten flags I mentioned does exactly that

Y

YuzukiAnri

Participant

I eventually discovered that there were bugs in the WebAssembly.instantaneous and WebAssembly.compile functions on the Photoshop 2025 version, which have a high probability of crashing in the presence of asynchronous threads.

We can use the following code to easily reproduce it:

const sleep = () => new Promise(r => setTimeout(r, 50))
for (let i = 0; i < 1000; i++) {
  await sleep()
  WebAssembly.instantiate(new Uint8Array([0, 97, 115, 109, 1, 0, 0, 0, 1, 4, 1, 96, 0, 0, 3, 2, 1, 0, 10, 30, 1, 28, 0, 65, 0, 253, 15, 253, 12, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 253, 186, 1, 26, 11]))
}

However, using the following code to initialize Wasm will not cause a crash:

const module = new WebAssembly.Module(new Uint8Array([...]))
const instance = new WebAssembly.Instance(module)

Therefore, I personally speculate that it may be due to some memory fields in Photoshop causing concurrent read and write errors when loading WASM.

Why did this cause the asynchronous method to load WASM to be very slow on Photoshop 2024 and earlier versions, and crash directly in 2025.

M

Michele3207419270yy

Participant

-sEMBIND_AOT=1 -sDYNAMIC_EXECUTION=0 -sWASM_ASYNC_COMPILATION=0

https://github.com/michelerenzullo/WasmUXP

The flags above are to fix the issue with dynamic loading of the JS code since UXP for security reasons doesn't allow that feature. Doing this should fix the problem, you can have a look at my boilerplate repository. Regards, Michele Renzullo

T

terence21981657g3ekAuthor

Inspiring

A solution has been identified above which remains valid. (To double check, I have just completed a successful run). It is not clear to me that you are leveraging this solution. At present this seems to be the only approach that people have had success with.

Y

YuzukiAnri

Participant

I compiled the cpp code into a standalone wasm and manually called WebAssembly.instantiate to load it, but the same error still occurred in the latest version of Photoshop.

import { env, type FaceObject } from 'retinaface-wasm'

// eslint-disable-next-line @typescript-eslint/no-var-requires
const { storage: { localFileSystem: fs, formats } } = require('uxp')

const loadModel = () => {
  // retinaface-simd.wasm from https://cdn.jsdelivr.net/npm/retinaface-wasm@0.2.5/wasm/retinaface-simd.wasm
  const file = await (await fs.getPluginFolder()).getEntry('wasm/retinaface-simd.wasm') as FileEntry
  return (await WebAssembly.instantiate(await file.read({ format: formats.binary }), env)).instance  // CRASHED HERE :(
}

const model = await loadModel()

In addition, my compilation configuration (link_options) is:

-Os -s WASM=1 -s INITIAL_MEMORY=256MB -s TOTAL_MEMORY=256MB -s FORCE_FILESYSTEM=1 -s STANDALONE_WASM -s WASM_ASYNC_COMPILATION=0 --no-entry

https://github.com/ShirasawaSama/retinaface-wasm/blob/main/CMakeLists.txt#L27

I am looking forward to your reply very much.

T

terence21981657g3ekAuthor

Inspiring

sttk3 wrote "It certainly does not crash on 2024 and does crash on 2025". Adobe has discontinued the availability of Photoshop 2024 which is unhelpful under the circumstances. The fix for Photoshop 2025 remains valid.

T

terence21981657g3ekAuthor

Inspiring

Thank you very much, Michele. I have implemented the solution and I agree that, with the proposed amendments, the Web Assembly plugin now runs on Photoshop 2024 (V 25.12.1), on Photoshop 2025 (V 26.20) and on Photoshop Beta (V 26.30).

Just to clarify, the required amendments are as follows.

The command prompt input previously suggested, in the comments in the TestPlugin_cpp.txt (above), should now be augmented to include the sequence …. -s WASM=1 -s WASM_ASYNC_COMPILATION=0 -s MODULARIZE=1 …… In the index.js file (as derived from the file index_js.txt that I attached above), the function loadWasm should be amended to read as given by Michele. (The line ‘name(Module)’ might require amendment to align with the command element -s EXPORT_NAME="name".)

Thank you again Michele.

COMMENT: This solution may also be relevant to the issue 'UXP Plugin Crashes' with WASM in Photoshop 2025 referenced above. However, I am not able to post there. The rules seem to be that one cannot post three entries in a row, instead one is expected to edit an existing post. However, my existing posts have extended beyond the deadline where they are editable. .... Stalemate!!

FURTHER COMMENT: On the Creative Cloud Developer Forum, under 'Wasm Instantiate Error', I mentioned that I have co-ordinated with another GitHub user to develop a web app which offers an improved implementation of Match Color and that he and I are working to now make this available as a Photoshop plugin together with other original processing methods. That other GitHub user is Michele Renzullo who has posted above under the user name Michele1835. His GitHub account offers additional insights into his understanding of this issue.

M

Michele1835

Participant

Hi Erin,

I confirm that the issue mentioned by Terry is solved, and probably related to what the other developer mentioned but not because of emscripten (older version of emscripten doesn't make the difference, rather the new V8 engine or UXP new security level implemented by Adobe in PS 2025), the issue appear to be the wasm async instantiation made by the js code of emscripten, disabling this feature, and providing manually the binary solve the problem. so flag

-sWASM_ASYNC_COMPILATION=0

and in the index.js

let wasmModule;
async function loadWasm() {
    return new Promise((resolve, reject) => {
        const script = document.createElement("script");
        script.src="TestPlugin.js";
        script.onload = async () => {
            try {
                const response = await fetch("TestPlugin.wasm");
                const wasmBinary = await response.arrayBuffer();

                // Initialize the Module with the wasmBinary
                const Module = {
                    wasmBinary: wasmBinary, // here the magic
                    onRuntimeInitialized: () => resolve(Module),
                };

                MyTestPlugin(Module);
            } catch (error) {
                reject(error);
            }
        };

        script.onerror = reject;
        document.head.appendChild(script);
    });
}

erinferinferinf

Adobe Employee

Issue not resolved on new update (version 26.2).
By @terence21981657g3ek

Hi Terrence,

I appreciate the time and effort you've put into developing your hybrid UXP plugin using WebAssembly (WASM).

I'd like to clarify that while there was a WASM sample in our official repository, but it was created by (effectively) a summer intern (technically an MLH Fellow) and was never officially supported or communicated as a stable feature. This sample was intended to showcase UXP's potential, but it has always been somewhat buggy, especially on ARM devices. (For example, I cancelled a blog post about it because I couldn't get the sample to run.)

Currently, our UXP team does not test or officially support WASM. It's possible that recent updates, such as the V8 upgrade, have further impacted the functionality of WASM plugins.

There is a roadmap item to investigate WASM support in the latter half of next year (H2 2025). However, until then, we cannot guarantee any fixes or improvements for WASM-based plugins.

We have heard of a developer in the community who has a WASM plugin running with Photoshop 2025, who said, in a loose quote here "new emscripten versions load differently". He hasn't gotten back to us.

We appreciate your understanding and patience.

T

terence21981657g3ekAuthor

Inspiring

Issue not resolved on new update (version 26.2).

Show more replies

Sign up

To post, reply, or follow discussions, please sign in with your Adobe ID.

Sign in to Adobe Community

To post, reply, or follow discussions, please sign in with your Adobe ID.

Scanning file for viruses.

This file cannot be downloaded