Abstract: A system and method for modeling code segments that do not have a location is disclosed. Source code may be indexed and modeled in a data graph with nodes representing code elements and edges representing relationships between nodes. However, some code elements may be hidden or implicit and therefore may lack location information. In these cases, code figments are created and represented as nodes in the graph. Figment nodes may be specially designated so that the figment nodes may be easily distinguished from real source code nodes. The graph is then updated to include location information for the code figments in the nodes that interact with the hidden or implicit code. The data graph may then be provided to a user or as a service to be used by coding tools.

Abstract: A fuzz testing system is described herein that represents event sources, channels, processors, and consumers as first-class entities in an application. Abstracting event-related entities allows fuzzing through injecting, dropping, reordering, and delaying events from within the application. This translates into the ability to localize the areas under test and perform fuzzing in a systematic manner. In some embodiments, the fuzz testing system tests concurrent asynchronous and event-based code, and can generate event streams based on a given statistical distribution. Representing events, event sources, processors, and sinks as first-class objects provides easy access to the event handlers and facilitates implementing fuzzing by introducing event processors between the source and the sink. Thus, the fuzz testing system improves the testability of applications and APIs with asynchronous behavior and provides a uniform framework for introducing fuzz testing into such applications.

Abstract: Embodiments provided a formalized set of intermediate analysis contexts that are relevant for analysis checks of target code. Such intermediate analysis context may include, but are not limited to, the development phase of targeted code, the type or state of the targeted code, a source manipulating the targeted code, a purpose for the targeted code, or other development or runtime requirements. Accordingly, embodiments dynamically identify a current analysis context under which targeted code is being developed and can then execute rules based on knowledge of what contexts the rule(s) may apply. More specifically, analysis rules can describe (e.g., via metadata) those context conditions under which a rule can run. Based on such description and the current context, those rules that have been configured to apply to such context conditions can be executed.

Abstract: A system, method, and computer-readable medium for static analysis of large-scale computer programs that uses a compiler to shard the computer programs by source files. Original compilation information is received for one or more groups of source files that reference modules in module containers. The compiler is run to determine a set of modules in the module containers and other source files that are referenced by a source file of the groups of source files. The compilation information is modified on the basis of the source file, the set of modules and the referenced source files. Static analysis is performed on the source file using the modified compilation information. Static analysis is efficiently performed over large-scale computer programs.

Abstract: Client-side performance is optimized through server-side pushing of content. Portions of content are requested and retrieved as required by a client-side application. Moreover, content likely to be needed in the near future is pre-fetched and pushed to the client. This is beneficial from an overhead standpoint since all content need not be provided to the client at once. Rather, content provisioning is throttled based on need, and wait time is mitigated by pre-fetching.

Abstract: An exemplary method includes providing an application that includes client-side code and server-side code, instrumenting the client-side code and the server-side code to generate timestamps, distributing the instrumented client-side code and the instrumented server-side code and monitoring timestamps generated during execution of the application. In such a method, where timestamps generated by the client-side code and timestamps generated by the server-side code occur along a common timeline, a developer can monitor performance of the distributed application. Other exemplary methods, systems, etc., are also disclosed.

Abstract: A processing system for distributed multi-tier applications is provided. The system includes a server component that executes a replica of a client-side application, where a client component executes the client-side application. The client component captures events from the client-side application and transmits the events to the replica to validate the computational integrity security of the application.

Abstract: An exemplary method includes providing an application that includes client-side code and server-side code, instrumenting the client-side code and the server-side code to generate timestamps, distributing the instrumented client-side code and the instrumented server-side code and monitoring timestamps generated during execution of the application. In such a method, where timestamps generated by the client-side code and timestamps generated by the server-side code occur along a common timeline, a developer can monitor performance of the distributed application. Other exemplary methods, systems, etc., are also disclosed.

Abstract: Secure distributed applications are produced by default upon construction. Mechanisms are provided to address distributed application vulnerabilities (e.g., cross-site scripting, cross-site request forgery, replay attacks. . . ) automatically. These mechanisms are provided in conjunction with a tier split component that breaks up an application for execution across multiple contexts or tiers. As a result, any application that is tier split is protected from security vulnerabilities by default without any intervention on the part of a developer.

Abstract: A first computing device receives (over a network) from at least a second computing device a container that includes information relating to types of software code that are potentially invoked by a program executing on the first computing device. A determination is made according to an on-demand basis, during execution of the program, whether a particular type of software code is to be loaded from the at least second computing device to the first computing device.

