Summary
projectGenerator terminates with STATUS_STACK_BUFFER_OVERRUN (0xC0000409) when an addon
directory contains symlinks. No project is produced.
Reproduction
OF 0.12.1 (also 0.11.0, 0.11.2, 0.12.0), Windows 11, projectGenerator -p vs.
projectGenerator.exe -oC:\of0121 -pvs -a"ofxHapPlayer" C:\of0121\apps\myApps\test
Result: exit code -1073740791 (0xC0000409). The generated .vcxproj is an 11 KB skeleton
with 2 ClCompile entries and no addon content.
Isolated with a control:
| PG invocation |
Result |
-a ofxGui |
OK — 12149 B vcxproj |
-a ofxHapPlayer |
CRASH — 11452 B skeleton only |
-a ofxHapPlayer after deleting its symlinks |
OK — 18443 B vcxproj |
So it is symlink handling specifically, not the addon and not PG generally.
The trigger
ofxHapPlayer ships 9 macOS .dylib version symlinks across two directories:
libs/ffmpeg/lib/osx/ libavcodec.57.dylib -> libavcodec.57.64.101.dylib (8 links)
libs/snappy/lib/osx/ libsnappy.dylib -> libsnappy.1.dylib (1 link)
All nine resolve — no dangling links, no cycles — so this is not runaway recursion. And
MAX_PATH is not involved: the longest path in that addon is 103 characters, well under 260
(LongPathsEnabled=0 on this machine).
Note that renaming or moving libs/ffmpeg/lib/osx does not help: PG scans directories
regardless of name, and one of the nine lives under libs/snappy/lib/osx, a different tree.
Why it matters
Symlinks appear in any addon vendoring macOS dylibs, and they survive a git clone on Windows
when core.symlinks is enabled. The only workaround is deleting them, which breaks macOS
linking (libavcodec.dylib is expected to resolve to the versioned file) — so it cannot be
fixed in the addon without harming other platforms.
Verbose output ends while enumerating the osx directory:
[verbose] libswresample.dylib
[verbose] listed 12 files in "C:\...\ofxHapPlayer\libs\ffmpeg\lib\osx\"
<crash>
A 0xC0000409 fail-fast points at a fixed-size buffer in the directory walker rather than
stack exhaustion (which would be 0xC00000FD).
Summary
projectGenerator terminates with
STATUS_STACK_BUFFER_OVERRUN(0xC0000409) when an addondirectory contains symlinks. No project is produced.
Reproduction
OF 0.12.1 (also 0.11.0, 0.11.2, 0.12.0), Windows 11,
projectGenerator -p vs.Result: exit code
-1073740791(0xC0000409). The generated.vcxprojis an 11 KB skeletonwith 2
ClCompileentries and no addon content.Isolated with a control:
-a ofxGui-a ofxHapPlayer-a ofxHapPlayerafter deleting its symlinksSo it is symlink handling specifically, not the addon and not PG generally.
The trigger
ofxHapPlayerships 9 macOS.dylibversion symlinks across two directories:All nine resolve — no dangling links, no cycles — so this is not runaway recursion. And
MAX_PATHis not involved: the longest path in that addon is 103 characters, well under 260(
LongPathsEnabled=0on this machine).Note that renaming or moving
libs/ffmpeg/lib/osxdoes not help: PG scans directoriesregardless of name, and one of the nine lives under
libs/snappy/lib/osx, a different tree.Why it matters
Symlinks appear in any addon vendoring macOS dylibs, and they survive a
git cloneon Windowswhen
core.symlinksis enabled. The only workaround is deleting them, which breaks macOSlinking (
libavcodec.dylibis expected to resolve to the versioned file) — so it cannot befixed in the addon without harming other platforms.
Verbose output ends while enumerating the
osxdirectory:A
0xC0000409fail-fast points at a fixed-size buffer in the directory walker rather thanstack exhaustion (which would be
0xC00000FD).