Replay Unable to Track Shared Memory Allocators
@kab163 is already working on this.
Since Jan 31, 2025.
- Dominant language
- C++
- Stars
- 422
- Forks
- 64
- PR merge metrics
- No merged PRs in 30d
Description
**Describe the bug**
When gathering a replay trace of some program that uses shared memory allocators, the replay executable is unable to replay that file and no `.ult` file is dumped. It just seg faults.
**To Reproduce**
Steps to reproduce the behavior:
Run any program that uses umpire shared memory with the `UMPIRE_REPLAY=On` env variable. Get the `.stats` file.
Build and make a separate umpire build with tools enabled (and hip/cuda enabled if appliable, shared memory if applicable, etc.)
If you run the replay executable with the `-d` option to get a .ult file dumped out, it will seg fault.
**Expected behavior**
Replay should be able to handle shared memory allocators especially as interest in using shared memory increases...
**Compilers & Libraries (please complete the following information):**
I ran a marbl triple pt run with the device memory on and it happens to use some shared memory allocators.
I ran this on rzadams with hip enabled, rocm/6.0.3, cmake/3.23.1, and shared memory
**Additional context**
The problem is likely that Replay is not tracking the traits that shared memory allocators use. It really just needs to know about the size of the shared memory allocator. Once that is added, that should be enough to get things working.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Assessment
This issue has not been assessed yet.