Abstract: A system and method for modeling code segments that do not have a location is disclosed. Source code may be indexed and modeled in a data graph with nodes representing code elements and edges representing relationships between nodes. However, some code elements may be hidden or implicit and therefore may lack location information. In these cases, code figments are created and represented as nodes in the graph. Figment nodes may be specially designated so that the figment nodes may be easily distinguished from real source code nodes. The graph is then updated to include location information for the code figments in the nodes that interact with the hidden or implicit code. The data graph may then be provided to a user or as a service to be used by coding tools.

Abstract: A build system and method, including receiving attribute rules and new rules, wherein the attribute rules correspond to one or more predefined default actions of the build system, wherein the new rules specify new actions that are to be added to the build system. A graph is generated to include files specified as attributes in the attributes rules and the one or more predefined default actions that correspond to the attributes rules. A request to enable at least one of the new rules is received. Action listener rules are received, wherein the action listener rules indicate default actions and corresponding new rules of the one or more new rules. The graph is checked for default actions that are indicated in the action listener rules. Additional actions are added to the graph for new rules based on the default actions indicated in the action listener rules.

Abstract: Various technologies and techniques are disclosed for providing a code analysis debugger. A code analysis process is performed to identify possible program defects that are present in particular source code. The results of the code analysis are stored in a results file in a structured format. The structured format contains sections that describe details about the one or more portions of source code that have been identified as possibly having the program defects. The analysis results are retrieved for display. A debugger-like feature allows a user to review a representation of the program defects identified during the code analysis. The debugger-like feature has a graphical user interface that can display at least some of the possible program defects in a call stack for further review.

Abstract: Embodiments provided a formalized set of intermediate analysis contexts that are relevant for analysis checks of target code. Such intermediate analysis context may include, but are not limited to, the development phase of targeted code, the type or state of the targeted code, a source manipulating the targeted code, a purpose for the targeted code, or other development or runtime requirements. Accordingly, embodiments dynamically identify a current analysis context under which targeted code is being developed and can then execute rules based on knowledge of what contexts the rule(s) may apply. More specifically, analysis rules can describe (e.g., via metadata) those context conditions under which a rule can run. Based on such description and the current context, those rules that have been configured to apply to such context conditions can be executed.

Abstract: An arrangement by which pointers may be represented in a restricted software execution environment that provides access to only reference types but not pointers is realized by modeling both pointers and value type boxing using a set of boxes (i.e., containers) which describe how to retrieve the value associated with the pointer, and emitting code for accessing the set of boxes. A decompiling and recompiling process is utilized in which code arranged to run in an execution environment that supports pointers is scanned to reveal pointer and boxing usage. In one illustrative example, code is responsively emitted to create one or more specific boxes. At runtime in the restricted execution environment, an instance of a box class is created to thus emulate a pointer to the value.

Abstract: Embodiments provided a formalized set of intermediate analysis contexts that are relevant for analysis checks of target code. Such intermediate analysis context may include, but are not limited to, the development phase of targeted code, the type or state of the targeted code, a source manipulating the targeted code, a purpose for the targeted code, or other development or runtime requirements. Accordingly, embodiments dynamically identify a current analysis context under which targeted code is being developed and can then execute rules based on knowledge of what contexts the rule(s) may apply. More specifically, analysis rules can describe (e.g., via metadata) those context conditions under which a rule can run. Based on such description and the current context, those rules that have been configured to apply to such context conditions can be executed.

Abstract: Mapping is performed between operations of an abstract asynchronous programming model and a concrete asynchronous programming model. In other words, differences between asynchronous programming models are bridged to enable interaction.

Abstract: A system and method for controlling the execution of notifications in a computer system with multiple notification contexts. A RunOn operator enables context hopping between notification contexts. Push-based stream operators optionally perform error checking to determine if notifications combined into a push-based stream share a common notification context. Context boxes group together notification creators and associate their notifications with a common scheduler and notification context. Operators employ a composition architecture, in which they receive one or more push-based streams and produce a transformed push-based stream that may be further operated upon. Components may be used in combinations to implement various policies, including a strict policy in which all notifications are scheduled in a common execution context, a permissive policy that provides programming flexibility, and a hybrid policy that combines flexibility with error checking.

Abstract: Mapping is performed between operations of an abstract asynchronous programming model and a concrete asynchronous programming model. In other words, differences between asynchronous programming models are bridged to enable interaction.

Abstract: Real user input targeting an application under test is blocked to prevent interference with a test. A shield window can be placed in front of an application-under-test window to intercept input destined for the application. Users can be notified of interception or a failed attempt to access the application. Furthermore, the shield window can be employed to provide feedback about the test including pointer movement and area focus.