Segmenation fault on bash if a specific script is executed only and compiled with clang

[0xIO32]

Bash crashes with a segmentation fault if executed with this specific script (context below) and if compiled with clang. The issue does not exist, if compiled with gcc.
I didn't use lto or -O3. This happens with "-march=native -O2 -pipe".

Steps to reproduce:

• Compile bash with clang
• Go to/Create a empty test directory
• create these directories "out/target/product/beyond2lte/obj/PACKAGING/apkcerts_intermediates/"
• copy the script to this location "out/target/product/beyond2lte/obj/PACKAGING/apkcerts_intermediates/lineage_beyond2lte-apkcerts.txt.sh"
• run the script using "bash out/target/product/beyond2lte/obj/PACKAGING/apkcerts_intermediates/lineage_beyond2lte-apkcerts.txt.rsp"

What should happen:
The bash script should generate the "out/target/product/beyond2lte/obj/PACKAGING/apkcerts_intermediates/lineage_beyond2lte-apkcerts.txt" file.

What does happen:
Bash crashes with a segmentation fault.

Context:
I don't know why this happens (I am not an expert). This bash script was created as part of the Android Open-Source Project build process (while I tried to compile android). It has been automatically created using Makefile files. I wasn't able to reproduce the issue with another bash script. There is something special about this one, maybe the size? (it just echos and appends data to a txt file, you can execute inside docker, a vm or whatever if you don't trust its content).

It only crashes if bash is compiled with clang.

The bash script: (the .txt extension only exists because github doesn't allow .sh or the .rsp extension)
lineage_beyond2lte-apkcerts.txt.rsp.txt

It has been tested using clang-19 and "GNU bash, version 5.2.37(1)-release"

[DimitryAndric]

I think that without a lot more reduction, you will not get any further on this bug tracker. You might be running into a bash bug, which is not unlikely. As a first step, I would try to run bash under valgrind, or recompile it with -fsanitize=address and/or -fsanitize=undefined, to see if there is anything strange going on. Also, remove the -march=native and try to experiment with different types of target CPUs.

The end goal would be to come up with a clear example of a miscompile: a self-contained .c or .cpp file with a specific compiler command line that can be run anywhere.

[0xIO32]

The error from valgrind:

==28482== Stack overflow in thread #1: can't grow stack to 0x1ffe801000
==28482==
==28482== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==28482==  Access not within mapped region at address 0x1FFE801FFC
==28482== Stack overflow in thread #1: can't grow stack to 0x1ffe801000
==28482==    at 0x154544: ??? (in /usr/bin/bash)
==28482==  If you believe this happened as a result of a stack
==28482==  overflow in your program's main thread (unlikely but
==28482==  possible), you can try to increase the size of the
==28482==  main thread stack using the --main-stacksize= flag.
==28482==  The main thread stack size used in this run was 8388608.

[0xIO32]

GDB Backtrace:

(gdb) bt
#0  0x00007ffff7caf379 in ?? () from /usr/lib64/libc.so.6
#1  0x00007ffff7cb1612 in malloc () from /usr/lib64/libc.so.6
#2  0x00005555555f4f50 in xmalloc ()
#3  0x00005555555da171 in begin_unwind_frame ()
#4  0x00005555555a0b53 in execute_command_internal ()
#5  0x00005555555a0455 in execute_command ()
#6  0x00005555555a4d76 in execute_connection ()
#7  0x00005555555a0fdb in execute_command_internal ()
#8  0x00005555555a0455 in execute_command ()
#9  0x00005555555a4d76 in execute_connection ()
#10 0x00005555555a0fdb in execute_command_internal ()
#11 0x00005555555a0455 in execute_command ()
#12 0x00005555555a4d76 in execute_connection ()
#13 0x00005555555a0fdb in execute_command_internal ()
#14 0x00005555555a0455 in execute_command ()
#15 0x00005555555a4d76 in execute_connection ()
#16 0x00005555555a0fdb in execute_command_internal ()

[0xIO32]

Increasing the stack size limit from the default 8192 to 16384 (using ulimit -s 16384) fixed the issue. But it is still weird that it only happend if compiled with clang.
I am now unsure, if this is a compiler bug or not? (I will leave it open for now)

[DimitryAndric]

This could be caused by inlining which can use up more stack. I also saw that your shell script is all on one line, so that could also make matters worse.