sharp 0.34.3 + Electron with memory cage + Windows : possible race condition/crash when reading image metadata containing XMP

[TomaterID]

Possible bug

I have updated my application to sharp 0.34.3 and started to receieve a lot of crash dumps realated to libvips. It did not happen before (on 33.3), at least not on this scale. Now almost half of all crash dumps are caused by libvips.

Typical crash dump looks like that:

This dump file has an exception of interest stored in it.
The stored exception information can be accessed via .ecxr.
(6fe8.58bc): Access violation - code c0000005 (first/second chance not available)
For analysis of this file, run !analyze -v
*** WARNING: Unable to verify checksum for ntdll.dll
*** WARNING: Unable to verify checksum for KERNELBASE.dll
ntdll!NtDelayExecution+0x14:
00007ffa`ee94db74 c3              ret
0:000> cdb: Reading initial command 'lm f m tonfotos; ~#kv; q'
start             end                 module name
00007ff7`a65a0000 00007ff7`affc5000   tonfotos C:\Users\sayna\AppData\Local\tonfotos\app-1.13.7\tonfotos.exe
Child-SP          RetAddr               : Args to Child                                                           : Call Site
00000001`29ffbd88 00007ffa`ec2062ce     : 00000001`29ffbe48 00007ff7`a9df32be 000002c7`0567cbe5 0000a907`38223dc3 : ntdll!NtDelayExecution+0x14
*** WARNING: Unable to verify checksum for tonfotos.exe
00000001`29ffbd90 00007ff7`ac071387     : 00000000`3f800000 0000497c`00000000 0000497c`c00000bb 00000000`00000000 : KERNELBASE!SleepEx+0x9e
00000001`29ffbe30 00007ffa`ec2eca77     : 00000000`00000000 00007ff7`ac0712c0 00000000`00000000 00000001`29ffcdb0 : tonfotos!crashpad::`anonymous namespace'::UnhandledExceptionHandler+0xc7 [C:\projects\src\third_party\crashpad\crashpad\client\crashpad_client_win.cc @ 186]
00000001`29ffbfb0 00007ffa`ee955818     : 00000001`29ffc1f0 00007ffa`ee9f6e8c 00000000`00000000 00000001`29ffc188 : KERNELBASE!UnhandledExceptionFilter+0x1e7
00000001`29ffc0d0 00007ffa`ee93ce46     : 00007ffa`eea2473c 00007ffa`ee8b0000 00000001`29ffc1f0 00007ffa`ee8e0e7b : ntdll!memset+0x1218
00000001`29ffc110 00007ffa`ee9528bf     : 00000000`00000000 00000001`29ffc6f0 00000001`29ffcdb0 00000000`00000000 : ntdll!_C_specific_handler+0x96
00000001`29ffc180 00007ffa`ee902554     : 00000000`00000000 00000001`29ffc6f0 00000001`29ffcdb0 00000000`00000000 : ntdll!_chkstk+0x11f
00000001`29ffc1b0 00007ffa`ee9513ce     : 000002c7`01003a79 0000497c`000dc000 00000001`29ffd008 00000000`00000000 : ntdll!RtlRaiseException+0x484
00000001`29ffc8c0 00007ffa`402a0189     : 0000497c`00038900 00007ff7`a918111b 0000497c`00150101 0000a907`38224f13 : ntdll!KiUserExceptionDispatcher+0x2e (TrapFrame @ 00000001`29ffcce8)
*** WARNING: Unable to verify checksum for libvips-42.dll
*** WARNING: Unable to verify timestamp for sharp-win32-x64.node
00000001`29ffcfe0 00007ffa`b45131a9     : 00000001`29ffd180 00007ffa`b4566a80 0000497c`00038900 00000001`29ffd208 : libvips_42!g_utf8_validate_len+0x33
00000001`29ffd040 00000001`29ffd180     : 00007ffa`b4566a80 0000497c`00038900 00000001`29ffd208 00000001`29ffd0e0 : sharp_win32_x64!MetadataWorker::OnOK+0x1179 [G:\Programming\tonfotos\node_modules\sharp\src\metadata.cc @ 265]
00000001`29ffd048 00007ffa`b4566a80     : 0000497c`00038900 00000001`29ffd208 00000001`29ffd0e0 00007ff7`a9c48c0e : 0x00000001`29ffd180
00000001`29ffd050 0000497c`00038900     : 00000001`29ffd208 00000001`29ffd0e0 00007ff7`a9c48c0e 00000001`29ffd0e0 : sharp_win32_x64!sharp::vipsWarningsMutex
00000001`29ffd058 00000001`29ffd208     : 00000001`29ffd0e0 00007ff7`a9c48c0e 00000001`29ffd0e0 00000001`29ffd098 : 0x0000497c`00038900
00000001`29ffd060 00000001`29ffd0e0     : 00007ff7`a9c48c0e 00000001`29ffd0e0 00000001`29ffd098 0000497c`0015c008 : 0x00000001`29ffd208
00000001`29ffd068 00007ff7`a9c48c0e     : 00000001`29ffd0e0 00000001`29ffd098 0000497c`0015c008 0000497c`00038900 : 0x00000001`29ffd0e0
00000001`29ffd070 0000a907`38225083     : 00007ffa`b45594d8 aaaaaaaa`aaaaaaaa 00000001`29ffd2a8 0000497c`00167980 : tonfotos!v8::TryCatch::~TryCatch+0x3e [C:\projects\src\v8\src\api\api.cc @ 2948]
00000001`29ffd0e0 00007ffa`b45594d8     : aaaaaaaa`aaaaaaaa 00000001`29ffd2a8 0000497c`00167980 00000000`00000000 : 0x0000a907`38225083
00000001`29ffd0e8 aaaaaaaa`aaaaaaaa     : 00000001`29ffd2a8 0000497c`00167980 00000000`00000000 00000001`29ffd2f0 : sharp_win32_x64!std::_Func_impl_no_alloc<<lambda_dd37503228a68a6e956b63afac12f7e1>,void,void *,char *>::`vftable'
00000001`29ffd0f0 00000001`29ffd2a8     : 0000497c`00167980 00000000`00000000 00000001`29ffd2f0 0000497c`000dc000 : 0xaaaaaaaa`aaaaaaaa
00000001`29ffd0f8 0000497c`00167980     : 00000000`00000000 00000001`29ffd2f0 0000497c`000dc000 00000000`00000000 : 0x00000001`29ffd2a8
00000001`29ffd100 00000000`00000000     : 00000001`29ffd2f0 0000497c`000dc000 00000000`00000000 00000000`0198405d : 0x0000497c`00167980
quit:
NatVis script unloaded from 'C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\Visualizers\atlmfc.natvis'
NatVis script unloaded from 'C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\Visualizers\ObjectiveC.natvis'
NatVis script unloaded from 'C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\Visualizers\concurrency.natvis'
NatVis script unloaded from 'C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\Visualizers\cpp_rest.natvis'
NatVis script unloaded from 'C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\Visualizers\stl.natvis'
NatVis script unloaded from 'C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\Visualizers\Windows.Data.Json.natvis'
NatVis script unloaded from 'C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\Visualizers\Windows.Devices.Geolocation.natvis'
NatVis script unloaded from 'C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\Visualizers\Windows.Devices.Sensors.natvis'
NatVis script unloaded from 'C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\Visualizers\Windows.Media.natvis'
NatVis script unloaded from 'C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\Visualizers\windows.natvis'
NatVis script unloaded from 'C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\Visualizers\winrt.natvis'

I will be happy to provide more information if I can.

Is this a possible bug in a feature of sharp, unrelated to installation?

• Running npm install sharp completes without error.
• Running node -e "require('sharp')" completes without error.

Are you using the latest version of sharp?

• I am using the latest version of sharp as reported by npm view sharp dist-tags.latest.

What is the output of running npx envinfo --binaries --system --npmPackages=sharp --npmGlobalPackages=sharp?

  System:
    OS: Windows 10 10.0.19045
    CPU: (20) x64 Intel(R) Core(TM) i9-7900X CPU @ 3.30GHz
    Memory: 45.81 GB / 63.69 GB
  Binaries:
    Node: 18.20.2 - C:\Program Files\nodejs\node.EXE      
    npm: 10.5.0 - C:\Program Files\nodejs\npm.CMD
  npmPackages:
    sharp: ^0.34.3 => 0.34.3

Does this problem relate to file caching?

The default behaviour of libvips is to cache input files, which can lead to EBUSY or EPERM errors on Windows.
Use sharp.cache(false) to switch this feature off.

• Adding sharp.cache(false) does not fix this problem.

I did not try but I don't think this is somehow related.

Does this problem relate to images appearing to have been rotated by 90 degrees?

No, this is unrelated to rotation.

What are the steps to reproduce?

This is happening on users side. There is no way to know what happened before crash.

What is the expected behaviour?

Should not crash.

Please provide a minimal, standalone code sample, without other dependencies, that demonstrates this problem

Sorry, not possible. Happens randomly on the user side.

Please provide sample image(s) that help explain this problem

Sorry, not possible. We don't steal people personal data.

[lovell]

Thanks for the detailed report. The salient line of the backtrace is:

0000000129ffcfe0 00007ffab45131a9 : 0000000129ffd180 00007ffab4566a80 0000497c00038900 0000000129ffd208 : libvips_42!g_utf8_validate_len+0x33

https://github.com/lovell/sharp/blob/45f871790057017a42647d3a47f925a84541c9c5/src/metadata.cc#L265C1-L265C97

Do you see this only when run inside Electron? If so think this might relate to its memory cage (ironically a "safety" feature) resulting in the XMP metadata being freed before the utf-8 validation takes place.

[lovell]

Are you able to test the following patch?

--- a/src/metadata.cc
+++ b/src/metadata.cc
@@ -261,11 +261,11 @@ class MetadataWorker : public Napi::AsyncWorker {
         info.Set("iptc", Napi::Buffer<char>::NewOrCopy(env, baton->iptc, baton->iptcLength, sharp::FreeCallback));
       }
       if (baton->xmpLength > 0) {
-        info.Set("xmp", Napi::Buffer<char>::NewOrCopy(env, baton->xmp, baton->xmpLength, sharp::FreeCallback));
         if (g_utf8_validate(static_cast<char const *>(baton->xmp), baton->xmpLength, nullptr)) {
           info.Set("xmpAsString",
             Napi::String::New(env, static_cast<char const *>(baton->xmp), baton->xmpLength));
         }
+        info.Set("xmp", Napi::Buffer<char>::NewOrCopy(env, baton->xmp, baton->xmpLength, sharp::FreeCallback));
       }
       if (baton->tifftagPhotoshopLength > 0) {
         info.Set("tifftagPhotoshop",

[TomaterID]

All my usage of sharp is inside electron, so yes, I see this inside electron.

I am not sure how to go about testing this patch. I don't build libvips from sources on my end, only sharp (and that part only remained from the time when we were hunting for other bug inside sharp, and now it is unnecessary).

Can I please get compiled version with the patch somehow? I wil try then to update my build system so it would replace libvips with patched version in my distribution file.

I have maintenance release planned for today, but I can push it till to morrow if you can provide me with patched dll. The next release window will be roughly in two weeks.. Since this is only happens on user side, we will need to release it and then check the crash dumps statistics, only then we will see if it helped or not.

[lovell]

Thanks for confirming this is Electron only, I'm pretty confident this relates to memory being freed earlier than expected due to the need to copy Buffers into its "memory cage" (rather than reference the same memory as Node.js quite happily continues to do).

I've added the fix via commit d8686e7 and this will be part of v0.34.4.

[Bilb]

Hey, I am also impacted by this issue I believe.
Any ideas when 0.34.4 is going to be released? I have tried downgrading to 0.33.3 but I have some performance issues when processing images.
Thanks a lot

[Bilb]

Here is a part of the dump I have:

Operating system: Linux
                  6.1.0 -39-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.148-1 (2025-08-26) x86_64
CPU: amd64
     family 20 model 1 stepping 0
     2 CPUs

GPU: UNKNOWN

Crash reason:  SIGILL / ILL_ILLOPN
Crash address: 0x7f02c4d3edbd
Process uptime: 990 seconds

Thread 16 (crashed)
 0  libvips-cpp.so.8.17.1 + 0x33edbd
    rax = 0x000000005e2f3160   rdx = 0x0000000000000000
    rcx = 0x000000002cc8e9a0   rbx = 0x00007f02c55db3cb
    rsi = 0x00007f02c55db3cb   rdi = 0x00007f02c55db3e6
    rbp = 0x00007f032edd703c   rsp = 0x00007f032edd6fe0
     r8 = 0x0000000000000020    r9 = 0x0000000000000000
    r10 = 0x00007f048ab875f8   r11 = 0x00007f048ac03260
    r12 = 0x00007ffe33099788   r13 = 0x0000000000000000
    r14 = 0x0000251c0b896df0   r15 = 0x0000000000000000
    rip = 0x00007f02c4d3edbd
    Found by: given as instruction pointer in context
 1  libvips-cpp.so.8.17.1 + 0xbdb3cb
    rbp = 0x00007f032edd703c   rsp = 0x00007f032edd7008
    rip = 0x00007f02c55db3cb

Let me know if you think that's a different so I can create another issue

[lovell]

@Bilb Are you using Electron and does this only occur when calling metadata() with an image that contains XMP metadata? Are you able to provide a backtrace (as the original post contains)?