A method and apparatus for upgrading libraries in a source code program by evaluating libraries in the source code program for predetermined selection criteria specifying library performance limitations to identify at least a first library which does not meet the plurality of predetermined selection criteria and then identifying a first alternative library that is suitable for substitution for the first library so that the source code program may be automatically modified to replace the first library with the first alternative library, thereby generating a modified source code program having an upgraded library functionality.

A computer-implemented method according to one embodiment includes receiving data associated with a driver performing actions. At least some of the actions trigger events emitted by an event emitter. Information, from the received data, about the performed actions is logged in an action log. An event observer is instructed to log the events emitted by the event emitter that the event observer observes. The observed events are logged in an event log. The information of the action log and information of the event log is compared based on a rule, and a validity of the event emitter is determined based on results of the comparing. A computer program product according to another embodiment includes a computer readable storage medium having program instructions embodied therewith. The program instructions are readable and/or executable by a processor to cause the processor to perform the foregoing method.

At least a static analysis and a dynamic analysis to perform for a first software application are determined based, at least in part, on a profile of the first software application. The first software application is analyzed with the static analysis to generate static analysis results. The first software application is analyzed with dynamic analysis to generate dynamic analysis results. An assessment report is generated based on the static analysis results and the dynamic analysis results, wherein the assessment report indicates a security score of the first software application that is based, at least in part, on the static analysis results and the dynamic analysis results.

Techniques are disclosed for generating an execution plan for performing functional tests in a cloud-computing environment. Infrastructure resources and capabilities (e.g., system requirements) may be defined within an infrastructure object (e.g., a resource of a declarative infrastructure provisioner) that stores a code segment that implements the resource or capability. Metadata may be maintained that indicates what particular capabilities are applicable to each infrastructure resource. Using the metadata, the system can generate an execution plan by combining code segments for each resource with code segments defining each capability in accordance with the metadata. The execution plan may include programmatic instructions that, when executed, generate a set of test results. The system can execute instructions that cause the set of test results to be presented at a user device.

A method for creating an allocation map, wherein the allocation map is created based on an FPGA source code, wherein the source code uses at least a first signal at a first location, wherein at least a first register is mapped to the first signal, wherein in the allocation map, the first signal and the first register are listed as mapped to one another, wherein a second signal is used at a second location in the FPGA source code, wherein it is automatically detected that the value of the second signal can be determined from the value of the first signal according to a first calculation rule, wherein in the allocation map, the second signal, the first register and the first calculation rule are listed as mapped to one another.

A mechanism is provided to monitor control flow failure of processors having a simple processing pipeline (e.g., RISC5) or accelerators (e.g., digital signal processors). Embodiments have a monitoring entity attached to the processor that does not interfere with the normal functionality of the accelerator. By virtue of being closely associated with the processor, the failure detection period can be smaller than that of a typical host watchdog and can be defined as per the needs of the application. In some embodiments, the failure detection period is defined by the number of clock cycles needed for the largest basic block in the executed code.

The invention relates to a system (300) and method for performing end-to-end simulation and testing of an IoT application (102). An IoT data simulator (310) is configured to simulate an IoT environment using data received from different components in the IoT environment, which include IoT messages/data from IoT devices (106), master data from different databases (108) and data from third-party web services (110). Device templates are created that are used as blueprint for defining a plurality of device instances which include simulated device instances and live device instances. An IoT application validator (326) is configured for testing and validating the IoT application (102) by transmitting a plurality of IoT messages to the IoT application (102) and validating the behavior of the IoT application (102) to the plurality of IoT messages for all layers including, but not limited to, a UI layer (112), a business logic (114) and a data layer (116), using one or more device instances.

A method for blocking external debugger application from analysing code of software program installed on computing device. The method including initializing software program including an application program and an internal debugger application. The software program, upon initialization thereof, instructs internal debugger application to load application program in internal debugger application. The internal debugger application is configured to utilize kernel resources of an operating system of the computing device. The method includes executing internal debugger application to set one or more break-points in code of application program to define execution path for code of application program, executing application program as per defined execution path for code thereof, stopping execution of code of application program upon reaching any of one or more break-points therein, and handing control to internal debugger application to provide an address for next instruction to be executed in defined execution path for code of application program.

An improved SDK includes a set of APIs and a crash handler registered with the operating system. Each API is an interface accessible by a computer software application. Up on entrance, each API determines the current thread identifier, and inserts it into a list if it is not already in the list. Each thread identifier corresponds to an API call counter, which is incremented by one at the entrance and decremented by one at the exit point of the API. The SDK also records the identifier of the thread it creates for callback functions. When a crash occurs, the crash handler is executed. It determines that the crash is related to a callback interface if the crash thread identifier matches the callback thread identifier. The crash is determined to be caused by the SDK if the API call counter corresponding to the crash thread identifier is greater than zero.

Examples herein include an incident workflow graphical user interface (“GUI”) that visualizes workflows for solving application performance issues. An analytics server can process alerts based on application performance notifications. An administrative console GUI can display an issue pane that organizes alerts and remedial actions of an individual underlying issue. Alerts can be organized in a first region with actions organized in a second region. The alerts can visually update as they become resolved. Issue assemblies can be stored for future retrieval, allowing a recommendation engine to help populate future issue panes based on similar issues.