You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Unity has a complex process tree including kicking off a bunch of dotnet processes, that are lunched via dotnet exec MyProgram.dll. All of these show up just as dotnet, which is not super useful for figuring out what's what :)
I'm thinking to do a local hack for when a process name is dotnet to grab the pid and use proc_pidinfo to get the command line, but I'm unsure if it's safe to do this during TaskProfiler::new just due to it being unclear how long that operation would take. I'm assuming the risk would be some lost samples on process startup, right?
Also, if I were to generalize this to a PR, it would probably look something like an argument to record that's something like... --use_arg_for_command_name dotnet:2 which means "if the command is dotnet, use argv[2] as the recorded command name". Does that sound reasonable?
The text was updated successfully, but these errors were encountered:
I guess dotnet doesn't do this but if you set /proc/pid/comm of the main thread then samply will rename the process accordingly. We use this pretty extensively when profiling Wine apps.
In #274 I added an --include-args (or --include-args=5) argument. We will see if proc_pidinfo on macOS is fast enough.
On Linux, renaming the process will still work as before; it will overwrite the old name including the arguments.
Also, if I were to generalize this to a PR, it would probably look something like an argument to record that's something like... --use_arg_for_command_name dotnet:2 which means "if the command is dotnet, use argv[2] as the recorded command name". Does that sound reasonable?
Unity has a complex process tree including kicking off a bunch of dotnet processes, that are lunched via
dotnet exec MyProgram.dll
. All of these show up just asdotnet
, which is not super useful for figuring out what's what :)I'm thinking to do a local hack for when a process name is
dotnet
to grab the pid and useproc_pidinfo
to get the command line, but I'm unsure if it's safe to do this duringTaskProfiler::new
just due to it being unclear how long that operation would take. I'm assuming the risk would be some lost samples on process startup, right?Also, if I were to generalize this to a PR, it would probably look something like an argument to
record
that's something like...--use_arg_for_command_name dotnet:2
which means "if the command isdotnet
, useargv[2]
as the recorded command name". Does that sound reasonable?The text was updated successfully, but these errors were encountered: