Word is getting around recently about how awesome rbtrace is. Which is great, because it’s a fantastically useful gem for debugging performance problems. In fact I mentioned it in my performance talk at GoRuCo last year.
In and of itself, it can get you some really good information about what’s going on inside of a live ruby process. Its real power, though, comes apparent when combined with the power of other tools. This is because rbtrace’s eval functionality allows you to run anything inside of your running ruby process. Now this should all come with a serious Uncle Ben Warning (i.e. “With Great Power Comes Great Responsibility”) - you need to make sure you have proper security around your ruby processes. Enabling rbtrace is giving access to run anything that the ruby process can run.
Assuming you understand the risks, rbtrace can enable you to get amazing insight, like being able to toggle and dump stackprof information remotely with stackprof-remote. Here we start thinking of rbtrace not as a performance tool itself, but a messaging protocol and system for setting and retrieving live objects in our ruby processes. This works because (as of 0.4.3) the main functionality of rbtrace was extracted into a useable ruby API which is accessible outside of the CLI. For example:
You can see the full magic here.
In this way you can trigger events in your process or just read or set values, but dynamically and without having to provide an explicit API. Again, this power could easily be abused not only by hackers but by developers who want to build the worlds most fragile RPC system (don’t do it!).
What if we used this power for good?