forked from Starry-OS/StarryOS
-
Notifications
You must be signed in to change notification settings - Fork 10
Un-reset heap pointer in sys_execve causes segfaults #28
Copy link
Copy link
Open
Starry-OS/StarryOS
#86Description
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_toppointer upward. - The process calls execve to run a new program.
sys_execveclears the old memory mappings and invokesload_user_appto load the new program’s ELF into the address space.- However, the
heap_topvalue in theProcessDatastructure still retains the elevated value from the previous process state. - After the new program starts running, its first
brkcall 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):
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
No labels