Java Bullshifier: Generate Massive Random Code Bases

For more articles like this, visit Takipi.

It's the command line tool you’ve been waiting for. Or not. After all, it’s pretty esoteric. Either way, it’s pretty useful to some and an amusing utility to others. Bullshifier is an internal OverOps tool developed by David Levanon and Hodaya Gamliel. It’s used in order to test some of our monitoring capabilities over ridiculously large code bases, with transactions that go thousands of calls deep, over thousands of classes, and end up with exceptions.

Let’s dig into how to use it and why we built it. And if you want to dive in, visit the site to download a sample result or view it on GitHub.

Some motivation

OverOps shows developers where, when, and why code breaks in production. Whenever there’s a logged error, warning, or exception, it shows you the complete source code and variable state across the entire call stack at the moment of error.

It’s built for production, and requires a low overhead that never goes over 3% in terms of CPU and memory. As such, as part of our process, we needed to test it with some extreme edge cases – and this is where Bullshifier comes in:

• Generates massive projects with tons of code and logging.
• Runs across methods with deep call stacks.
• Throws exceptions caused by random variable state.

Basic Usage

Requirements

• Groovy installed.
• Java installed.

Installation

• Download, unzip, and you’re ready to go.

Run settings

• ./gradlew run (Default parameters, generates one jar with 10 classes).
• cd output && gradle fatJar to build the generated project.
• java -cp output/build/libs/tester.jar helpers.Main to run it.

Or, you can simply run ./scripts/small.sh, or ./scripts/big.sh, with preconfigured run settings.

Flags

• -Poutput-directory (Relative path to output directory)
• -Poutput-classes (number of classes to generate)
• -Psubprojects (number of jars to generate)

Keep in mind that generating over 500 classes will take quite some time. Our biggest run had 20,000 classes, but its better to keep this under 5,000.

Running Sub-Projects

• /gradle build (get a WAR file)
• Go to bin
• A shell script is created per project, root will run them all

Advanced Config

There are some additional options that give you fine grained control over the generated code, but might mess it up, use at your own risk:

• Low level config: src/main/groovy/generator/Config.groovy
• Higher level config is available in the output folder. There are more options to add logging, and fine-tune the behavior of the application but it’s experimental at the moment.

If you’d like to learn more, feel free to reach out or ask us in the comments section for a deeper walkthrough. Default settings are no logs, and an exception on every 10th frame in the call stack.

Sample Output

Fun fact, at first, all those randomly generated class and variable names caused a lot of hits with reserved words. Even though they’re completely random, because of the huge amounts of generated code. So now it’s random minus reserved words

Each generated method contains 4 sections:

• Variable definition, with random types, random names, and values.
• A section that throws exceptions, or prints to the log, according to the config settings for the rate of events. This also includes a “suicide” function that stops the execution of the program.
• Calls the next method.
• Code that never runs.

Here’s a random snippet from the first part:

int methodId = 2;
Object[] root = new Object[9];
List<Object> valCjrukeawxor = new LinkedList<Object>();
Set<Object> valRvshucjormy = new HashSet<Object>();
boolean valSboiogeldpb = true;

valRvshucjormy.add(valSboiogeldpb);
boolean valPjvoucyfprv = true;

For more articles like this, visit Takipi.