2,562 research outputs found

    Distributed debugging and tumult

    Get PDF
    A description is given of Tumult (Twente university multicomputer) and its operating system, along with considerations about parallel debugging, examples of parallel debuggers, and the proposed debugger for Tumult. Problems related to debugging distributed systems and solutions found in other distributed debuggers are discussed. The following are the main features of the debugger: it is event based, using a monitor for intercepting these events; record and reply are the main debugging techniques; preprocessing of events is done by programmable filters; the user interface is graphical, using grouping as the main abstraction mechanism. Parts of the debugger, as well as initial versions of the global and local event managers, have been implemented. A slow serial link between the front-end processor and the Tumult system has been replaced by a fast SCSI communication link. The user interface is partly textual, partly graphical. The languages used to implement the debugger are Modula-2 and C. The X Window System and OSF/Motif are used for the graphical user interfac

    On debugging in a parallel system

    Get PDF
    In this paper a description is given of a partly implemented parallel debugger for the Twente University Multicomputer (TUMULT). The system's basic method for exchange of data is message passing. Experience has learned that most programming errors in application software are made in calls to the kernel and the interprocess communication. The debugger is intended to be used for locating bugs at this level in the application software. It is assumed that basic blocks of the debuggee can be debugged using a traditional sequential sourcelevel debugger

    An Integrated Development Environment for Declarative Multi-Paradigm Programming

    Full text link
    In this paper we present CIDER (Curry Integrated Development EnviRonment), an analysis and programming environment for the declarative multi-paradigm language Curry. CIDER is a graphical environment to support the development of Curry programs by providing integrated tools for the analysis and visualization of programs. CIDER is completely implemented in Curry using libraries for GUI programming (based on Tcl/Tk) and meta-programming. An important aspect of our environment is the possible adaptation of the development environment to other declarative source languages (e.g., Prolog or Haskell) and the extensibility w.r.t. new analysis methods. To support the latter feature, the lazy evaluation strategy of the underlying implementation language Curry becomes quite useful.Comment: In A. Kusalik (ed), proceedings of the Eleventh International Workshop on Logic Programming Environments (WLPE'01), December 1, 2001, Paphos, Cyprus. cs.PL/011104

    Parallel software tools at Langley Research Center

    Get PDF
    This document gives a brief overview of parallel software tools available on the Intel iPSC/860 parallel computer at Langley Research Center. It is intended to provide a source of information that is somewhat more concise than vendor-supplied material on the purpose and use of various tools. Each of the chapters on tools is organized in a similar manner covering an overview of the functionality, access information, how to effectively use the tool, observations about the tool and how it compares to similar software, known problems or shortfalls with the software, and reference documentation. It is primarily intended for users of the iPSC/860 at Langley Research Center and is appropriate for both the experienced and novice user

    Dynamic and Transparent Analysis of Commodity Production Systems

    Full text link
    We propose a framework that provides a programming interface to perform complex dynamic system-level analyses of deployed production systems. By leveraging hardware support for virtualization available nowadays on all commodity machines, our framework is completely transparent to the system under analysis and it guarantees isolation of the analysis tools running on its top. Thus, the internals of the kernel of the running system needs not to be modified and the whole platform runs unaware of the framework. Moreover, errors in the analysis tools do not affect the running system and the framework. This is accomplished by installing a minimalistic virtual machine monitor and migrating the system, as it runs, into a virtual machine. In order to demonstrate the potentials of our framework we developed an interactive kernel debugger, nicknamed HyperDbg. HyperDbg can be used to debug any critical kernel component, and even to single step the execution of exception and interrupt handlers.Comment: 10 pages, To appear in the 25th IEEE/ACM International Conference on Automated Software Engineering, Antwerp, Belgium, 20-24 September 201
    • …
    corecore