all: parallelize symbolize

[jiangenj]

1. symbolize takes much time especially if there are hundreds of modules and many pcs.
2. concurrent writing to slice without protection will result in race condition, see https://blog.sgkandale.com/appending-slice-from-multiple-goroutines-86bc1c821e9e.

The PR is to fix these two issues:

1. by symbolize each module in different goroutine.
2. protect concurrent writing to slice using channel.

---

Before sending a pull request, please review Contribution Guidelines:
https://github.com/google/syzkaller/blob/master/docs/contributing.md

---

[dvyukov]

What exactly is the issue?
This type is not supposed to be used concurrently, perhaps there is a bug in the caller.
It's used in the symbolizer, which is not thread-safe either.

[jiangenj]

The current merged master branch doesn’t have issue. But I have coming changes which will parallel to use the symbolizer, then it will report goroutine concurrency issue. Those changes are a little big, so I submit this PR first as it doesn’t influence existing code anyway. From: Dmitry Vyukov ***@***.***> Sent: Thursday, May 9, 2024 3:39 PM To: google/syzkaller ***@***.***> Cc: Joey Jiao (QUIC) ***@***.***>; Author ***@***.***> Subject: Re: [google/syzkaller] pkg/symbolizzer: use thread safe sync.Map to avoid concurrency issue (PR #4787) @dvyukov requested changes on this pull request. What exactly is the issue? This type is not supposed to be used concurrently, perhaps there is a bug in the caller. It's used in the symbolizer, which is not thread-safe either. — Reply to this email directly, view it on GitHub<#4787 (review)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/BCHNAODNKJYFMZ2UOED3KWLZBMR2ZAVCNFSM6AAAAABHN5IBXGVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDANBXGM2DCNZYGM>. You are receiving this because you authored the thread.Message ID: ***@***.******@***.***>>

[dvyukov]

Please show the other changes where this is needed. Otherwise it's impossible to understand if this is the right approach or not.
There should be some synchronization in the symbolizer, possibly the interner should be protected by the same synchronization.
Symbolizer is also not used concurrently by manager now, so I would like to understand what you want to do with manager to use symbolizer concurrently.
Frequently using synchronization in the lowest-level primitives is the wrong approach.

[codecov]

Codecov Report

Attention: Patch coverage is 4.22535% with 68 lines in your changes are missing coverage. Please review.

Project coverage is 61.1%. Comparing base (9026e14) to head (bb831fb).

Additional details and impacted files

Files	Coverage Δ
pkg/symbolizer/cache.go	100.0% <100.0%> (ø)
pkg/cover/backend/dwarf.go	11.3% <0.0%> (-0.8%)	⬇️

... and 1 file with indirect coverage changes

[jiangenj]

Please show the other changes where this is needed. Otherwise it's impossible to understand if this is the right approach or not. There should be some synchronization in the symbolizer, possibly the interner should be protected by the same synchronization. Symbolizer is also not used concurrently by manager now, so I would like to understand what you want to do with manager to use symbolizer concurrently. Frequently using synchronization in the lowest-level primitives is the wrong approach.

updated the PR, please check again.

[jiangenj]

@dvyukov Can you review this?