This article originally appeared in the Fall 2015 issue of Inquiry, the biannual publication produced for University of Chicago Physical Sciences Division alumni and friends.
Shan Lu finds your software bugs and kills them
Say you find a bug in your kitchen. You have three options: leave it be and try to forget about it, put it outside where it won’t bother you, or kill it. The same options exist for computer program bugs: ignore the problem, build a work-around, or fix the source code. But what if you have a million bugs? You call a professional, like associate professor Shan Lu. Specializing in computer system robustness and reliability, she eradicates software bugs through program analysis and software engineering.
When she started graduate school at the University of Illinois at Urbana-Champaign, Lu had much less programming experience than many of her peers. “I had a lot of bugs in my programs,” says Lu, who joined the University in August 2014. But rather than a liability, her inexperience opened a door. She didn’t have an adviser at the time, and a professor who worked on software reliability asked if she’d like to join his group.
Pattern recognition
Understanding, detecting, mitigating, and fixing defects in today’s software is much more involved than it once was. “Thirty years ago, programs usually had a thousand lines of code,” says Lu. “It was still possible to read through every line and manually validate and correct.” Most programs are now too large and complicated to comb through the source code, and they often combine different components. “Software is not built by just one person.” So Lu builds programs to find bugs based on patterns and then, if possible, fix them automatically.
A typical project for Lu involves choosing a large, mature, and open-source program and studying its defect database, which contains detailed user reports. She studies discussions between users and developers, patches, and reviews of patches and tries to identify a pattern in the types of mistakes developers make. She uses complex software to provide a large enough sample size to draw statistically significant conclusions.
Once Lu generalizes a common problem and identifies a pattern—the most challenging part of the process—she can write a program to search code, identify that pattern, and, depending on the type of bug, automatically fix it. “When you fix a bug,” she adds, “you want to make sure you don’t introduce new ones.”
Lu’s group ran one of these programs on 15 widely used Java and C/C++ applications. It found 150 previously undetected performance bugs. Lu submitted the report along with patches to fix the bugs, and 116 were immediately accepted by developers. The software was presented at the International Conference on Software Engineering in May, winning the team a Distinguished Paper Award.
Depending on a digital world
The type of software dependability research Lu conducts affects much of our technologically developed lives, in both trivial and critical ways. Consider your smartphone or smartwatch. If its software is inefficient, your applications can become unresponsive and drain the battery. Now consider the equipment that delivers radiation therapy to cancer patients. A programming error can cause lethal malfunctions—and has, Lu recalls.
Between 1985 and 1987, the Therac-25 radiation therapy machine ran software that contained a subtle bug called a race condition, which causes a device to attempt two or more operations at the same time, resulting in the wrong sequence of events. The machine delivered an overdose of radiation; five patients died and many others were injured. Bugs also have caused space rockets to explode (Mariner I, 1962; Ariane 5, 1996) and destroyed pipelines (trans-Siberian gas pipeline, 1982, rumored to have been caused by a CIA-planted bug, leading to the largest non-nuclear explosion in history).
Ivory to computer towers
Because of our dependence on computer systems, academic computer science and industry share a close relationship. Often breakthroughs are directly and immediately applied by corporations. When she was a student, Lu and her adviser developed a tool, filed a patent, and licensed it to Intel. Her adviser created a start-up based on another technique they developed. While she doesn’t plan to begin her own company any time soon, she does expect to collaborate with industry.
This melding of academia and entrepreneurship is reflected in recent changes to the computer science department. In 2011 Andrew Chien, previously Intel’s vice president of research, joined the department as the William Eckhardt Distinguished Service Professor. While the department maintains its traditional focus on theory, says associate chair Anne Rogers, his appointment marked the beginning of an expansion of faculty members who work under the broad umbrella of systems.
“The field is going to change, and very quickly,” says department chair Todd Dupont. Some recent hires come from industry, some from academia, and some have worked in both (see "Science Nonfiction"). The boundaries between the two areas are increasingly fluid, says Rogers, with advances in each driving the other.
This relatively new attention to systems research is part of the reason Lu came to UChicago from an established program at the University of Wisconsin–Madison. “It almost feels like a start-up,” she says. “Everyone is energetic, with a ‘we’re doing this together’ feeling.” As a relatively junior faculty member, Lu has an opportunity to effect real change.
Cascade effect:
The path to gender diversity in computer science
Andrew Chien, a computer science professor who’s helped recruit more systems-focused faculty, has been intent on increasing the department’s diversity, making an effort to identify top-flight women in the field and inviting them to visit campus. Sometimes that visit has led to an appointment, as was the case for Shan Lu. In the past year, the department has hired two more women computer scientists—assistant professor Yanjing Li and Diana Franklin, director of computer science education at the Center for Elementary Mathematics and Science Education. Such additions may encourage more women to pursue a field in which they are still underrepresented.
Lu feels surrounded and supported by women colleagues at UChicago, so it takes her a minute to remember ever feeling less at ease. But her years as an undergraduate at the University of Science and Technology of China were difficult. She began her course work with little programming experience—inexperience shared by her three female classmates. The 20 or so male computer science majors seemed to already have programming knowledge. “How can they already know so much,” Lu wondered, “and how can I possibly catch up?”
The women banded together, helping each other narrow the gap, while the men moved forward from their head start. She wonders if women are deterred by the disparity in early exposure to computer science.
Now as a professor, she makes a point of assuring her less experienced students—who tend to be women—that although they need to practice programming, they can still do well in her classes. Speed is important, but “there are many other skills that will determine if you’re successful,” Lu says. “Whether you’re organized, determined, or creative. You need to be a good thinker.”
As a graduate student 10 years ago, Lu helped her adviser mentor two undergrads through the Distributed Research Experiences for Undergraduates program, sponsored by a woman-focused committee of the Computing Research Association. This summer she became a mentor herself, hosting two women computer science students from different cities for 10 weeks.
Lu’s colleague, assistant professor Hank Hoffmann, also hosted women summer researchers through a different program. “We are hoping that a collective effort like this,” says Lu, “will contribute to increasing the percentage of women in computer science.”
Ento/etymology:
The first computer bug
In 1947 Harvard’s computer lab was developing the Mark II for the US Navy when it shorted out. The culprit? A moth trapped in the machine. The team pulled it out and taped it to a logbook, noting, “First actual case of bug being found.” The phrase has been attributed to one of Mark II’s programmers, Grace Hopper, a computer science pioneer who retired from the Navy as a rear admiral.
[[{"type":"media","view_mode":"media_original","fid":"3129","attributes":{"alt":"","class":"media-image","height":"329","typeof":"foaf:Image","width":"500"}}]] In 1947 Harvard’s computer lab, run by Grace Hopper, pulled a moth from a malfunctioning Mark II. Though widely cited as the origin of “computer bug,” this tale is disputed. (Photo courtesy US Naval Historical Center)
This story has been widely cited as the origin of the term “computer bug,” but Peggy Kidwell, who curated the exhibit at the Smithsonian where the logbook now resides, disputes this claim.
By the time the Mark II was in development, usage of the word “bug” to mean flaw was common in technical circles, since at least the late 19th century, when Thomas Edison used it to describe problems with his inventions. Kidwell also notes that the logbook is not in Hopper’s handwriting.
Still, Hopper often told the story at public appearances, included the term in programming books she authored, and illustrated Mark II flaws as insects. It’s fair to say, if she and her team didn’t coin the term, they certainly popularized it in the context of computers.