Codex flagged a remaining race after the initial fix: walkVM's read-only
bounded_lookup still traverses row->next and reads row->keys[j] without
holding _class_map_lock, while Profiler::dump's exclusive _class_map.clear()
runs in the unlockAll -> lock window and free()s those same nodes/strings.

Take _class_map_lock shared via OptionalSharedLockGuard (try-lock so the
signal handler never blocks). When an exclusive clear() is in progress,
drop the synthetic vtable-target frame instead of dereferencing freed
memory.

Also add the missing <cstring> include in dictionary_concurrent_ut.cpp;
strlen() previously worked only via a transitive include through
gtest_crash_handler.h.

Addresses review comments on PR #512.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

flightRecorder.cpp: refer to classMap()/classMapLock() rather
than the underlying _class_map/_class_map_lock fields.
dictionary_concurrent_ut.cpp: drop PROF-14549 ticket reference.

Co-Authored-By: muse <muse@noreply>

Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>

… vs dump clear

Adds SignalHandlerBoundedLookupVsDumpClear: concurrent signal-handler threads
(OptionalSharedLockGuard + bounded_lookup(0)) vs a dump thread (exclusive lock
+ dict.clear()), reproducing the PROF-14550 crash signature without the fix.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

…fter-unlock in writeClasses; cap tryLockShared at 5 attempts

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

…unded variant

- ddprof-lib/src/main/cpp/spinLock.h:49 — restored tryLockShared() to spin until exclusive lock released; added tryLockSharedBounded() for signal-handler paths
- ddprof-lib/src/main/cpp/spinLock.h:102 — OptionalSharedLockGuard updated to use tryLockSharedBounded()

Co-Authored-By: muse <muse@noreply>

…(), not tryLockShared()

The previous commit added tryLockSharedBounded() and claimed OptionalSharedLockGuard
was updated to use it, but the constructor still called tryLockShared() — the spinning
(potentially unbounded) variant. Since OptionalSharedLockGuard is used in signal-handler
paths, it must use the bounded variant to be async-signal-safe.

Agent-Logs-Url: https://github.com/DataDog/java-profiler/sessions/4b50411f-3c52-4938-9d54-a43ada34b94e

Co-authored-by: jbachorik <738413+jbachorik@users.noreply.github.com>

- ddprof-lib/src/main/cpp/spinLock.h:115 — OptionalSharedLockGuard reverted to tryLockShared() (non-spurious) for FlightRecorder hot paths; BoundedOptionalSharedLockGuard added for signal-handler-only callers
- ddprof-lib/src/main/cpp/profiler.h:208 — classMapTrySharedGuard() now returns BoundedOptionalSharedLockGuard

Co-Authored-By: muse <muse@noreply>

…ounded unit tests

- spinlock_bounded_ut.cpp: 6 tests covering tryLockSharedBounded() and
  BoundedOptionalSharedLockGuard in isolation (free lock, exclusive-held
  failure, multiple shared holders, RAII destruction, concurrent stress)
- dictionary_concurrent_ut.cpp: update SignalHandlerBoundedLookupVsDumpClear
  to use BoundedOptionalSharedLockGuard matching the actual hotspotSupport.cpp
  code path (classMapTrySharedGuard())

Co-Authored-By: muse <muse@noreply>

…nalSharedLockGuard

Restore OptionalSharedLockGuard in SignalHandlerBoundedLookupVsDumpClear and
add SignalHandlerBoundedOptionalLookupVsDumpClear for BoundedOptionalSharedLockGuard,
which is what classMapTrySharedGuard() returns in hotspotSupport.cpp.

Co-Authored-By: muse <muse@noreply>

Exercises the race where Profiler::start(reset=true) clears _class_map
concurrently with Recording::writeClasses iterating its row keys, which
corrupted rbtree nodes and caused SIGSEGV in std::_Rb_tree_increment.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

alloc=1ms is not recognized by Arguments::parse — only event=alloc and
memory=<interval>[:<config>] are valid. Switch to memory=262144:a so
allocating threads actually populate _class_map via ObjectSampler.

- ddprof-test/src/test/java/com/datadoghq/profiler/jfr/ConcurrentDumpRestartTest.java:68 — memory=262144:a,wall=5ms

Co-Authored-By: muse <muse@noreply>

… handler and dump path (#516)