Skip to content

Un-reset heap pointer in sys_execve causes segfaults #28

@sunhaosheng

Description

@sunhaosheng

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)

  1. export UB_BINDIR=/root/UnixBench/pgms
  2. cd ./UnixBench/pgms
  3. ./execl 30

Expected Behavior

Successfuly run execl test and output a score.

Image

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:

  1. A process expands its heap region via the brk system call, moving its heap_top pointer upward.
  2. The process calls execve to run a new program.
  3. sys_execve clears the old memory mappings and invokes load_user_app to load the new program’s ELF into the address space.
  4. However, the heap_top value in the ProcessData structure still retains the elevated value from the previous process state.
  5. After the new program starts running, its first brk call attempts to allocate heap memory starting from an incorrect, excessively high address.
  6. 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):

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions