Issue Title (Short summary)
Un-reset heap pointer in sys_execve causes segfaults
Environment
- Application / Service name: NA
- Version / Branch: mainline
- Deployment environment: qemu
- Container runtime (if any):
- Other dependencies (e.g., database, cache, middleware and versions): UnixBench 6.0.0, perl, make, gcc, g++
A configured image can be downloaded via rootfs-unixbench.img.xz
Architecture
aarch64 + qemu
Image (Container Image Information)
- Image registry and name: alpine-rootfs img
Description
When running the UnixBench benchmark, the execl test consistently triggers a segmentation fault, causing the entire test to stop. Executing the ./execl program on its own also reproduces the crash within a short time.
Reproduction Steps (if reproducible)
- export UB_BINDIR=/root/UnixBench/pgms
- cd ./UnixBench/pgms
- ./execl 30
Expected Behavior
Successfuly run execl test and output a score.
Actual Behavior
it would remind a segmentation fault happenning.
Logs / Error Details
- System or container status:
Troubleshooting & Workarounds
In the execl test, the program repeatedly calls execve on itself, executing thousands of times within about 30 seconds. In StarryOS, although sys_execve clears the old address space and reloads the program, it does not reset the process’s maintained heap boundary state.
The detailed flow is as follows:
- A process expands its heap region via the brk system call, moving its
heap_top pointer upward.
- The process calls execve to run a new program.
sys_execve clears the old memory mappings and invokes load_user_app to load the new program’s ELF into the address space.
- However, the
heap_top value in the ProcessData structure still retains the elevated value from the previous process state.
- After the new program starts running, its first
brk call attempts to allocate heap memory starting from an incorrect, excessively high address.
- This causes the heap to overlap illegally with other regions (such as the stack), eventually leading to a segmentation fault during subsequent operations.
Notes / Additional Information
- Related Issue / PR / RFC links:
- Contact person (for follow-up questions):
- Desired priority (e.g., P0/P1/P2):
Issue Title (Short summary)
Un-reset heap pointer in sys_execve causes segfaults
Environment
A configured image can be downloaded via rootfs-unixbench.img.xz
Architecture
aarch64 + qemu
Image (Container Image Information)
Description
When running the UnixBench benchmark, the execl test consistently triggers a segmentation fault, causing the entire test to stop. Executing the ./execl program on its own also reproduces the crash within a short time.
Reproduction Steps (if reproducible)
Expected Behavior
Successfuly run execl test and output a score.
Actual Behavior
it would remind a segmentation fault happenning.
Logs / Error Details
Troubleshooting & Workarounds
In the execl test, the program repeatedly calls execve on itself, executing thousands of times within about 30 seconds. In StarryOS, although
sys_execveclears the old address space and reloads the program, it does not reset the process’s maintained heap boundary state.The detailed flow is as follows:
heap_toppointer upward.sys_execveclears the old memory mappings and invokesload_user_appto load the new program’s ELF into the address space.heap_topvalue in theProcessDatastructure still retains the elevated value from the previous process state.brkcall attempts to allocate heap memory starting from an incorrect, excessively high address.Notes / Additional Information