DVT channel occasionally returns nonsense when using process_control

[JJTech0130]

Test environment

• macOS Sonoma 14.3.1
• iPhone 12 on iOS 16.1.2

Describe the bug
When calling process_control.launch(), the expected return value is the PID of the launched process, or an error. Sometimes it returns nonsense like outputReceived:fromProcess:atTime: instead, presumably because of some kind of race condition or other data coming down the DVT channel.

To Reproduce
Steps to reproduce the behavior:

1. Call process_control.launch() many times, for example:

pid = process_control.launch(bundle_id="com.apple.tips", arguments=[],
                                     kill_existing=True, start_suspended=False,
                                     environment=dict())

Expected behavior
Returning the PID of the launched process every time.

For community

⬇️ Please click the 👍 reaction instead of leaving a +1 or 👍 comment

[0xepsil0n]

@doronz88 let me handle this issue. I've been dealing with this output stuff. I will propose a fix for it. Expect an answer & PR tomorrow @JJTech0130

[0xepsil0n]

@JJTech0130 I looked at it more deeply and it is something that is by design. If we do a change to it, IMO, it wouldn't make sense since we would need to change the code to manage situations that shouldn't be occurring in the first place.

ANSWER

Each time you launch a process, create a channel. Do not reuse the channel.

DETAILS

When you "Call process_control.launch() many times" you reuse the channel which means all it goes through it will be mixed. It is like you mixed all output of multiple processes into the same socket connection. NOW, as you said, the output generated has this format "outputReceived:fromProcess:atTime:". Doronz (amazing) code has simplified this to not generate noise but you could actually get more information.

The function that is used to obtain the socket stream information is "receive_plist()" (pymd3/services/remote_server.py). As you'll be able to see, it only retrieves the first element. If you took the second element, you would be able to see the parameters of "outputReceived:fromProcess:atTime:" and filter out which process is telling what.

I thought about a way of mux/demux stuff to be able to reuse the channel for multiple launches but that wouldn't make any sense since the basic idea of a Channel is to create a point to point communication with a developer service. And when you launch an app, that Channel is dedicated to receiving (for example) "com.apple.tips" outputs.

IF YOU REALLY NEED TO DO IT

You should add a func like "receive_plist_with_info()" and retrieve also the second element and work from there. If you receive "outputReceived:fromProcess:atTime:" just print it / ignore it until you receive a value that can be a PID of your new process. Since you control the spawn order, it shouldn't be confused with other PIDs.

@doronz88 might have another opinion on this, but that's my take on it :)

[doronz88]

That is correct. The DVT works in "channels", which respresents different singleton objects being called in DTServiceHub. It looks like maybe you maybe triggered a selector that caused the channel to report something before the PID?

Is the launch() the only method you triggered from ProcessControl? Is so, then I can make sure this invocation will always create and close a channel for each invocation to guard it.