7

I have been developing with React Native for some years now but the following behaviour only started recently. After running any React Native app on the iOS simulator (either directly from Xcode or via react-native run-ios) the diagnosticd process slowly increases CPU usage to 150% after a couple of minutes. My laptop becomes unusable because the process is also eating up all file handles of the OS. Googling around only points to excessive logging, but either I'm not looking in the right location or no huge amounts of logging is taking place.

Closing the app by pressing the Home button in the simulator immediately stops the high cpu load.

Is anybody also experiencing this? How can I find out what is causing this?

MacOS Catalina version 10.15.3, Xcode version 11.4, React version 16.9.0, React Native version 0.61.5, Simulator iPhone 11 (iOS 13.4)

mvandillen
  • 904
  • 10
  • 17

5 Answers5

4

I think I found the solution. Xcode was logging a lot of lines containing: xcode nw_connection_get_connected_socket Client called nw_connection_get_connected_socket on unconnected nw_connection. This started after some update of Xcode a couple of months ago. Disabling the logging has stopped the diagnosticd process from eating up all OS resources. I followed these instructions: Hide strange unwanted Xcode logs

Basically comes down to adding an environment variable OS_ACTIVITY_MODE with value disable to the Scheme (Run).

What the real reason for the logging is I still don't know. It looks like some sort of polling from React Native.

mvandillen
  • 904
  • 10
  • 17
  • Oops. I spoke too soon. The diagnosticd process is running fine now, but something is still using up resources so my system still becomes unstable after a couple of minutes. Chrome crashing etc. Probably due to depletion of available file (network socket?) handles. – mvandillen Jun 08 '20 at 08:48
  • Found the solution, see my other answer! – mvandillen May 20 '21 at 13:57
0

It's more of a workaround than a solution, but it seems that resetting the simulator to factory default temporary fix this problem (at least on my case).

It looks like diagnosticd is processing some files which may be located on the simulator internal memory, so it may takes more and more cpu as the files are growing over time ?

Anyway try to go to the simulator menu : Hardware -> Erase All Content and Settings Then close the simulator and start it again from XCode in order to copy your app on it.

Nicolas
  • 127
  • 1
  • 10
  • Killing the app itself on the simulator and restarting it seems to do the same for me, but as a workaround it only lasts for a couple of minutes. I also get an error in some other running applications that the OS is out of file descriptors, so I'm guessing it's not some big files on the simulator but a very huge number of small files that are being opened over time (and possibly not closed due to the high cpu usage?). I wish someone with more knowledge of the OS could find out which files these are and what's in it. – mvandillen Apr 28 '20 at 07:40
  • In this case you must have a completely other problem than me. diagnosticd was also eating CPU but not as much as you and resetting the erasing the simulator fix that temporary (I don't know for how long though it's been two days and the problem still hasn't come back). – Nicolas Apr 29 '20 at 08:23
  • I am interested on your problem since it's not far from mine. It would be interesting to try to guess what is diagnosticd is actually doing when the cpu usage is high (I can't do this on my computer since I don't have the problem anymore). With the terminal you can see the list of open files of all processes with lsof, if you type lsof | grep diagnosticd you will see every file opened by diagnosticd and its process id pid. You can also see all system calls with the command dtruss -p PID_Number Can you try that when there is a high cpu usage ? – Nicolas Apr 29 '20 at 08:25
  • Thank you for your suggestions. I had already tried that but couldn't make any sense of the output. I have pasted in a chat room, let's continue over there. https://chat.stackoverflow.com/rooms/212792/high-cpu-load-of-diagnosticd-process-while-running-react-native-app-on-ios-simula – mvandillen Apr 29 '20 at 13:42
  • It seems my chat room has been deleted by a moderator. Please let me know how to reach you – mvandillen May 07 '20 at 08:31
0

workaround from Xcode 9.3 Playground - diagnosticd,

kill $(ps -ef | grep Xcode.app | egrep "diagnosticd|homed" | awk '{ print $2 }')

I found this to be useful

  • Thanks for your suggestion, I tried it. Killing the diagnosticd process doesn't help. It immediately comes back with the same high cpu usage. I've also tried another approach using `/bin/launchctl list | grep SimDevice | awk '{print $3}' | xargs -I %s /bin/launchctl stop %s`. That definitely kills the diagnosticd process, but unfortunately also the complete simulator with it. – mvandillen May 14 '20 at 06:56
  • yea, launchctl ended up working for me as well, but a bit diffrent approach, ```sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.diagnosticd.plist```. However this may require you turn off SIP... Good Luck! – TheNumberOneD May 15 '20 at 01:56
  • I found a solution in disabling the logging from Xcode. See my own answer for details. Thanks for your help! – mvandillen Jun 08 '20 at 08:41
0

Finally found the solution! I was always wondering why the default url in AppDelegate.m did not work. So I started focusing on that. It turns out that my huge adblocking hosts file was the cause of this. Restoring the original /etc/hosts file solved both problems!

mvandillen
  • 904
  • 10
  • 17
-1

One more thing you can try, this is a very drastic measure and only do this at your own risk,

first try this,

sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.diagnosticd.plist

and if you get a message about system protection (SIP),

you can try turning off SIP, then running that command again,

That will pretty much guarantee diagnosticd never run's again... no idea about the implications of that though...

read more about those two things here,

https://makandracards.com/dev/16439-disable-daemons-services-in-mac-os-x

https://www.imore.com/how-turn-system-integrity-protection-macos

*disclaimer, this is probably not the safest solution messing with SIP, but I did it on my old 2015 i5 macbook because I was getting desperate, and literally couldn't do any work on simulator with the diagnosticd bug.

So far everything seems happy...

  • Thanks for your suggestions. I have tried renaming the diagnosticd application before, but the simulator wouldn't start anymore without it. Are you sure it starts when disabled by launchctl? And what about debugging from Xcode? Is that still working? – mvandillen May 19 '20 at 07:15
  • yes, for me everything still works after `sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.diagnosticd.plist` I will note that there is still seems to be diagnostid that spins up, but it's only 1 now and not 2 like before, and it seems like the one that is still spun up is the lighter of the 2, the one that only takes up 50% of one core when app is open. The diagnostid that took up 150% + is gone for me now, which makes my system a lot more stable. Also the logging seems to be fine, at-least the logs i look at, the ones in the bottom tab. – TheNumberOneD Jun 03 '20 at 23:45
  • I found a solution in disabling the logging from Xcode. See my own answer for details. Thanks for your help! – mvandillen Jun 08 '20 at 08:41