`set_worker_thread_count(1)` causes a hang if the input file has debug info

[psifertex]

Newly introduced in 4.0, this behavior previously worked in 3.5 but now will cause the process to hang with 0% CPU utilization. Using any other value than 1 works fine.

[xusheng6]

I cannot reproduce this. Any other info available?

[psifertex]

Nope, it worked exactly as the customer reported when I tried it. I did it with Python 3.12 headlessly

[xusheng6]

I can reproduce this with the following script:

import binaryninja
print(f"Using binja version {binaryninja.__version__}")
binaryninja.set_worker_thread_count(1)
with binaryninja.load(r"C:\Windows\notepad.exe") as bv:
    print(f"Opening {bv.file.filename} which has {len(list(bv.functions))} functions")

Things to note:

1. It only affects Windows
2. It only affects headless
3. It seems to only affect a binary with PDB symbols. I tried a few other samples and it seems to work just fine

[xusheng6]

Update on this:

1. This is related to the PDB parsing. If I set corePlugins.pdbImport to false and then load the file, it works fine. If I load an .exe with no PDB symbol, it works fine
2. This is actually NOT Windows specific. It affects macOS in the very same way. We previously believe it to be Windows only because it is not handy to find a file with PDB symbols on macOS

[xusheng6]

The dynamics of the hang is like:

1. The debug info parser code runs on a worker thread
2. The debug info parser uses SymbolQueue which wants some job done on another worker thread, and blocks on it to wait for it
3. There is only one worker thread, and it hangs

Note, our binary view types are also using the SymbolQueue to handle the bulk addition of symbols. However, they do not cause a hang because in that case, the SymbolQueue itself runs on the main thread, and it can ask the only worker thread to do some job for it.

[xusheng6]

This is broken in 3.6.4689-dev