Vips (Windows binary) seems to be stuck in loop forever #4690

IgelCampus · 2025-10-08T09:06:50Z

IgelCampus
Oct 8, 2025

We are executing the Windows command line executable in parallel and sometimes the vips.exe never returns from the conversion but seems to stall. Running the exact same command line on the exact same asset later again works fine as expected.

The requested operation is generating a small jpeg from a bigger jpg image.

This happens on all modern Windows version including 10, 11 and recent Server versions.

Is there any way to tackle this in some way?

Screenshots

You can see here how several stalled vips.exe processes are effectively blocking the entire machine and look at the CPU-time column for the accumulated runtime of these processes.

lovell · 2025-10-08T10:56:54Z

lovell
Oct 8, 2025
Maintainer

The screenshot only includes partial command line but it looks like temporary files are being used, which could suggest this is a filesystem-related thing e.g. files disappearing, moving or being overwritten during processing.

To be able to help further, we'll need complete steps to reproduce, e.g. a shell script that consistently creates the scenario.

0 replies

IgelCampus · 2025-10-08T15:32:31Z

IgelCampus
Oct 8, 2025
Author

I can reproduce this with some command line scripting.
When extracting the attached archive into c:\vips you will find the test image, the used icc profile and the source code of the test application which can be executed (requires Java 21) with C:\vips>java --source 21 --enable-preview test.java
The test is self-contained as all test files are created/deleted in the c:\vips\tmp directory.
You can adjust the number of cpu cores and test rounds in the source file via the according constants. You need to adjust the location of the vips.exe binary in the test source as well. The vips I am testing with contains the content of the vips-dev-8.17\bin directory from the vips-dev-w64-all-8.17.2.zip release zip. The other directories from the release zip have been removed as they don't need to be necessary for vips to run.
On my test machine with 16 cores it needs to run for almost an hour until the first non-returning vips.exe can be observed.
vips.zip

1 reply

kleisauke Oct 8, 2025
Maintainer

Ouch, waiting nearly an hour just to hit the hang makes reproducing tricky. It might be worth inspecting the hanging process with https://github.com/winsiderss/systeminformer to see if a stack trace is available.

I'll take a look at this tomorrow. In the meantime, could you also reproduce this using vips-dev-w64-web-8.17.2-static.zip? That contains only the file format loaders that have been carefully tested and which are commonly used on the web. It's also linked against a single shared libvips DLL, which might help avoid potential DLL conflicts.

IgelCampus · 2025-10-09T08:40:22Z

IgelCampus
Oct 9, 2025
Author

I tried the recommended static version and this produced the issue on the first try within seconds after starting the test script.
I could also grab several stack traces from different vips processes running into the issue in that run:

0, ntdll.dll!RtlpLowFragHeapAllocFromContext+0x723
1, ntdll.dll!RtlpAllocateHeapInternal+0x9a7
2, ucrtbase.dll!_calloc_base+0x4e
3, ucrtbase.dll!__acrt_getptd+0x85
4, ucrtbase.dll!_configthreadlocale+0xd
5, libvips-42.dll!g_atomic_rc_box_get_size+0x11d69f
6, libvips-42.dll!g_unichar_break_type+0x52b82
7, libvips-42.dll!g_atomic_rc_box_get_size+0xe3a0d
8, libvips-42.dll!g_atomic_rc_box_get_size+0x11e2c1
9, libvips-42.dll!g_atomic_rc_box_get_size+0xc47aa
10, libvips-42.dll!g_atomic_rc_box_get_size+0x11d4f0
11, ucrtbase.dll!<lambda_f03950bc5685219e0bcd2087efbe011e>::operator()+0xa6
12, ucrtbase.dll!__crt_seh_guarded_call<int>::operator()<<lambda_7777bce6b2f8c936911f934f8298dc43>,<lambda_f03950bc5685219e0bcd2087efbe011e> &,<lambda_3883c3dff614d5e0c5f61bb1ac94921c> >+0x3b
13, ucrtbase.dll!execute_onexit_table+0x34
14, libvips-42.dll+0x10a8
15, libvips-42.dll+0x127d
16, ntdll.dll!LdrpCallInitRoutine+0x61
17, ntdll.dll!LdrShutdownProcess+0x22a
18, ntdll.dll!RtlExitUserProcess+0xad
19, kernel32.dll!ExitProcessImplementation+0xb
20, ucrtbase.dll!exit_or_terminate_process+0x44
21, ucrtbase.dll!common_exit+0x6f
22, vips.exe+0x138a
23, vips.exe+0x13a6
24, kernel32.dll!BaseThreadInitThunk+0x14
25, ntdll.dll!RtlUserThreadStart+0x21

