D04parameter.ztst crashes if USE_MMAP is not defined

["Jun. T" <takimoto-j@xxxxxxxxxxxxxxxxx>]

If I use autoconf-2.72 to create configure on Cygwin, and build
zsh, then test D04parameter crashes. The crash can be reproduced
on Linux or macOS by, after ./configure, manually removing the
following lines from zsh.h,
#define HAVE_MMAP 1
#define HAVE_MSYNC 1
#define HAVE_MUNMAP 1
and "make; make TESTNUM=D04 check".

[1] AC_FUNC_MMAP in autoconf-2.72 checks functionalities of
mmap() more strictly, and Cygwin's mmap() can't pass this
test, and HAVE_MMAP is not defined in zsh.h.

# The new AC_FUNC_MMAP checks whether MAP_FIXED works as
# expected or not (and it doesn't work on Cygwin). But zsh does
# not use MAP_FIXED. If autoconf-2.71 or earlier is used on
# Cygwin, HAVE_MMAP is defined and the resulting zsh works fine.

It seems something is wrong in the code that is used when
USE_MMAP is not defined.

[2] The crash occurs in the test chunk
"Unsetting and recreation of tied normal parameters".
The chunk has 8 "print $STRING $string", and it crashes
at the 6th of them.

But If I run the code in the chunk alone in a zsh (built without
HAVE_MMAP) it does not crash. Maybe the crash is related with
some state of the heap?

[3] Back trace of the crashed zsh (obtained on Ubuntu-22.04):
#0  __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:74
#1  0x000055e6f65cbffe in paramsubst (l=0x55e6f860b178, n=0x55e6f860b1c0, 
    str=0x7ffcebda63a0, qt=0, pf_flags=0, ret_flags=0x7ffcebda64b4)
    at subst.c:4322
#2  0x000055e6f65c2592 in stringsubst (list=0x55e6f860b178, 
    node=0x55e6f860b1c0, pf_flags=0, ret_flags=0x7ffcebda64b4, asssub=0)
    at subst.c:322
#3  0x000055e6f65c1878 in prefork (list=0x55e6f860b178, flags=0, 
    ret_flags=0x7ffcebda64b4) at subst.c:142
#4  0x000055e6f6549ec7 in execcmd_exec (state=0x7ffcebda6e00, 
    eparams=0x7ffcebda6a10, input=0, output=0, how=2, last1=2, 
    close_if_forked=-1) at exec.c:3282
#5  0x000055e6f6546636 in execpline2 (state=0x7ffcebda6e00, pcode=1219, how=2, 
    input=0, output=0, last1=0) at exec.c:2016
#6  0x000055e6f65451ca in execpline (state=0x7ffcebda6e00, slcode=5122, how=2, 
    last1=0) at exec.c:1741
#7  0x000055e6f654440c in execlist (state=0x7ffcebda6e00, dont_change_job=1, 
    exiting=0) at exec.c:1495
#8  0x000055e6f6543a2c in execode (p=0x55e6f8609ec0, dont_change_job=1, 
    exiting=0, context=0x55e6f65e10eb "eval") at exec.c:1276
#9  0x000055e6f6539bca in eval (argv=0x55e6f8608de0) at builtin.c:6203
#10 0x000055e6f653a8de in bin_eval (nam=0x55e6f8608ba8 "eval", 
    argv=0x55e6f8608de0, ops=0x7ffcebda6fa0, func=14) at builtin.c:6389

line 4322 in subst.c is:
            xlen = strlen(x);
It seems x (= aval[0]) points to an already freed memory, but
I currently have no time to investigate further.