Hi,
I'm Arnaud Diederen, one of the developers at www.hex-rays.com, and contributor to IDAPython (Python bindings to IDA's API.)
The following discussion will require the following bits of background:
- IDA is the main application
- IDAPython is an IDA plugin, loaded very early by IDA, that loads python2.7.dll
- IDA has a WinDbg debugger backend
- IDA provides an input field for the WinDbg debugger backend, so that users can type WinDbg commands directly
Recently, one of our customers came to us saying that trying to ".load pykd" causes IDA to crash.
---
I could reproduce the issue, and came to the following conclusions: at setup time ( https://pykd.codeplex.com/SourceControl/latest#branch/0.3.x/pykd/windbgext.cpp ), pykd does the following:
- Py_Initialize();
- PyEval_InitThreads();
- python::object main = boost::python::import("__main__");
This third statement causes the crash, because the current 'thread' (from a Python runtime point-of-view) is NULL, because Py_Initialize() is a no-op in this case: the Python runtime had already been initialized earlier by the IDAPython plugin.
Unless I'm mistaken, the issue here lies with pykd assuming that it initializes the runtime itself and thus can perform CPython calls.
Is my understanding correct?
If so, do you think there's a way/need to fix this, or is this a use-case you don't really want to support?
Thank you for any feedback,
A.
Comments: ** Comment from web user: ussrhero **
I'm Arnaud Diederen, one of the developers at www.hex-rays.com, and contributor to IDAPython (Python bindings to IDA's API.)
The following discussion will require the following bits of background:
- IDA is the main application
- IDAPython is an IDA plugin, loaded very early by IDA, that loads python2.7.dll
- IDA has a WinDbg debugger backend
- IDA provides an input field for the WinDbg debugger backend, so that users can type WinDbg commands directly
Recently, one of our customers came to us saying that trying to ".load pykd" causes IDA to crash.
---
I could reproduce the issue, and came to the following conclusions: at setup time ( https://pykd.codeplex.com/SourceControl/latest#branch/0.3.x/pykd/windbgext.cpp ), pykd does the following:
- Py_Initialize();
- PyEval_InitThreads();
- python::object main = boost::python::import("__main__");
This third statement causes the crash, because the current 'thread' (from a Python runtime point-of-view) is NULL, because Py_Initialize() is a no-op in this case: the Python runtime had already been initialized earlier by the IDAPython plugin.
Unless I'm mistaken, the issue here lies with pykd assuming that it initializes the runtime itself and thus can perform CPython calls.
Is my understanding correct?
If so, do you think there's a way/need to fix this, or is this a use-case you don't really want to support?
Thank you for any feedback,
A.
Comments: ** Comment from web user: ussrhero **
I think, you should use pykd as a ordinal python module. A long time ago I run pykd under IDA 6.6:
```
Python>import pykd
Python>pykd.initialize()
Python>print pykd.module('ntdll')
Module: ntdll
Start: 77d00000 End: 77e79000 Size: 179000
Image: C:\WINDOWS\SYSTEM32\ntdll.dll
Symbols: c:\mss\wntdll.pdb\F42E56BB23DF4C2A9CAA683DA90E032F1\wntdll.pdb
Timestamp: 55c599e1
Check Sum: 176a84
```