Yuheng Zou <zouyuheng1...@gmail.com> writes:
> ...
> I built a C++ library which contains EvalFrame function, and then use dlopen
> and dlsym to use it. It looks like this:
>
> extern "C" PyObject *EvalFrame(PyFrameObject *f, int throwflag) {
> return _PyEval_EvalFrameDefault(f, throwflag);
> }
> I added following code to Python/pylifecycle.c at function
> _Py_InitializeEx_Private(Python version is 3.6.1):
>
> void *pyjit = NULL;
> pyjit = dlopen("../cmake-build-debug/libPubbon.dylib", 0);
> if (pyjit != NULL) {
> interp->eval_frame = (_PyFrameEvalFunction)dlsym(pyjit, "EvalFrame");
> //interp->eval_frame = _PyEval_EvalFrameDefault;
> }
> Then something strange happened. I used LLDB to trace the variables. When it
> ran at EvalFrame, the address of f pointer didn't change, but f->f_lineno
> changed.
>
It may not be very surprising that the lineno changes during execution.
It should correspond to the line of the code currently executed.
> Then when I ran python.exe, I got Segmentation Fault.
>
> Why the address of the pointer didn't change, but the context change?
Some structure fields (such as lineno) may be expected to change.
In addition, the interpreter is using some global variables to
maintain state - variables that may change e.g. during thread switches.
The "SIGSEGV" might indicate that the structure has been freed --
and is now used for different things.
--
https://mail.python.org/mailman/listinfo/python-list
