Re: [PATCH 6/6] max_tree_depth: lower it for clangarm64 on Windows

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Apr 21, 2025 at 12:39:10PM +0000, Johannes Schindelin via GitGitGadget wrote:
> diff --git a/environment.c b/environment.c
> index 9e4c7781be0..cc853950bb2 100644
> --- a/environment.c
> +++ b/environment.c
> @@ -82,9 +82,21 @@ int max_allowed_tree_depth =
>  	 * the stack overflow can occur.
>  	 */
>  	512;
> +#else
> +#if defined(GIT_WINDOWS_NATIVE) && defined(__clang__) && defined(__aarch64__)

Tiny nit, only because it puzzled me for a second: this should probably
be `#elif`.

> +	/*
> +	 * Similar to Visual C, it seems that on Windows/ARM64 the clang-based
> +	 * builds have a smaller stack space available. When running out of
> +	 * that stack space, a `STATUS_STACK_OVERFLOW` is produced. When the
> +	 * Git command was run from an MSYS2 Bash, this unfortunately results
> +	 * in an exit code 127. Let's prevent that by lowering the maximal
> +	 * tree depth; This value seems to be low enough.
> +	 */
> +	1280;
>  #else
>  	2048;
>  #endif
> +#endif

Hm. This whole construct feels rather awful, if you ask me. Instead of
papering over the issue it would be nice if we eventually fixed the root
cause, which is that we use recursion on a data structure that has an
unbounded depth in theory.

Anyway, that is clearly outside of the scope of this patch series, so
the bandaid is good enough for now.

Patrick




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux