Bug 1116957
| Summary: | GDB Python GIL handling with gdb.execute("continue") | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Developer Toolset | Reporter: | Bryan Totty <btotty> | ||||
| Component: | gdb | Assignee: | Jan Kratochvil <jan.kratochvil> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Martin Cermak <mcermak> | ||||
| Severity: | low | Docs Contact: | |||||
| Priority: | low | ||||||
| Version: | DTS 2.1 RHEL 6 | CC: | jan.kratochvil, mcermak, mfranc, patrickm | ||||
| Target Milestone: | beta2 | ||||||
| Target Release: | 3.0 | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | devtoolset-3-gdb-7.8-18.el6 | Doc Type: | Bug Fix | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2014-10-30 09:38:09 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
As this is coming from Python (the gdb.execute python syntax) the GIL is already acquired by the Python interpreter. As it enters the GDB code, GDB calls execute_command on the given command and waits for the result to finish. So as correctly pointed here in this bz, the GIL will block for the amount of time the GDB command takes. We should release the GIL in GDB before we execute the internal GDB code for this command, and reacquire it after the GDB command has completed.
As a point of interest, if you pass the & operand to the command, does it improve your situation?
E.g, gdb.execute ("continue &")
This will tell GDB to not wait.
Created attachment 926448 [details]
Path to GDB for gdb.command to optionally release GIL
This patches allows the optional release of the Python GIL when gdb.command() is executed. To maintain backwards compatibility this feature has been implemented by specifying a new keyword. The keyword "release_gil" now accepts True or False, and will release the GIL accordingly.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHEA-2014-1756.html |
Problem: Unable to run anything in a background thread inside GDB when the main thread does an gdb.execute("continue"). It would appear the GIL is still helped by the thread and that the lock should be released when the target enters a running state. ------ $ /bin/sleep 100000 & gdb -p $! -x t.py --batch I would expect it to print BG Thread every second. However, it does seem that GDB holds the lock while actually blocking on IO in the main thread, effectively preventing the background thread from doing anything useful. ------ Workaround: Run a main loop via a GDB command language script, which invokes a Python convenience function. It still needs interrupt via sending a signal to the main thread which isn't pretty but good enough for now. ---------- import threading import time running = True def run(): while running: print 'BG Thread' time.sleep(1) t = threading.Thread(target=run) t.start() gdb.execute('continue') running = False t.join() ---------- Additional Information: Python 3.x still has the GIL. http://www.rfk.id.au/blog/entry/a-gil-adventure-threading2/ Suggests making use of processor affinity but it doesn't work for everybody.