Skip to content

Commit 73ce0dc

Browse files
committed
max_tree_depth: lower it for clangarm64 on Windows
Just as in b64d78a (max_tree_depth: lower it for MSVC to avoid stack overflows, 2023-11-01), I encountered the same problem with the clang builds on Windows/ARM64. The symptom is an exit code 127 when t6700 tries to verify that `git archive big` fails. This exit code is reserved on Unix/Linux to mean "command not found". Unfortunately in this case, it is the fall-back chosen by Cygwin's `pinfo::status_exit()` method when encountering the NSTATUS `STATUS_STACK_OVERFLOW`, see https://github.com/cygwin/cygwin/blob/cygwin-3.6.1/winsup/cygwin/pinfo.cc#L171 I verified manually that the stack overflow always happens somewhere around tree depth 1403, therefore 1280 should be a safe bound in these instances. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
1 parent 95b2c74 commit 73ce0dc

1 file changed

Lines changed: 12 additions & 0 deletions

File tree

environment.c

Lines changed: 12 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -87,9 +87,21 @@ int max_allowed_tree_depth =
8787
* tree depth; This value seems to be low enough.
8888
*/
8989
1280;
90+
#else
91+
#if defined(GIT_WINDOWS_NATIVE) && defined(__clang__) && defined(__aarch64__)
92+
/*
93+
* Similar to Visual C, it seems that on Windows/ARM64 the clang-based
94+
* builds have a smaller stack space available. When running out of
95+
* that stack space, a `STATUS_STACK_OVERFLOW` is produced. When the
96+
* Git command was run from an MSYS2 Bash, this unfortunately results
97+
* in an exit code 127. Let's prevent that by lowering the maximal
98+
* tree depth; This value seems to be low enough.
99+
*/
100+
1280;
90101
#else
91102
2048;
92103
#endif
104+
#endif
93105

94106
#ifndef PROTECT_HFS_DEFAULT
95107
#define PROTECT_HFS_DEFAULT 0

0 commit comments

Comments
 (0)