OSX 10.13中dtruss报错‘dynamic variable drops with non-empty dirty list’含义及排查
Let’s break this down clearly, starting with the error message you’re seeing, then moving to actionable fixes for your connect freeze issue.
What does the "783 dynamic variable drops with non-empty dirty list" message mean?
This is an internal warning from DTrace (the underlying tool powering dtruss) that signals a resource bottleneck in your tracing session:
- Dynamic variable drops: DTrace uses temporary dynamic variables to track state during tracing (like syscall arguments, timestamps, or counts). When DTrace runs out of buffer space or can’t keep up with the flood of events from your target process, it has to discard these unprocessed variable updates.
- Non-empty dirty list: This means there were pending variable changes that hadn’t been flushed to DTrace’s buffers before they were dropped.
In your case, this is almost certainly happening because dtruss is defaulting to tracing every single system call for your process. When the process hangs on connect, the volume of background syscalls (plus the stuck connect event) overwhelms DTrace’s default buffer limits, causing dtruss itself to freeze under the load.
Troubleshooting Steps to Diagnose the Connect Freeze
1. Narrow Your Tracing Scope
Instead of tracing all syscalls, focus only on socket-related operations to cut down on event volume. Use the -c flag with dtruss to specify exactly the calls you care about:
dtruss -c connect,socket,recv,send -p <YOUR_PROCESS_PID>
This limits tracing to just the socket operations relevant to your connection issue, reducing the chance of DTrace hitting resource limits.
2. Increase DTrace Buffer Size
DTrace’s default buffer is often too small for busy processes. Use the -b flag to allocate a larger buffer (e.g., 10MB) to give DTrace more breathing room:
dtruss -b 10m -p <YOUR_PROCESS_PID>
A bigger buffer reduces the likelihood of variable drops and dtruss freezes by giving the tool more space to store events before processing them.
3. Use a Custom DTrace Script (Instead of dtruss)
dtruss is a general-purpose wrapper—writing a minimal custom DTrace script is more efficient for your specific use case. Here’s a script that only tracks connect entry and return, including critical error details:
#!/usr/sbin/dtrace -s syscall::connect:entry /pid == $1/ { printf("[%d] connect() called on fd %d, target address: %p\n", pid, arg0, arg1); } syscall::connect:return /pid == $1/ { printf("[%d] connect() returned %d, errno: %d\n", pid, arg0, errno); }
Save this as connect_trace.d, then run it with:
dtrace -s connect_trace.d <YOUR_PROCESS_PID>
This lightweight script focuses exactly on the connect call, so it’s far less likely to freeze or drop variables. The return value and errno will tell you if the call is failing, hanging, or stuck in a kernel state.
4. Complement DTrace with Other macOS Tools
If DTrace is still giving you trouble, use these tools to gather more context about the frozen process:
- Check process state: Run
ps aux | grep <PID>and look at theSTATcolumn. A state ofDmeans the process is in an uninterruptible sleep—this usually indicates it’s waiting on a kernel resource (like network I/O or disk). - Inspect open sockets: Use
lsof -p <PID>to list all file descriptors for the process. Look for socket entries and note their state (e.g.,SYN_SENTmeans the process is waiting for a SYN-ACK from the remote server). - Check network state: Run
netstat -an | grep <REMOTE_PORT>to see the status of the network connection. If it’s stuck inSYN_SENT, the issue might be network-related (firewall, remote server downtime, routing problems) rather than a bug in your process.
5. Verify SIP Status (macOS 10.13 Specific)
System Integrity Protection (SIP) on macOS can restrict DTrace’s ability to trace certain system processes. If you’re tracing a system-owned process, you may need to disable SIP temporarily (note: this reduces security, so re-enable it after troubleshooting). To check SIP status:
csrutil status
内容的提问来源于stack exchange,提问作者horseyguy

