{
  "video_id": "reddit_1ttjtwv",
  "channel_slug": "programming",
  "channel_handle": "r/programming",
  "title": "Your process' memory is a file: The underappreciated gem that is /proc/<pid>/mem",
  "url": "https://www.reddit.com/r/programming/comments/1ttjtwv/your_process_memory_is_a_file_the/",
  "external_url": "https://lcamtuf.substack.com/p/weekend-trivia-your-process-memory",
  "upload_date": "20260601",
  "published_at": "2026-06-01T06:32:12+00:00",
  "transcript": "\n\n--- Top Comments ---\n\n\n[83 upvotes] Perfect post to plug in my /proc/*/mem grepping tool: https://github.com/eras/memgrep\n\nAlthough I haven't maintained it for some time. I expect that the latest release binary at least works.\n\n[7 upvotes] Hopefully constructive suggestion, oftentimes when a libc function fails it's beneficial to end users to include the errno in the message to determine why it failed. For example on line 99 I see this:\n\n      if (ptrace(PTRACE_ATTACH, trace_pid, 0, 0)) \n        FATAL(\"Cannot attach to process (privileged / already debugged?)\");\n\n  \nInstead of \"(privileged / already debugged?)\" if you just include the value of errno the end user has a chance to determine why it failed.\n\n[-37 upvotes] It's not a file though, the kernel generates it on demand\n\nEdit: Go ahead and downvote me, I am correct",
  "transcript_chars": 832,
  "ingested_at": "2026-06-01T13:30:32.057922+00:00",
  "source": "reddit",
  "yt_meta": {
    "score": 209,
    "upvote_ratio": 0.94,
    "num_comments": 16,
    "author": "mttd",
    "is_self": false
  }
}