qilingframework
ql.os.stop() not work for Linux when multithread=True
Describe the bug
When emulating a linux binary with multithread=True, calling ql.os.stop() to stop emulation didn't work as expected.
After a simple analysis, it seems that the self.threads of QlLinuxThreadManagement is always empty. No threads are added to it according to the code. As a result, when calling ql.os.stop(), no threads will be killed.
https://github.com/qilingframework/qiling/blob/272a3da410da17e6f8c8ff00f09ce762b7766203/qiling/os/linux/thread.py#L585-L590
A possible fix this is to add self.cur_thread into self.threads, maybe in QlLinuxThreadManagement.run() method. Or there is a better place to do it?
By the way, ql.emu_stop() is used for this purpose when multithread=False, and ql.os.stop() is used when multithread=True. Of course, calling ql.os.stop() work well in both cases. To make it consistent, maybe it's better to move ql.os.stop() into ql.stop(). Then use ql.stop() in all cases.
Sample Code
Taken from the examples/hello_x8664_linux_part_debug.py, and make minor changes. In this case, the function dump() will be called multiple times.
def dump(ql, *args, **kw):
ql.save(reg=False, cpu_context=True, snapshot="/tmp/snapshot.bin")
ql.log.info("here")
ql.os.stop()
if __name__ == "__main__":
ql = Qiling(["rootfs/x8664_linux/bin/sleep_hello"], "rootfs/x8664_linux", verbose=QL_VERBOSE.DEFAULT, multithread=True)
# load base address from profile file
X64BASE = int(ql.profile.get("OS64", "load_address"), 16)
# take a snapshot
ql.hook_address(dump, X64BASE + 0x1094)
ql.run()
Why not simply call ql.stop for multithread case?
From: kj.xwings.l @.> Sent: Friday, August 13, 2021 5:56:50 PM To: qilingframework/qiling @.> Cc: lazymio @.>; Mention @.> Subject: Re: [qilingframework/qiling] ql.os.stop() not work for Linux when multithread=True (#884)
@wtdcodehttps://github.com/wtdcode whats your thought ?
― You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/qilingframework/qiling/issues/884#issuecomment-898340487, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AHJULO5355Z2JWEZ33KEDZ3T4TT6FANCNFSM5CA6AW2A.
@wtdcode There is no ql.stop() currently if I didn't miss it, only ql.os.stop(), and it works for both cases. And my suggestion is:
To make it consistent, maybe it's better to move ql.os.stop() into ql.stop(). Then use ql.stop() in all cases.
Looks like stop_thread should be called instead of gevent.kill. Would check it later.
From: CQ @.> Sent: Friday, August 13, 2021 6:11:29 PM To: qilingframework/qiling @.> Cc: lazymio @.>; Mention @.> Subject: Re: [qilingframework/qiling] ql.os.stop() not work for Linux when multithread=True (#884)
@wtdcodehttps://github.com/wtdcode There is no ql.stop() currently if I didn't miss it, only ql.os.stop(), and it works for both cases. And my suggestion is:
To make it consistent, maybe it's better to move ql.os.stop() into ql.stop(). Then use ql.stop() in all cases.
― You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/qilingframework/qiling/issues/884#issuecomment-898349474, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AHJULOYTZOWJGF54EE7Y6PDT4TVVDANCNFSM5CA6AW2A.
Is this problem solved? I also encountered the problem that multithread could not stop in qiling v1.4.2.
Is this problem solved? I also encountered the problem that multithread could not stop in qiling v1.4.2.
We are still facing issue witu threadmanagement. Which is very ticky to solve. Currently we do have some idea but is not that easy. If you have any suggestion, please update in issue #333