{'fraction_non_alphanumeric': 0.035071090047393366, 'fraction_numerical': 0.009478672985781991, 'mean_word_length': 5.041984732824427, 'pattern_counts': {'":': 0, '<': 0, '<?xml version=': 0, '>': 0, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
Program Synthesis for Program Analysis : Models and Drivers ( Extended Abstract )

In recent years, many program analysis tools have been proposed, with several promising results, e.g., using abstract interpretation [4] or symbolic execution [9] to find bugs in software systems [2, 3]. Despite a diversity of techniques on which those tools rely, almost all tools share a common problem: they focus on analyzing the application code. But applications are no longer written in isolation— they are built on top of frameworks consisting of infrastructure, libraries, and the operating system, at the very least. Moreover, framework code might not be available; it might be available but too large and complex to analyze in practice; or it might be written in a different language from the ones handled by tools. As a result, program analysis cannot be performed properly when it reaches the boundary between an app and the framework. Suppose we want to analyze a Java Swing app. Figure 1 shows a subset of call-return sequences and event creations recorded under one particular run of the target app, which registers itself as an event listener for two buttons (lines 5–6). After GUI elements are built, it is ready to react to user interactions; user’s button clicks will trigger ActionEvents (lines 8 and 12), which are in turn followed by the corresponding event handler, actionPerformed. From the client point of view, control-flows from ActionEvent creation to client’s actionPerformed method (lines 8–9 and 12–13) are implicit. That is, part of client code is called back from the framework, thus program analysis tools cannot properly analyze such program without a model of the framework. To resolve this issue, most analysis tool developers resort to manually writing models of frameworks for analysis purpose. For example, Java Pathfinder [14] includes models of Java GUI libraries [12], and the KLEE project [3] uses a specially modified, embedded systems version of libc. Such models of framework, however, are tedious and error-prone to write, and must often be modified if the analysis or framework changes. With or without such models of a framework, it is challengeable for program analysis tools to achieve (re)usability. Program analysis techniques, such as abstract interpretations [4] and symbolic execution [9], define how to analyze programs, but what properties to analyze are up to what problems those tools aim for. In most cases, program analysis tools are either specific to particular problems, e.g., buffer overrun detection [19], or so general that driving them to analyze desired properties is not trivial. In this article, we propose to apply program synthesis [10, 11] to automatically generate two artifacts—models of framework and client-oriented drivers—to enable program analysis tools to analyze framework apps more easily and efficiently. The first one will enable program analysis to proceed even when it reaches the boundary between an app and the framework. The second one will supply end-users with easy-to-understand code that drives program analysis tools to analyze properties of interest. 1 ButtonDemo.createAndShowGUI()