0, ntdll.dll!RtlpLowFragHeapAllocFromContext+0x6c2
1, ntdll.dll!RtlpAllocateHeapInternal+0x9a7
2, ucrtbase.dll!_calloc_base+0x4e
3, ucrtbase.dll!__acrt_GetLocaleInfoA+0x6f
4, ucrtbase.dll!initialize_lc_time+0x184
5, ucrtbase.dll!__acrt_locale_initialize_time+0x41
6, ucrtbase.dll!_wsetlocale_set_cat+0x15f
7, ucrtbase.dll!_wsetlocale_nolock+0x101
8, ucrtbase.dll!<lambda_ffc046909424fd52df0ac47e64813305>::operator()+0x3a
9, ucrtbase.dll!__crt_seh_guarded_call<void>::operator()<<lambda_1d892b297fdedeee07ed8124eeb2f2fa>,<lambda_ffc046909424fd52df0ac47e64813305> &,<lambda_01a7098693036236037e7cdb9bca3d73> >+0x3b
10, ucrtbase.dll!<lambda_2a444430fde8c29194d880d93eed5e8f>::operator()+0x80
11, ucrtbase.dll!__crt_seh_guarded_call<void>::operator()<<lambda_e9338f07fe435327d97d4ef86149e64d>,<lambda_2a444430fde8c29194d880d93eed5e8f> &,<lambda_02db5278e8aef8b5e4976579d73f5304> &>+0x15
12, ucrtbase.dll!_wsetlocale+0x106
13, ucrtbase.dll!<lambda_2116bde18c9e5f34230805ea4a4660ed>::operator()+0xae
14, ucrtbase.dll!__crt_seh_guarded_call<char *>::operator()<<lambda_e9ce07acdb0b138e546925ae9f1a2c9c>,<lambda_2116bde18c9e5f34230805ea4a4660ed> &,<lambda_5d037afbfc54bf1ca80d3d1ee4062886> >+0x3b
15, ucrtbase.dll!setlocale+0x47
16, libvips-42.dll!g_unichar_break_type+0x52bc2
17, libvips-42.dll!g_atomic_rc_box_get_size+0xe3a0d
18, libvips-42.dll!g_atomic_rc_box_get_size+0x11e2c1
19, libvips-42.dll!g_atomic_rc_box_get_size+0xc47aa
20, libvips-42.dll!g_atomic_rc_box_get_size+0x11d4f0
21, ucrtbase.dll!<lambda_f03950bc5685219e0bcd2087efbe011e>::operator()+0xa6
22, ucrtbase.dll!__crt_seh_guarded_call<int>::operator()<<lambda_7777bce6b2f8c936911f934f8298dc43>,<lambda_f03950bc5685219e0bcd2087efbe011e> &,<lambda_3883c3dff614d5e0c5f61bb1ac94921c> >+0x3b
23, ucrtbase.dll!execute_onexit_table+0x34
24, libvips-42.dll+0x10a8
25, libvips-42.dll+0x127d
26, ntdll.dll!LdrpCallInitRoutine+0x61
27, ntdll.dll!LdrShutdownProcess+0x22a
28, ntdll.dll!RtlExitUserProcess+0xad
29, kernel32.dll!ExitProcessImplementation+0xb
30, ucrtbase.dll!exit_or_terminate_process+0x44
31, ucrtbase.dll!common_exit+0x6f
32, vips.exe+0x138a
33, vips.exe+0x13a6
34, kernel32.dll!BaseThreadInitThunk+0x14
35, ntdll.dll!RtlUserThreadStart+0x21

10 replies

IgelCampus Oct 9, 2025
Author

I have changed my Regional Settings to English (US) now and will try again.

This didn't help. It still created hanging instances.

kleisauke Oct 9, 2025
Maintainer

I could also grab several stack traces from different vips processes running into the issue in that run:
[...]

Converting this address-based + partial-symbol trace (which happens when PDBs aren't loaded) into a fully symbolicated one produces:

Details

0, ntdll.dll!RtlpLowFragHeapAllocFromContext+0x723
1, ntdll.dll!RtlpAllocateHeapInternal+0x9a7
2, ucrtbase.dll!_calloc_base+0x4e
3, ucrtbase.dll!__acrt_getptd+0x85
4, ucrtbase.dll!_configthreadlocale+0xd
5, [/var/tmp/tmp-llvm-x86_64-w64-mingw32.static/llvm-project-21.1.1.src/libc
8000
xx/include/__locale_dir/support/windows.h @ 302] (00007ffe`eb56db90)   libvips_42!std::__1::__locale::__locale_guard::__locale_guard+0x17   |  (00007ffe`eb56dc10)   libvips_42!std::__1::__stdinbuf<char>::~__stdinbuf
6, [/var/tmp/tmp-llvm-x86_64-w64-mingw32.static/llvm-project-21.1.1.src/libcxx/src/support/win32/locale_win32.cpp @ 95] (00007ffe`eb698920)   libvips_42!std::__1::__locale::__wcrtomb+0x32   |  (00007ffe`eb6989f0)   libvips_42!std::__1::__locale::__mbsnrtowcs
7, [/var/tmp/tmp-llvm-x86_64-w64-mingw32.static/llvm-project-21.1.1.src/libcxx/src/locale.cpp @ 1395] (00007ffe`eb533ed0)   libvips_42!std::__1::codecvt<wchar_t,char,_Mbstatet>::do_unshift+0x45   |  (00007ffe`eb534030)   libvips_42!std::__1::codecvt<wchar_t,char,_Mbstatet>::do_encoding
8, [/var/tmp/tmp-llvm-x86_64-w64-mingw32.static/llvm-project-21.1.1.src/libcxx/src/std_stream.h @ 364] (00007ffe`eb56e790)   libvips_42!std::__1::__stdoutbuf<wchar_t>::sync+0x39   |  (00007ffe`eb56e820)   libvips_42!std::__1::__stdoutbuf<wchar_t>::xsputn
9, [/var/tmp/tmp-llvm-x86_64-w64-mingw32.static/llvm-project-21.1.1.src/libcxx/include/__ostream/basic_ostream.h @ 502] (00007ffe`eb514c60)   libvips_42!std::__1::basic_ostream<wchar_t,std::__1::char_traits<wchar_t> >::flush+0x52   |  (00007ffe`eb514d30)   libvips_42!std::__1::basic_ostream<wchar_t,std::__1::char_traits<wchar_t> >::~basic_ostream
10, [/var/tmp/tmp-llvm-x86_64-w64-mingw32.static/llvm-project-21.1.1.src/libcxx/src/iostream.cpp @ 133] (00007ffe`eb56d9d0)   libvips_42!`dynamic atexit destructor for 'init_the_streams'+0x28   |  (00007ffe`eb56da20)   libvips_42!std::__1::force_locale_initialization::<lambda0>::operator()
11, ucrtbase.dll!<lambda_f03950bc5685219e0bcd2087efbe011e>::operator()+0xa6
12, ucrtbase.dll!__crt_seh_guarded_call<int>::operator()<<lambda_7777bce6b2f8c936911f934f8298dc43>,<lambda_f03950bc5685219e0bcd2087efbe011e> &,<lambda_3883c3dff614d5e0c5f61bb1ac94921c> >+0x3b
13, ucrtbase.dll!execute_onexit_table+0x34
14, libvips_42!CRT_INIT+0xa8   |  (00007ffe`eaff11e0)   libvips_42!DllMainCRTStartup
15, libvips_42!DllMainCRTStartup+0x9d   |  (00007ffe`eaff1350)   libvips_42!atexit
16, ntdll.dll!LdrpCallInitRoutine+0x61
17, ntdll.dll!LdrShutdownProcess+0x22a
18, ntdll.dll!RtlExitUserProcess+0xad
19, kernel32.dll!ExitProcessImplementation+0xb
20, ucrtbase.dll!exit_or_terminate_process+0x44
21, ucrtbase.dll!common_exit+0x6f
22, vips!WinMainCRTStartup+0x38a   |  (00007ff6`d56c1390)   vips!mainCRTStartup
23, vips!mainCRTStartup+0x16   |  (00007ff6`d56c13b0)   vips!atexit
24, kernel32.dll!BaseThreadInitThunk+0x14
25, ntdll.dll!RtlUserThreadStart+0x21

Which is:
https://github.com/llvm/llvm-project/blob/llvmorg-21.1.1/libcxx/include/__locale_dir/support/windows.h#L302
https://github.com/llvm/llvm-project/blob/llvmorg-21.1.1/libcxx/src/support/win32/locale_win32.cpp#L95
https://github.com/llvm/llvm-project/blob/llvmorg-21.1.1/libcxx/src/locale.cpp#L1395
https://github.com/llvm/llvm-project/blob/llvmorg-21.1.1/libcxx/src/std_stream.h#L364
https://github.com/llvm/llvm-project/blob/llvmorg-21.1.1/libcxx/include/__ostream/basic_ostream.h#L502
https://github.com/llvm/llvm-project/blob/llvmorg-21.1.1/libcxx/src/iostream.cpp#L133

0, ntdll.dll!RtlpLowFragHeapAllocFromContext+0x6c2
1, ntdll.dll!RtlpAllocateHeapInternal+0x9a7
2, ucrtbase.dll!_calloc_base+0x4e
3, ucrtbase.dll!__acrt_GetLocaleInfoA+0x6f
4, ucrtbase.dll!initialize_lc_time+0x184
5, ucrtbase.dll!__acrt_locale_initialize_time+0x41
6, ucrtbase.dll!_wsetlocale_set_cat+0x15f
7, ucrtbase.dll!_wsetlocale_nolock+0x101
8, ucrtbase.dll!<lambda_ffc046909424fd52df0ac47e64813305>::operator()+0x3a
9, ucrtbase.dll!__crt_seh_guarded_call<void>::operator()<<lambda_1d892b297fdedeee07ed8124eeb2f2fa>,<lambda_ffc046909424fd52df0ac47e64813305> &,<lambda_01a7098693036236037e7cdb9bca3d73> >+0x3b
10, ucrtbase.dll!<lambda_2a444430fde8c29194d880d93eed5e8f>::operator()+0x80
11, ucrtbase.dll!__crt_seh_guarded_call<void>::operator()<<lambda_e9338f07fe435327d97d4ef86149e64d>,<lambda_2a444430fde8c29194d880d93eed5e8f> &,<lambda_02db5278e8aef8b5e4976579d73f5304> &>+0x15
12, ucrtbase.dll!_wsetlocale+0x106
13, ucrtbase.dll!<lambda_2116bde18c9e5f34230805ea4a4660ed>::operator()+0xae
14, ucrtbase.dll!__crt_seh_guarded_call<char *>::operator()<<lambda_e9ce07acdb0b138e546925ae9f1a2c9c>,<lambda_2116bde18c9e5f34230805ea4a4660ed> &,<lambda_5d037afbfc54bf1ca80d3d1ee4062886> >+0x3b
15, ucrtbase.dll!setlocale+0x47
16, [/var/tmp/tmp-llvm-x86_64-w64-mingw32.static/llvm-project-21.1.1.src/libcxx/src/support/win32/locale_win32.cpp @ 97] (00007ffe`eb698920)   libvips_42!std::__1::__locale::__wcrtomb+0x72   |  (00007ffe`eb6989f0)   libvips_42!std::__1::__locale::__mbsnrtowcs
17, [/var/tmp/tmp-llvm-x86_64-w64-mingw32.static/llvm-project-21.1.1.src/libcxx/src/locale.cpp @ 1395] (00007ffe`eb533ed0)   libvips_42!std::__1::codecvt<wchar_t,char,_Mbstatet>::do_unshift+0x45   |  (00007ffe`eb534030)   libvips_42!std::__1::codecvt<wchar_t,char,_Mbstatet>::do_encoding
18, [/var/tmp/tmp-llvm-x86_64-w64-mingw32.static/llvm-project-21.1.1.src/libcxx/src/std_stream.h @ 364] (00007ffe`eb56e790)   libvips_42!std::__1::__stdoutbuf<wchar_t>::sync+0x39   |  (00007ffe`eb56e820)   libvips_42!std::__1::__stdoutbuf<wchar_t>::xsputn
19, [/var/tmp/tmp-llvm-x86_64-w64-mingw32.static/llvm-project-21.1.1.src/libcxx/include/__ostream/basic_ostream.h @ 502] (00007ffe`eb514c60)   libvips_42!std::__1::basic_ostream<wchar_t,std::__1::char_traits<wchar_t> >::flush+0x52   |  (00007ffe`eb514d30)   libvips_42!std::__1::basic_ostream<wchar_t,std::__1::char_traits<wchar_t> >::~basic_ostream
20, [/var/tmp/tmp-llvm-x86_64-w64-mingw32.static/llvm-project-21.1.1.src/libcxx/src/iostream.cpp @ 133] (00007ffe`eb56d9d0)   libvips_42!`dynamic atexit destructor for 'init_the_streams'+0x28   |  (00007ffe`eb56da20)   libvips_42!std::__1::force_locale_initialization::<lambda0>::operator()
21, ucrtbase.dll!<lambda_f03950bc5685219e0bcd2087efbe011e>::operator()+0xa6
22, ucrtbase.dll!__crt_seh_guarded_call<int>::operator()<<lambda_7777bce6b2f8c936911f934f8298dc43>,<lambda_f03950bc5685219e0bcd2087efbe011e> &,<lambda_3883c3dff614d5e0c5f61bb1ac94921c> >+0x3b
23, ucrtbase.dll!execute_onexit_table+0x34
24, libvips_42!CRT_INIT+0xa8   |  (00007ffe`eaff11e0)   libvips_42!DllMainCRTStartup
25, libvips_42!DllMainCRTStartup+0x9d   |  (00007ffe`eaff1350)   libvips_42!atexit
26, ntdll.dll!LdrpCallInitRoutine+0x61
27, ntdll.dll!LdrShutdownProcess+0x22a
28, ntdll.dll!RtlExitUserProcess+0xad
29, kernel32.dll!ExitProcessImplementation+0xb
30, ucrtbase.dll!exit_or_terminate_process+0x44
31, ucrtbase.dll!common_exit+0x6f
32, vips!WinMainCRTStartup+0x38a   |  (00007ff6`d56c1390)   vips!mainCRTStartup
33, vips!mainCRTStartup+0x16   |  (00007ff6`d56c13b0)   vips!atexit
34, kernel32.dll!BaseThreadInitThunk+0x14
35, ntdll.dll!RtlUserThreadStart+0x21

Which is:
https://github.com/llvm/llvm-project/blob/llvmorg-21.1.1/libcxx/src/support/win32/locale_win32.cpp#L97
https://github.com/llvm/llvm-project/blob/llvmorg-21.1.1/libcxx/src/locale.cpp#L1395
https://github.com/llvm/llvm-project/blob/llvmorg-21.1.1/libcxx/src/std_stream.h#L364
https://github.com/llvm/llvm-project/blob/llvmorg-21.1.1/libcxx/include/__ostream/basic_ostream.h#L502
https://github.com/llvm/llvm-project/blob/llvmorg-21.1.1/libcxx/src/iostream.cpp#L133

So, the hang appears(?) to occur within the C++ standard I/O stream destructors. I'll keep digging.

Are you trying the latest zip with the static vips build? For me within a minute I have at least one hanging vips process.

Yes, that was using the statically built Windows binaries on a Windows 11 PC with OpenJDK from:
https://adoptium.net/temurin/releases?version=21&os=windows&arch=x64&mode=filter
(i.e. Adoptium Eclipse Temurin 21)

I have changed my Regional Settings to English (US) now and will try again.

This didn't help. It still created hanging instances.

Ah, bummer. This suggests that it's not related to llvm/llvm-project#160479.

kleisauke Oct 9, 2025
Maintainer

Given that Process.waitFor() blocks until the process exits, you could work around this by using:

--- a/test.java
+++ b/test.java
@@ -2,6 +2,7 @@ import java.io.IOException;
 import java.nio.file.*;
 import java.nio.file.attribute.BasicFileAttributes;
 import java.util.concurrent.CountDownLatch;
+import java.util.concurrent.TimeUnit;
 
 public class test
 {
@@ -38,9 +39,8 @@ public class test
                                                     "--height", "65536",
                                                     "--size", "down",
                                                     "--output-profile", profileImage.toString ())
-                                .inheritIO ()
                                 .start ();
-                            p.waitFor ();
+                            p.waitFor (5, TimeUnit.MINUTES); // adjust as needed
                         }
                         catch (Throwable e)
                         {

(I also removed ProcessBuilder.inheritIO(), as the vips.exe output is probably not needed)

I'm still investigating a possible reason for this. It's a bit strange that it occurs within the built-in atexit() handler.

8000

IgelCampus Oct 9, 2025
Author

Thanks for the idea, but this is just quick throw-away test code to reproduce the issue which does not need to handle the situation better.
The actual product uses Go to call vips which on the other hand unfortunately cannot kill started processes so if it cannot be fixed by vips itself we might have to fall back to calling taskkill.exe manually.

IgelCampus Oct 9, 2025
Author

Another find. When trying to force kill the parent process (pid 7916) Windows can not even find the still running vips process (pid 24564) anymore (sorry it's German):

C:\Windows\system32>taskkill /F /PID 7916 /T
ERFOLGREICH: Der Prozess mit PID 22768 (untergeordnetem Prozess von PID 7916) wurde beendet.
FEHLER: Der Prozess mit PID 24564 (untergeordnetem Prozess von PID 7916) konnte nicht beendet werden.
Ursache: Von dieser Aufgabe wird momentan keine Instanz ausgeführt.
ERFOLGREICH: Der Prozess mit PID 7916 (untergeordnetem Prozess von PID 25776) wurde beendet.

But the process with pid 24564 is clearly still running according to Task Manager and Process Explorer.

kleisauke · 2025-10-09T19:54:41Z

kleisauke
Oct 9, 2025
Maintainer

It seems this is a known issue in libc++, see: llvm/llvm-project#110954.

2 replies

kleisauke Oct 10, 2025
Maintainer

Here's a better stack trace now that I've reproduced this issue locally:

Details

0:000> k
 # Child-SP          RetAddr               Call Site
00 00000070`086ff040 00007ffc`8fa50f54     ntdll!RtlpLowFragHeapAllocFromContext+0x1c8
01 00000070`086ff110 00007ffc`8fa50e14     ntdll!RtlpAllocateNTHeapInternal+0xe4
02 00000070`086ff1a0 00007ffc`8cd000a3     ntdll!RtlAllocateHeap+0xad4
03 00000070`086ff2e0 00007ffc`8cd0759a     ucrtbase!calloc_base+0x53
04 00000070`086ff310 00007ffc`8cd074a8     ucrtbase!internal_get_ptd_head_slow+0x3a
05 00000070`086ff340 00007ffc`8cd7402d     ucrtbase!__acrt_getptd+0x58
06 00000070`086ff380 00007ffc`1119dba7     ucrtbase!configthreadlocale+0xd
07 00000070`086ff3b0 00007ffc`112c8952     libvips_42!std::__1::__locale::__locale_guard::__locale_guard+0x17 [/var/tmp/tmp-llvm-x86_64-w64-mingw32.static/llvm-project-21.1.1.src/libcxx/include/__locale_dir/support/windows.h @ 302] 
08 00000070`086ff3f0 00007ffc`11163f15     libvips_42!std::__1::__locale::__wcrtomb+0x32 [/var/tmp/tmp-llvm-x86_64-w64-mingw32.static/llvm-project-21.1.1.src/libcxx/src/support/win32/locale_win32.cpp @ 95] 
09 00000070`086ff460 00007ffc`1119e7c9     libvips_42!std::__1::codecvt<wchar_t,char,_Mbstatet>::do_unshift+0x45 [/var/tmp/tmp-llvm-x86_64-w64-mingw32.static/llvm-project-21.1.1.src/libcxx/src/locale.cpp @ 1395] 
0a (Inline Function) --------`--------     libvips_42!std::__1::codecvt<wchar_t,char,_Mbstatet>::unshift+0x11 [/var/tmp/tmp-llvm-x86_64-w64-mingw32.static/llvm-project-21.1.1.src/libcxx/include/__locale @ 842] 
0b 00000070`086ff4e0 00007ffc`11144cb2     libvips_42!std::__1::__stdoutbuf<wchar_t>::sync+0x39 [/var/tmp/tmp-llvm-x86_64-w64-mingw32.static/llvm-project-21.1.1.src/libcxx/src/std_stream.h @ 364] 
0c (Inline Function) --------`--------     libvips_42!std::__1::basic_streambuf<wchar_t,std::__1::char_traits<wchar_t> >::pubsync+0x6 [/var/tmp/tmp-llvm-x86_64-w64-mingw32.static/llvm-project-21.1.1.src/libcxx/include/streambuf @ 176] 
0d 00000070`086ff550 00007ffc`1119d9f8     libvips_42!std::__1::basic_ostream<wchar_t,std::__1::char_traits<wchar_t> >::flush+0x52 [/var/tmp/tmp-llvm-x86_64-w64-mingw32.static/llvm-project-21.1.1.src/libcxx/include/__ostream/basic_ostream.h @ 502] 
0e (Inline Function) --------`--------     libvips_42!std::__1::DoIOSInit::~DoIOSInit+0x24 [/var/tmp/tmp-llvm-x86_64-w64-mingw32.static/llvm-project-21.1.1.src/libcxx/src/iostream.cpp @ 127] 
0f 00000070`086ff5a0 00007ffc`8cd3bc75     libvips_42!`dynamic atexit destructor for 'init_the_streams'+0x28 [/var/tmp/tmp-llvm-x86_64-w64-mingw32.static/llvm-project-21.1.1.src/libcxx/src/iostream.cpp @ 133] 
10 00000070`086ff5d0 00007ffc`8cd3b897     ucrtbase!<lambda_f03950bc5685219e0bcd2087efbe011e>::operator()+0xa5
11 00000070`086ff620 00007ffc`8cd3b84d     ucrtbase!__crt_seh_guarded_call<int>::operator()<<lambda_7777bce6b2f8c936911f934f8298dc43>,<lambda_f03950bc5685219e0bcd2087efbe011e> &,<lambda_3883c3dff614d5e0c5f61bb1ac94921c> >+0x3b
12 00000070`086ff650 00007ffc`10c210a8     ucrtbase!execute_onexit_table+0x3d
13 00000070`086ff690 00007ffc`10c2127d     libvips_42!CRT_INIT+0xa8
14 00000070`086ff6f0 00007ffc`8fb60ede     libvips_42!DllMainCRTStartup+0x9d
15 00000070`086ff740 00007ffc`8fa7483e     ntdll!LdrpCallInitRoutineInternal+0x22
16 00000070`086ff770 00007ffc`8faf
8000
dfff     ntdll!LdrpCallInitRoutine+0x10e
17 00000070`086ff7e0 00007ffc`8fa08ede     ntdll!LdrShutdownProcess+0x17f
18 00000070`086ff8f0 00007ffc`8e2918ab     ntdll!RtlExitUserProcess+0x9e
19 00000070`086ff920 00007ffc`8cd90093     KERNEL32!ExitProcessImplementation+0xb
1a 00000070`086ff950 00007ff6`e2e1138a     ucrtbase!common_exit+0xc7
1b 00000070`086ff9b0 00007ff6`e2e113a6     vips!WinMainCRTStartup+0x38a
1c 00000070`086ffa30 00007ffc`8e27e8d7     vips!mainCRTStartup+0x16
1d 00000070`086ffa60 00007ffc`8fa08d9c     KERNEL32!BaseThreadInitThunk+0x17
1e 00000070`086ffa90 00000000`00000000     ntdll!RtlUserThreadStart+0x2c

As a possible workaround for now, we could call TerminateProcess(GetCurrentProcess(), 0); after vips_shutdown() in the vips driver program on Win32.

libvips/tools/vips.c

Line 944 in 064c365

vips_shutdown();

This would align the behavior with LLVM-based tools (e.g. LLD, see commit llvm/llvm-project@b4fd512).

IgelCampus Oct 10, 2025
Author

Thanks a lot for all the time you are spending on this. If you have an idea how to solve it I would be happy to test ideas here locally.

Uh oh!

Vips (Windows binary) seems to be stuck in loop forever #4690

Uh oh!

IgelCampus Oct 8, 2025

Replies: 4 comments · 13 replies

Uh oh!

lovell Oct 8, 2025 Maintainer

Uh oh!

IgelCampus Oct 8, 2025 Author

Uh oh!

kleisauke Oct 8, 2025 Maintainer

Uh oh!

IgelCampus Oct 9, 2025 Author

Uh oh!

IgelCampus Oct 9, 2025 Author

Uh oh!

kleisauke Oct 9, 2025 Maintainer

Uh oh!

kleisauke Oct 9, 2025 Maintainer

Uh oh!

IgelCampus Oct 9, 2025 Author

Uh oh!

IgelCampus Oct 9, 2025 Author

Uh oh!

kleisauke Oct 9, 2025 Maintainer

Uh oh!

kleisauke Oct 10, 2025 Maintainer

Uh oh!

IgelCampus Oct 10, 2025 Author

IgelCampus
Oct 8, 2025

Replies: 4 comments 13 replies

lovell
Oct 8, 2025
Maintainer

IgelCampus
Oct 8, 2025
Author

kleisauke Oct 8, 2025
Maintainer

IgelCampus
Oct 9, 2025
Author

IgelCampus Oct 9, 2025
Author

kleisauke Oct 9, 2025
Maintainer

kleisauke Oct 9, 2025
Maintainer

IgelCampus Oct 9, 2025
Author

IgelCampus Oct 9, 2025
Author

kleisauke
Oct 9, 2025
Maintainer

kleisauke Oct 10, 2025
Maintainer

IgelCampus Oct 10, 2025
Author