-
Notifications
You must be signed in to change notification settings - Fork 745
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ql.os.stop() not work for Linux when multithread=True #884
Comments
@wtdcode whats your thought ? |
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)
@wtdcode<https://github.com/wtdcode> whats your thought ?
―
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<#884 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AHJULO5355Z2JWEZ33KEDZ3T4TT6FANCNFSM5CA6AW2A>.
|
@wtdcode There is no
|
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)
@wtdcode<https://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 GitHub<#884 (comment)>, or unsubscribe<https://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. |
1 similar comment
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 |
Describe the bug
When emulating a linux binary with
multithread=True
, callingql.os.stop()
to stop emulation didn't work as expected.After a simple analysis, it seems that the
self.threads
ofQlLinuxThreadManagement
is always empty. No threads are added to it according to the code. As a result, when callingql.os.stop()
, no threads will be killed.qiling/qiling/os/linux/thread.py
Lines 585 to 590 in 272a3da
A possible fix this is to add
self.cur_thread
intoself.threads
, maybe inQlLinuxThreadManagement.run()
method. Or there is a better place to do it?By the way,
ql.emu_stop()
is used for this purpose whenmultithread=False
, andql.os.stop()
is used whenmultithread=True
. Of course, callingql.os.stop()
work well in both cases. To make it consistent, maybe it's better to moveql.os.stop()
intoql.stop()
. Then useql.stop()
in all cases.Sample Code
Taken from the
examples/hello_x8664_linux_part_debug.py
, and make minor changes. In this case, the functiondump()
will be called multiple times.The text was updated successfully, but these errors were encountered: