In crashes and ANR put the state of all the threads in attributes

[atulgpt]

Expected Behavior

For events, device.anr and device.crash we should also put the state and stactrace of the all the threads present in the system. This becomes really useful in case of ANR where more than one thread participate in ANR

Current Behavior

We only put state of current thread where ANR or crash happened

[breedx-splk]

Thanks @atulgpt. I have a comment and a couple questions about this request. To start, I should mention that the ANR instrumentation already allows some "additional extractors" (attribute extractors) to be configured by the developer, and these could be used to do this. Crash has this too.

1. Do you know of an existing api that can "snapshot" the state and stack of all threads at once (atomically)? The problem with enumerating and iterating threads to get this information is that it could have changed and no longer accurately represents the internal state of the time of the crash/anr.
2. I think that the semantic conventions don't yet cover this case. We would need to update the semconv to create an array of "other threads" or something. Please give that some consideration.

Thanks again!

[atulgpt]

Hi @breedx-splk there is Java method in public int enumerate(Thread[] list) in the thread group which gives you the list of all the threads.

One possible implementation could be this(taken from Bugsnag android sdk)

internal fun allThreads(): List<JavaThread> {
    val rootGroup = rootThreadGroup()
    val threadCount = rootGroup.activeCount()
    val threads: Array<JavaThread?> = arrayOfNulls(threadCount)
    rootGroup.enumerate(threads)
    return threads.filterNotNull()
}

Though I agree, that while capturing this info some thread could moved to different states. But again this is for observability and debugging the system state purposes, so this should be fine. I also read the oracle doc(ref above) and they also states the same Due to the inherent race condition in this method, it is recommended that the method only be used for debugging and monitoring purposes.

Also in mobile, most of the tools show this info in the the dashboard as sometimes your bugs, crashes can happen due to some other thread doing something

I think that the semantic conventions don't yet cover this case. We would need to update the semconv to create an array of "other threads" or something. Please give that some consideration.

I agree with this, we could define other_threads property

[fractalwrench]

There can be a lot of threads in mobile applications (I've seen 300+ threads in prod before) & tracing all the threads can be a pretty expensive operation that bloats the size of exported telemetry. IMO capturing this data via ApplicationExitInfo would be a good way of doing it as it correlates with Google's ANR metrics, and it's theoretically possible to parse the report on the client & select only the interesting threads.