Describe the bug

The issue was originally raised in the JetBrains fork, but I think that the same issue is possible in the async-profiler too
https://youtrack.jetbrains.com/issue/IDEA-367770

The crash appears on macOS ARM.

Stack: [0x0000000350e04000,0x0000000350e87000],  sp=0x0000000350e86f10,  free space=523k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [libasyncProfiler.dylib+0x54660]  ThreadFilter::accept(int)+0x10
C  [libasyncProfiler.dylib+0x58544]  WallClock::threadEntry(void*)+0xc
C  [libsystem_pthread.dylib+0x72e4]  _pthread_start+0x88

After investigation of the crash dump, we found out that threadId = -1. In the fork, we guarded the problem with if (thread_id < 0) return false; check, but we were interested in whether negative values are actually valid in this case.

The values are coming from MacThreadList::MacThreadList where they are unsigned int, but then they are cased to int, which is suspicious.

Expected vs. actual behavior

No response

Reproduction Steps

The issue cannot be stably reproduced

Additional Information/Context

No response

Async-profiler version

3.0

Environment details

No response