[gui] Task execution finishes too quickly causing incomplete termination or stuck waiting state

[z2010643575]

Issue details

Summary When a stage contains lightweight text file reading tasks that complete almost instantly, the stopExecution() method may never be called, and the main thread gets stuck in waitTermination().

Steps to Reproduce

Create a stage with one or more very fast text file reading tasks.

Run the task pipeline sequentially (ExecType.SEQUENTIAL).

Observe that the UI or waiting loop never exits (waitTermination(Supplier<TaskStatus> cancelCheck) loop continues indefinitely).

Expected Behavior stopExecution() should always be invoked even when tasks complete immediately.

Actual Behavior The loop never terminates due to a timing race — the task finishes before internal state updates occur.

Temporary Workaround Add a small delay (Thread.sleep(200)) before executing each task inside wrapTask(Runnable task) to prevent the race condition. This is my current workaround, but I’d appreciate a better or more proper fix from your side.

Jadx version

1.5.3

Java version

21.0.6 2025-01-21 LTS

OS

• [x] Windows
• [ ] Linux
• [ ] macOS

[skylot]

@z2010643575 looks like this issue was fixed in 104a0f063646910dddee4ddc0ae7203508e0d042. Can you check latest master commit or latest unstable build?

[z2010643575]

@z2010643575 looks like this issue was fixed in 104a0f0. Can you check latest master commit or latest unstable build?

It doesn’t work it seems that this commit didn’t actually fix the issue. I checked the code I pulled from Git, and it’s the same as yours, but the bug is still not resolved.

[z2010643575]

You can check the video I sent — opening text files like "xposed_init" almost always causes a freeze, but other files don’t seem to have this issue.

During my multiple debugging attempts, the code inside the waitTermination(Supplier<TaskStatus> cancelCheck) function kept looping indefinitely and never executed the stopExecution() function.

https://github.com/user-attachments/assets/5a8702f8-5132-4ab5-967e-a3b7c85f7c1b

[skylot]

@z2010643575 thank you for details :+1: I was able to reproduce this issue and looks like the cause is a deadlock while updating UI inside background thread in code area loading code. I managed split loading and UI update, but fix still not finished because of other issues. Hope I will complete it in next few days.

[z2010643575]

@z2010643575 thank you for details 👍 I was able to reproduce this issue and looks like the cause is a deadlock while updating UI inside background thread in code area loading code. I managed split loading and UI update, but fix still not finished because of other issues. Hope I will complete it in next few days.

Thank you for your hard work

[skylot]

@z2010643575 I commit changes to split background and UI loading for code area, this fixed the issue. Also, I reworked background executor to remove processing delay for short tasks: progress UI updates moved into another thread and don't affect tasks execution anymore. These changes are quite big, so please check them using latest master or latest unstable build.

[z2010643575]

@z2010643575 I commit changes to split background and UI loading for code area, this fixed the issue. Also, I reworked background executor to remove processing delay for short tasks: progress UI updates moved into another thread and don't affect tasks execution anymore. These changes are quite big, so please check them using latest master or latest unstable build.

Okay, thank you for your hard work.