Bug 1373043

Summary:	RFE: would like extra dtrace/systemtap/gdb tracing for PyCFunction_Call
Product:	[Fedora] Fedora	Reporter:	Frank Ch. Eigler <fche>
Component:	python3	Assignee:	Charalampos Stratakis <cstratak>
Status:	CLOSED UPSTREAM	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	rawhide	CC:	bkabrda, cstratak, dmalcolm, dsmith, ivazqueznet, jonathansteffan, mcyprian, mhroncok, ncoghlan, pviktori, rkuska, scox, tomspur, torsava
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2018-01-19 17:39:57 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:

Description Frank Ch. Eigler 2016-09-05 01:21:36 UTC

The fedora/RHEL-only :-( 00055-* patch for python2 (and similar for python3) adds sys/sdt.h macro calls wrapped into dtrace_enter/exit into PyEval_EvalFrameEx().  This allows a systemtap script (or gdb) to trap events when a python function is being entered or exited, and permit fairly high performance tracing or analysis.

The problem is that C functions called from a python function are not reported.  This makes opaque the internal operation of python programs that use a lot of C bits (time.sleep(), lock.acquire), etc.

Please consider adding analogous dtrace_entry / dtrace_exit calls to the C function calling path, such as within PyCFunction_Call(), describing the PyCFunctionObject's name/location etc. as similarly as possible as the python function calls do.

Comment 1 Fedora Admin XMLRPC Client 2017-01-10 18:49:00 UTC

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 2 Frank Ch. Eigler 2017-01-10 18:52:47 UTC

The instrumentation added to python 3.6 via upstream:

% stap -L 'process("/usr/lib64/libpython3*so*").mark("*")'
process("/usr/lib64/libpython3.6m.so.1.0").mark("function__entry") $arg1:long $arg2:long $arg3:long
process("/usr/lib64/libpython3.6m.so.1.0").mark("function__return") $arg1:long $arg2:long $arg3:long
process("/usr/lib64/libpython3.6m.so.1.0").mark("gc__done") $arg1:long
process("/usr/lib64/libpython3.6m.so.1.0").mark("gc__start") $arg1:long
process("/usr/lib64/libpython3.6m.so.1.0").mark("line") $arg1:long $arg2:long $arg3:long

is a nice step, except that the C functions are still not visible.

Comment 3 Petr Viktorin 2018-01-18 14:18:28 UTC

This is a low priority for us.

systemtap support is upstream now, however. Please open an issue there if you want to push this further.

Comment 4 Frank Ch. Eigler 2018-01-19 17:39:57 UTC

OK, thanks.  https://bugs.python.org/issue32599