Sampling profiler fails to display user-defined function in IDLE when started with the run command

[smontanaro]

Bug report

Bug description:

This is my simple test running IDLE at profiler startup (sudo as I'm running on a Mac, YMMV):

sudo -E ./python.exe -m profiling.sampling run -a --realtime-stats -d 99999 --live -m idlelib

As expected, I can also attach to a running IDLE session:

sudo -E ./python.exe -m profiling.sampling attach -a --realtime-stats -d 99999 --live <PID>

The two versions display things differently. If I attach to a running IDLE, define fib(), then call it with a large n (say, 200), it will run for a while before returning a result. I can see the recursive calls to fib in the display.

If I use the run command instead, I never see fib show in the display. Instead, I see something like this:

It appears all the samples in fib are credited to Misc.mainloop. I know the function is executing, given that small-n calls return quickly with the correct result, but shouldn't fib show up in the display when called with a large value for n if I use the run command to start IDLE?

CPython versions tested on:

CPython main branch

Operating systems tested on:

macOS

[ned-deily]

Dunno if this will help but normally IDLE uses more than one process. There is a deprecated option to run everything in one process: -m idlelib -n.

[terryjreedy]

When you used 'run', did you enter 'fib' directly into shell, or run from editor?

When you used 'attach', how did you start IDLE

[terryjreedy]

Ned's comment is the point of my 2nd question. For the attach result, it looks like fib was being run in the IDLE process instead of a user process.

[smontanaro]

Thanks for the responses. I'll try to answer all questions in one comment.

• When attaching, I ran IDLE in a separate shell as ./python.exe -m idlelib.
• I always manually typed the fibonacci function in at the IDLE prompt.
• Starting up IDLE with the deprecated -n option (as part of the tachyon command) solves the problem. I now see fib in the displayed functions.

Does that last point imply that the profiler needs to dive deeper into the subprocesses the profiled command runs? Or am I missing some "follow fork" option? (I saw nothing in the -h output or the interactive help.)