Skip to content

Conversation

@pablogsal
Copy link
Member

@pablogsal pablogsal commented Oct 20, 2017

The docs for sys.settrace mention that:

event is a string: 'call', 'line', 'return', 'exception', 'c_call', 'c_return', or 'c_exception'

But in the code for ceval.c the only point where call_trace is invoked with PyTrace_C_CALL or PyTrace_C_RETURN is under the C_TRACE macro. In this macro this line prevents any function set up using sys.settrace to call call_trace with the mentioned arguments:

if (tstate->use_tracing && tstate->c_profilefunc)

Notice that from the code of PyEval_SetTrace and PyEval_SetProfile, only the later sets tstate->c_profilefunc and therefore only functions installed using sys.setprofile will recieve a c_call for the event:

void
PyEval_SetProfile(Py_tracefunc func, PyObject *arg)
{
     ...
    tstate->c_profilefunc = func;
    tstate->c_profileobj = arg;
    tstate->use_tracing = (func != NULL) || (tstate->c_tracefunc != NULL);
}

void
PyEval_SetTrace(Py_tracefunc func, PyObject *arg)
{
     ...
    tstate->c_tracefunc = func;
    tstate->c_traceobj = arg;
    tstate->use_tracing = ((func != NULL) || (tstate->c_profilefunc != NULL));
}

This PR updates the documentation clarifying the real behaviour of both functions.

https://bugs.python.org/issue17799

Copy link
Member

@zhangyangyu zhangyangyu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@bedevere-bot
Copy link

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phrase I have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

@pablogsal
Copy link
Member Author

I have made the requested changes; please review again

@bedevere-bot
Copy link

Thanks for making the requested changes!

@zhangyangyu: please review the changes made to this pull request.

| :const:`PyTrace_C_RETURN` | Function object being called. |
+------------------------------+--------------------------------------+
Any trace function registered using :c:func:`PyEval_SetTrace` will not recieve
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/s/recieve/receive

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! Corrected in 18b88ec

Any trace function registered using :c:func:`PyEval_SetTrace` will not receive
:const:`PyTrace_C_CALL`, :const:`PyTrace_C_EXCEPTION`, :const:`PyTrace_C_RETURN`
or :const:`PyTrace_LINE` as a value for the *what* parameter.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why line event is also here?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, I misread that part.

Set the tracing function to *func*. This is similar to
:c:func:`PyEval_SetProfile`, except the tracing function does receive line-number
events.
events or any event related to C function objects being called.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is does receive, so I think it is wrong here. Maybe just declare it does not receive PyTrace_C_CALL/RETURN/EXCEPTION here, so don't have to write the previous added block.


Profile functions should have three arguments: *frame*, *event*, and
*arg*. *frame* is the current stack frame. *event* is a string: ``'call'``,
``'line'``, ``'return'``, ``'exception'``, ``'c_call'``, ``'c_return'``, or
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

line will be received here?


``'call'``
A function is called (or some other code block entered). The
global trace function is called; *arg* is ``None``; the return value
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Although the previous doc says profile function is called similiarly to trace function, but from the implementation, there is no concept like global trace function or local trace function. And at least we call it profile function here not trace function.

@pablogsal
Copy link
Member Author

@zhangyangyu Thank you very much for the comments. I have addressed your feedback in a9f381f and 3887c6c.

profile function is called; *arg* is ``None``.

``'return'``
A function (or other code block) is about to return. The local trace
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also here and the following return, exception part about the global/local and name.

``'c_exception'``
A C function has raised an exception. *arg* is the C function object.

``'opcode'``
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

opcode events won't be triggered for profile functions, also note the above list needs also be modified.

Any trace function registered using :c:func:`PyEval_SetTrace` will not receive
:const:`PyTrace_C_CALL`, :const:`PyTrace_C_EXCEPTION` or :const:`PyTrace_C_RETURN`
as a value for the *what* parameter.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I prefer to combine this section with the specified PyEval_SetTrace part.

@pablogsal
Copy link
Member Author

@zhangyangyu Upon inspection and testing I think that profile functions cannot receive "exception" events as well. Can you confirm this?

@zhangyangyu
Copy link
Member

Yes. But profile functions receive even PyTrace_C_EXCEPTION, why not Python exception events?

@zhangyangyu
Copy link
Member

zhangyangyu commented Jan 23, 2018

From the unitest test_sys_setprofile, exception events should never be received by profile functions, so seems it's by design.

@zhangyangyu
Copy link
Member

PyEval_SetProfile should also be updated that not only line number events but also Python exception events.

@zhangyangyu
Copy link
Member

I think the following paragraph need some modification, something like "... but it is called with different events, for example ..."

The system's profile function is called similarly to the
system's trace function (see :func:settrace), but it isn't called for each
executed line of code (only on call and return, but the return event is reported
even when an exception has been set).

And your NEWS entry needs updated too. It's not only about C events now. BTW, we need a new issue to complete the C part about PyTrace_OPCODE.

@zhangyangyu zhangyangyu added needs backport to 3.6 docs Documentation in the Doc dir labels Jan 24, 2018
@miss-islington
Copy link
Contributor

Thanks @pablogsal for the PR, and @zhangyangyu for merging it 🌮🎉.. I'm working now to backport this PR to: 2.7, 3.6.
🐍🍒⛏🤖

@zhangyangyu
Copy link
Member

@pablogsal I merged it! Nice work!

@miss-islington
Copy link
Contributor

Sorry, @pablogsal and @zhangyangyu, I could not cleanly backport this to 3.6 due to a conflict.
Please backport using cherry_picker on command line.
cherry_picker 131fd7f96c619bc7eaea956e45c6337175f4b27f 3.6

@miss-islington
Copy link
Contributor

Sorry, @pablogsal and @zhangyangyu, I could not cleanly backport this to 2.7 due to a conflict.
Please backport using cherry_picker on command line.
cherry_picker 131fd7f96c619bc7eaea956e45c6337175f4b27f 2.7

zhangyangyu pushed a commit to zhangyangyu/cpython that referenced this pull request Jan 24, 2018
@bedevere-bot
Copy link

GH-5298 is a backport of this pull request to the 3.6 branch.

zhangyangyu pushed a commit to zhangyangyu/cpython that referenced this pull request Jan 24, 2018
@bedevere-bot
Copy link

GH-5299 is a backport of this pull request to the 2.7 branch.

zhangyangyu added a commit that referenced this pull request Jan 24, 2018
zhangyangyu added a commit that referenced this pull request Jan 24, 2018
@pablogsal pablogsal deleted the 17799 branch May 19, 2021 18:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

docs Documentation in the Doc dir

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants