Design and Implementation of a Tracer Driver: Easy and Efficient Dynamic Analyses of Constraint Logic Programs

Under c onsider ation for public ation in The ory and Pr actic e of L o gic Pr o gr amming 1 Design and Implementation of a T r ac er Driver: Easy and Ecient Dynamic A nalyses of Constr aint L o gic Pr o gr ams ∗ Ludo vic Langevine † Mission Critic al IT, Boulevar d de F r anc e, 9, Bât A, 1420 - Br aine-l'A l leud, Belgium ( e-mail: llg@missio ncriticalit.com ) Mireille Ducassé IRISA/INSA of R ennes, Campus de Be aulieu, 35 042 R ennes Ce dex, F r anc e ( e-mail: Mireille.D ucasse@irisa.fr ) submitte d 5 July 2006; r evise d 5 June 2007, 20 De c emb er 2007; ac c epte d 23 April 2008 Abstract T racers pro vide users with u sef u l information ab out p ro gram execu tions. In this article, w e prop ose a tracer d riv er. F rom a single tracer, i t pro vides a p o w er ful fron t-end enabling m ult iple dynamic analysis to ols to b e easily implemen ted, while limiting the o v erhead of the trace generation. The relev an t execution ev en ts are sp ecied b y exible ev en t patterns and a large v ariet y of trace data can b e giv en either systematically or on demand. The prop osed tracer d r i v er has b een designed i n the con text of constrain t logic programming; exp erimen ts h a v e b een made within GNU -Prolog. Execution views pro vided b y exist ing to ols ha v e b een easily em ulated with a negligible o v erhead. Exp erimen t al measures sho w that the exibil it y and p o w er of the describ ed a rc hitecture lead to go o d p erformance. The tracer driv er o v erhead is in v ersely prop ortional to the a v erage time b et w een t w o traced ev e n ts. Whereas the principles of the tracer driv er are indep enden t of the traced programming language, it is b est suited for high-lev el languages, su c h as constrain t logic programming, wh ere eac h traced execution ev en t encompasses n umerous lo w-lev el execu- tion steps. F urt hermo re, constrain t logic programming i s esp ecially hard to debug. The curren t en vironmen ts do not pro vide all the useful dynamic analysis to ols. Th ey can sig- nican tly b enet from our tracer d r i v er whi c h en ables dynamic analyses to b e in tegrated at a v ery lo w cost. T o app ear in T heory and Practice of Logic Programming (TPLP), C am bridge Univ ersit y Press. KEYW ORDS : Soft w are Engineering, Debugging, Execution T race Analysis, Execution Monitoring, Execution T racin g, Execution Visualizat ion, Programming En vironmen t, Con- strain t Logic Progra mming ∗ This w ork has b een partly supp orted b y the F renc h RNTL O ADymPP aC p ro ject and th e ER CIM f e l lo wship programme. † Most of the w ork has b een done while Ludo vic Langevine w as at INRIA Ro cqu encourt, F rance 2 L. L angevine an d M. Duc assé 1 In tro duction Dynamic program analysis is the pro c ess of analyzing program executions. It is generally ac k no wledged that dynamic analysis i s complemen tary to static analysis; see for example the discussion of Ball (Bal l 1999). Dynamic analysis to ols include, in particular, tracers, de bu g gers, monitors and visualizers. Analysis 1 (e.g. a tracer) Analysis 2 (e.g. a monitor) Analysis n (e.g. a visualizer) Development of ad hoc instrumentation parts ... Fig. 1. The usual case: all dynamic analysis to ols imple men t a dedicated instru- men tation part In order to b e able to analyze executions, some data m ust b e gathere d and some sort of instrumen tation mec hanisms m ust b e implemen ted. The state-of-the- practice, illustrated b y Fig. 1, is to re-implemen t the i ns trumen tation for eac h new dynamic analysis to ol. The adv an tage s are, rstly , that the instrumen tation is nat- urally and tigh tly connected to the analysis, and secondly , that it is sp ecialized for the targeted analysis and pro duces relev an t information. The dra wbac k, ho w ev er, is that this implemen tation usually requires m uc h tedious w ork whic h has to b e rep eated b y eac h to ol's wr i t e r for eac h en vironmen t. This acts as a brak e up on dev elopmen t of dynamic analysis to ols. 1.1 A T r ac er Driver to Eciently Shar e Instrumentations In this article w e suggest that standard tracers can b e used to giv e information ab out executions to sev eral dy nami c anal y sis to ols. I n de ed, H ar rol d et al. ha v e sho wn that a trace consisting of the sequence of program statemen ts tra v ersed as the program executes subsumes a n um b er of in teresting other represen tations suc h as the s e t of conditional branc hes or the set of paths (Harrold et al. 1998). b asic tracer Analysis 1 (e.g. a standard tracer) Analysis 2 (e.g. a monitor) Analysis n (e.g. a visualizer) trace ... Fig. 2. The generate-and-dump approac h: the instrumen tati on part is shared but the amoun t of data is h uge Ho w ev er, the separation of the extraction part from the analysis part requires T r ac er Driver and Dynamic A nalyses of CLP(FD) 3 basic tracer with a tracer driver Analysis 1 (e.g. a standard tracer) Analysis 2 (e.g. a monitor) Analysis n (e.g. a visualizer) requests ... relevant trace Fig. 3. Our sup ervised generation approac h: with a tracer driv er only the relev an t part of the execution information is generated care. Indeed, as illustrated b y Fig. 2, if execution information is systematically generated and dump ed to the anal y sis to ols, the amoun t of information that o ws from the tr ac er to the analysis mo dules can b e h uge, namely sev eral gigab ytes for a few seconds of execution. Whether the information o ws through a le, a pip e, or ev en main me mory , writing suc h an amoun t of information tak es so m uc h tim e that the to ols are not usable in terac t i v ely . This is esp ecial ly critical for debugging, ev en when it is automated, b ec aus e users need to in teract in real-time with the to ols. Reiss and Renieris prop o s e to enco de and compact the t rac e information (Reiss and Renieris 2001). Thei r approac h is us e d in a con text where m ultiple tracing sources send information to the same analysis mo dule. I n this artic le, w e prop ose another approac h, more ac curate when a single source sends information to (p ossi- bly) sev eral analysis mo dules. As illustrated b y Fig. 3, w e ha v e designed what w e call a tracer driv er, whose primary function is to lter the data on the y accord- ing to requests sen t b y the analysis mo dules. Only the necessary trace information is actually generated. This often drastically reduces the amoun t of trace data, and signican tly impro v es the p erformance. Therefore, the i ns trumen tation mo dule is shared among sev eral analysis to ols and there is v ery little slo wdo wn c ompared to the solution where ea c h analysis has its dedicated instrumen tation. F rom a single tracer, the tracer driv er pro vides a p o w erful fron t-end for m ultiple dynamic analysis to ols while lim iting th e o v erhead of the trace generation. The consequence is that sp ecifying and impl emen ting dynamic analysis to ols is m uc h easier, without n e gativ e impact on the end-us e r. 1.2 Inter actions b etwe en a T r ac er and A n alyzers In the follo wing, w e call a mo dule that is connected to a tracer an a n a lyzer . In its simplest form the analyzer is only the standard output, or a le, in whic h traces are written b y a primitiv e tracer. Another form of analyzers is traditional debuggers, whic h are mere in teractiv e tracers of executions. They handle the in teraction onc e the execution is stopp ed at in teresting p oin ts. They sh o w some trace information and react on users' commands. More sophisticated debugging to ol s exhibit more sophisticated analyzers. A trace querying mec hanism with a database a v or can b e connected to a tracer and let users in v estigate executions i n a more t horough w a y . This has b ee n done for example f o r C in the Co ca to ol (Ducassé 1999a) and for Prolog in the Opium to ol (Du c ass é 1999b). A real database can ev en b e used 4 L. L angevine an d M. Duc assé if on the y p erformance is not a big issue. This has b een done for a distributed system in Hy + (Consens et al. 1994). Algorithmic debuggi ng t ra v erses an execution tree in an in teractiv e w a y . Users answ er querie s and an algorithm fo cuses on no des whic h seem erroneous to users while their c hildren seem correct (Shapiro 1983). Note that the d e clarativ e debugger of Mercury is explicitl y built on top of the Mer- cury tracer (MacLart y et al. 2005). Monitoring to ols can b e connec t e d to tracers in order to sup ervise executions and collect data. F o r example, the Morphine to ol for Mercury is able to assess the qualit y of a test set (Jahier and Ducassé 2002). The EMMI to ol, for Icon, is able to detect some programming mistak es (Jeery and Grisw old 1994). A n um b er of v i s ua lization t o ols use traces to generate graph- ical views suc h as the DiSCiPl views (Deransart et al. 2 000) for constrain t logic programming. The latest trend in fault lo calization consists in mining sets of program executions to cross c hec k execution trace s , see for example (Jones et al. 2002; Jones and Harrold 2005; Denmat et al . 2005). The in teraction mo des b et w een the tracer and the analyzers exhibited b y the previous exampl es are all dieren t and sp ecic. F or pr i mitiv e tracers, simple vi- sualization a n d trace mining, the tracer simply outputs trace information in to a giv en c hannel. T raditional debuggers, trace query systems and declarativ e debug- gers output information ab out executions and ge t user requests. W he n information is displa y e d and un til the user sends a request, the exec u ti on is blo c k ed. Monitors pro cess the trace information on the  y . The y also blo c k the execution un til they ha v e n i sh e d p ro cessing the curren t t rac e information but without an y in teraction with users. A t presen t, all these to ols are disjoin t and dicult to me r ge . There- fore, further mec hani s m s are required in order to share a tracer among analyzers of dieren t t yp es. When the tracer has sen t trace informati on to the analyzers, the ab o v e examples exhibit t w o b eha viors: 1) the execution is blo c k ed w aiting f o r an answ er from the analyzers; this is called sync hronous in teracti on in the follo wing; 2) the exec ut i on pro ceeds; this is called async hronous in teraction in the follo wing. Our tracer driv er includes b oth mec hanisms. It enables dieren t in teraction mo des b et w e en a tracer and analyzers to b e in tegrated in one single to ol. This has sev eral adv an tages. Firstly , users do not switc h to ols to a c hiev e dieren t aims. They use a single to ol to trace, debug, monitor and visualiz e executi ons . Secondly , in tegrating all the p ossible usages results in a more p o w erful to o l than the mere juxtap osition of dieren t to ols. F or example, one can, sim ultaneo u sl y , c hec k for kno wn bug patterns, and collec t data for visualization. Whenev er a bug is encoun tered the to o l can switc h to a sync hronous d e bugging se s sio n , using the already collected visualization data. The visualization to ol can also c hange the gran ularit y o f the collected data dep ending on the curr e n t con text. 1.3 Debugging of Constr a int L o gic Pr o gr ams The prop osed tracer driv er has b een designed in the con t e x t of constrain t logic programming. Exp erime n ts ha v e b een made within GNU-Prol og (Diaz 2003). Pro- T r ac er Driver and Dynamic A nalyses of CLP(FD) 5 grams with constrain ts are esp ecially hard to debug (Meier 1995). The n umerous constrain ts and v ariables in v o lv ed mak e the state of th e exec ut i on di cult to grasp. Moreo v er, the complexit y of the ltering al gorithms as w ell as the optimized prop- agation strategies lead to a tortuous e x e cution. As a result, when a program giv es incorrect answ ers, misses exp ected solutions, or has disapp oin ting p erformance, the dev elop er gets v ery little supp ort from the curren t programming en vironmen ts to impro v e the program. This issue is critical b ecause it increases th e exp ertise re- quired to de v elop constrain t programs. Some previous pap ers ha v e addressed this critical issue. Mo s t of t he m are based on dynamic analyses. During the exec ut i on, some data are colle cted in the execution so as to displa y some graphical views, compute some statistics and other abstraction of the execution b eha vior. Those data are then examined b y the programmer to gain a b etter understanding of the execution. F or instance, a displa y of the searc h-tree sho ws users ho w the searc h heuristics b eha v e (F ages 2002). A dding some visual clues ab out the domain propagation helps users lo c ate situations wh e re pr o p a gation is not strong enough (Carro and H ermenegildo 2000; Bracc hi et al . 2001). A structured insp ection of the store helps to in v estigate constrain ts b eha vior (Goualard and Benhamou 2000). A more detailed view of the propagation in sp ec ic no des of t he searc h-tree giv es a go o d i n si gh t to nd redundan t constrain ts or se lect dieren t ltering algorithms (Simonis a n d Aggoun 2000). A common observ ation is that there is no ultimate to ol that w ould meet all the debugging needs. A large v ariet y of complemen tary to ols already exists, ranging from coarse-grained abstraction of the whole execution to v ery detailed views of small sub-parts, and ev en application-sp ec ic displa ys. As a matter of fact, none of the curren t en vironmen ts in CLP con tain all of the in teresting features that ha v e already b een iden tied. Eac h of these features requires a dedicated instrumen tation of the exec ut i on, or a dedicated annotation of the traced p rogram , to collect the data they need. Those instrumen tations are often hard to mak e. Y et, man y of those dynamic analyses could b e built on top of lo w-lev el tracers. Th e generate d traces can b e structured and abstracted b y analyzers in order to pro duce high-lev el v i ews. With our tracer driv er, it i s ea s y to dev elop and explore dynamic analyses with div erse abstraction lev els. F or instance, w e can rst compute a general vie w of the searc h-tree, t rac ing only the execution ev en ts related to the searc h-tree construction and ignoring the propagation ev en ts o r just computing some basics statistics ab out propagation stages. Suc h an analysis quic kly giv es a general picture of the execution. Then, a more sp e cic analysis of, sa y , a subset of v ariables or constrain ts ma y pro vide further details ab out a sub-part of the program but ma y need a more v oluminous execution trace . 1.4 Contributions The con tributions of this article are threefold. Firstly , it justies the need for a tracer driv er in order to b e able to ecien tly i n tegrate sev eral dynamic analy- ses within a single to ol. In particular, it emphasizes that b oth sync hronous and async hronous comm unications are required b et w een the tracer and the analyzer. 6 L. L angevine an d M. Duc assé Secondly , it describ es in breadth and in some depth the mec hanisms needed to im- plemen t suc h a tracer driv er: 1) the patterns to sp ecify what trace information is needed, 2) the language of in teraction b et w e en the tracer driv er and the analyzers and 3) the mec hanisms to ecien tly lter trace information on the y . Lastly , an implemen tation has b een ac hiev ed inside GNU-Prolog. The pap er a s sume s propa- gation based solv ers only for purp oses of exp osition. The me c hanisms o f the tracer driv er are indep enden t of the traced language, t he y are still appl icable to solv ers that d o not use propagators. Exp erimen tal measureme n ts on CLP(FD) executions sho w that this arc hitecture increases the trace rele v ance and drastically sp eeds up trace generation and c omm unicatio n. More precisely , the exp erime n ts sho w that 1. The o v e rh e ad of the core tracer mec hanisms is small, therefore the core tracer can b e p ermanen tly activ ated 2. The tracer driv er o v erhead is in v ersel y prop ort i onal t o the a v erage time b e- t w een t w o traced e v en ts. It is acce pt a b l e for CLP(FD). 3. There is no o v erhea d in the ltering mec hanisms when searc hing sim ultane- ously for sev eral patterns. 4. The tracer driv er o v erhead is predictable for giv en patterns. 5. The tracer d ri v er approac h that w e prop ose is more ecien t than sending o v er a default trace, ev en to construct sophisticated graphical v i ews. 6. Answ ering queries is orders of magnitude more ecien t than displa ying t rac es. 7. There is no need to restrict the trace information a priori. 8. The p erformance of our to ol is comparable to the state-of-the-practice while b eing more p o w erful a n d more generic. Whereas the principles of the tracer driv er are indep enden t of the traced program- ming language, it is b est suited for high-lev el languages, suc h as constrain t logic programming, where eac h traced execution ev en t encompasses n umerous lo w-l ev el execution steps. In the follo wing, Section 2 giv es an o v erview o f the tracer driv e r and in particular the in teractio n s it enables b et w een a tracer and an analyzer. Section 3 sp ecies the nature of patterns. Section 4 presen ts the requests that an analyzer can send to our tracer and ho w they are pro cessed. Section 5 describ es in detail our ltering mec hanism and its implemen tation. Section 6 discusses the requiremen ts on the tracer for the o v erall arc hitecture to b e ecien t. Se ction 7 giv es exp erime n tal results and sho ws the eciency of the tracer driv er mec hanism. Section 8 discusses related w ork. 2 Ov erview of the tracer driv er This section presen ts an o v erview of the tracer driv er arc hitecture and, in partic- ular, the in teracti ons it enables b et w een a tracer and analyzers. The tracer and the analyzers are run as t w o c oncurren t pro cesses. The tracer spies the execution and can outpu t, when needed, c ertain trace ev en ts with some attac hed data. Eac h analyzer listens to the trace and pro cesses it. T r ac er Driver and Dynamic A nalyses of CLP(FD) 7 Event Filtering Trace data ... Execution Observed by tracer Tracer Driver Go! Event i Event i+1 Event i+2 Event i+3 Event i+4 Event i+5 Event i+6 Retrieving Data Event patterns Synchronous Handler Asynchronous Handler Send more data! Modify patterns! Trace and synchr. data Additional Trace Data Analyzer Mediator Fig. 4. Async h ronous and sync hronous in teractions b et w een the tracer and the analyzer mediator As already men tione d in the in tro duction, b oth sy nc hronous and async hronous in teractions ar e necessary b et w een the tracer and the analyzers. On the one hand , some analyzers are highly in teractiv e. Users ma y ask for more information ab out the curren t ev en t than what is pro vided b y default. In that cases, it is imp ortan t that the exec u ti on is blo c k ed un til all the analyzers notify it that it can pro ceed. On the other hand, if the a n a lyzers passiv ely collect information there is no need to blo c k the execution. An execution trace is a sequenc e of observ ed exec ution ev en ts that ha v e at- tributes. The analyzers sp ecify the ev en ts to b e observ ed b y the means of event p atterns . An ev e n t pattern is a condition on the attributes of an ev e n t (see details in Section 3). The t rac er driv er manages a set of activ e ev en t patterns. Eac h ex- ecution ev en t i s c hec k ed against the se t of activ e patte r ns. An ev en t matc hes an 8 L. L angevine an d M. Duc assé ev en t pattern if and only if the pattern condition is satised b y the attributes of this ev en t. An asynchr onous p attern sp ecies that, at matc hing trac e ev en ts, some trace data are to b e sen t to analyzers without freezing t he execution. A synchr onous p atte r n sp ecies that, at matc hing trace ev en ts, some trace data are to b e sen t to analyzers. The execution is frozen un til t he analyze rs order the execution to resume. An event hand ler is a pro cedure dened in an analyzer, whic h is called when a matc hing ev en t is encoun tered. Fig. 4 illustrates the treatmen t of the t w o t yp es of patterns. The execution is presen ted as a sequence of elemen tary blo c ks (the execution ev en ts). An analyzer mediator gathers the patterns requested b y the analyzers and distributes the trace data sen t b y the tracer dr i v er to the analyzers (see detai led description Section 4). A t eac h trace e v en t, the tracer driv er is called t o lter the ev en t. I f the curren t ev en t do es not matc h a n y of the sp ecied a ctiv e patterns, the execution con tin ues (ev en ts i , i + 1 , i + 2 , i + 4 , i + 6 ). If the curren t ev en t matc hes an activ e pattern, some trace data are se n t to the analyze r mediator (ev en ts i + 3 , i + 5 ). If the matc hed pattern is async hronous the data is pro cessed b y the relev an t analyzer in an async hronous w a y (ev en t i + 3 ). If the pattern is sync hronous the executio n is frozen, w aiting for a query from the analyzer (ev en t i + 5 ). The analyzer pr o cesses the sen t data and c an ask for more data ab out the state of the execution. The tracer driv er c an retriev e useful data ab out the execution state and send them to the analyzer on demand. The analyzer can also request some mo dications of the activ e patterns: add new patterns or remo v e existing ones. When no analyzer has an y further request to mak e ab out the curren t ev en t, the analyzer mediator sends the resuming co mmand to the t rac er driv er ( g o command). The tracer then resumes the execution un til the next matc hing ev en t. The arc hitecture enable s the managemen t of sev eral activ e patterns. Eac h pattern is iden tied b y a lab el. A giv en execution e v en t ma y matc h sev eral patterns. When sending the trace data, the list of (lab el s of ) matc hed patterns is added to the trace. Then, the analyze r mediator calls a sp ecic handler for eac h matc hed pattern and dispatc hes rel ev an t t rac e data to it. If at least one matc hed pattern is sync hronous, the analyzer mediator w aits for ev ery sync hronous handler to nish b efore sending the resuming command to the tracer driv er. F rom the p oin t of view of a giv en ev en t handler, the acti v ation of other handlers on the same execution e v en t is transparen t. This article fo cuses more on the tracer driv er than on the analyzer mediator. On the one hand, the design and implemen tation of the tracer driv er is critical w i th resp ect to resp onse time. Indeed it is called at eac h ev en t and e x e cutions of sev eral millions of ev en ts (see Section 7) are v ery common. Ev ery o v erhead, ev en the tiniest, is therefore critical. On the other hand, the implemen tation of the analyzer mediator is m uc h less critical b ecause it is called onl y on matc hing ev en ts. F urthermore, its implemen tation is m uc h easier. T r ac er Driver and Dynamic A nalyses of CLP(FD) 9 3 Ev en t P atterns As already men tioned, an ev en t pattern is a condition on the attributes of ev en ts . It consists of a l ogical form ula com bining elem en tary conditions on the attributes. This section summarize s the information attac hed to tr a ce ev en ts, sp ecies the format of the ev en t patterns and giv es examples of patterns. 3.1 T r ac e Ev ents Some information is attac hed to eac h trace ev en t. This section summarizes the format of t rac e ev en t information us e d in this article; a more detai led description can b e found in (Langevine et al. 2004). The actual format of trace ev en t informa- tion has no inuenc e on the tracer driv er mec h a n i sms. The imp ortan t issue is that ev en ts ha v e attributes and that some attributes are sp ecic to the t yp e of ev en ts. Note that the pattern language is indep enden t of the traced language. A constrain t program manipulates v ariables and constrain ts on these v ariables. Eac h v ariable has a domain , a nite set o f p ossible v al u e s. The aim of a constrain t program is to nd a v aluation (or the b est v aluation, giv en an ob jectiv e function) of the v ariabl es suc h that ev ery constrain t is s ati s e d . T o do so, constrain t solv ers implemen t n umerous algorithms coming from v arious researc h areas, suc h as op er- ation researc h. T raditionally in log ic programming, the t yp e of ev en ts is called a p ort . There are 14 p ossible ev en t t y p es in the tracer w e use. Those t yp e s of ev e n ts are partitioned in to t w o classes: con trol ev en ts and propagation ev en ts. The con trol ev en ts are related to the handli n g of the constrain t store and the s e arc h: • new va riable sp ecies that a new v ariable is in tro duce d; • new constraint sp ecies that the solv er declares a new constr a in t; • p ost sp ecies that a declared c onst rai n t is in tro duced in to the store as the activ e one; • new child sp ecies that the curren t solv er s tate corresp onds to a new no de of the searc h-tree; • jump to sp ecies that the solv er bac k-jumps fr om its curren t state to a previous c hoice-p oin t; • solution sp ecies that the c urr e n t solv er s tate is a solution (a toplev el success); • failure sp ecies that the curr e n t state is inconsisten t. Six p orts describ e the dom ain reductions and the constrain t propagation: • reduce sp ecies that a domain is b eing reduced, this generates domain up dates whic h ha v e to b e propagated; • susp end sp ecies that the activ e co n strain t cannot reduce an y more domains and is th us susp ended; • entail sp ecies that the activ e constrain t is true; • reject sp ecies that the activ e constrain t is unsatisable ; • schedule sp ecies that a domain up date is selected b y the propagation lo op; • a w ak e sp ecies that a constrain t whic h dep ends on the sc heduled domain up- date is a w ak ened; 10 L. L angevine an d M. Duc assé 1 newVariable v1=[0-268435455] 2 newVariable v2=[0-268435455] 3 newConstraint c1 fd_element([v1,[2,5,7],v2]) 4 reduce c1 v1=[1,2,3] delta=[0,4-268435455 ] 5 reduce c1 v2=[2,5,7] delta=[0-1,3-4,6,8-2 68435455] 6 suspend c1 7 newConstraint c4 x_eq_y([v2,v1]) 8 reduce c4 v2 =[2] delta=[5 ,7] 9 reduce c4 v1 =[2] delta=[1 ,3] 10 suspend c4 11 awake c1 12 reject c1 Fig. 5. A p ortion of t rac e • end of trace noties the end of the tracing pro cess. 3.2 Event A ttributes Eac h ev en t has common and sp ecic attributes. A ttributes are data ab out the exe- cution ev en t. The common attributes are: the p ort, a c hronological ev en t n um b er, the depth of the curren t no de in the searc h-tree , the solv er state (con taining all the domains, the full constr ai n t store and the propagation queue), and the user time sp en t since th e b e ginning of the execution. The s p ecic attributes dep end on the p ort. F or example, the sp ecic attributes for p ort new va riable are the v ariabl e iden tier and its initial domain. F or the p orts related to the s e arc h-tree the only sp ecic attribute is the no de lab el. Sp ecic attributes for other p orts are describ ed in (Langevine et al . 2004). Fig. 5 presen ts the b eginning of a trace of a to y program in order to illustrate the ev en ts describ ed ab o v e. This program, fd_element( I, [2,5,7],A), (A#=I ; A#=2) , sp ecies that A is a nite domain v a r i able whic h is in { 2 , 5 , 7 } and I is the index of the v alue of A in this list; moreo v er A is either equal to I or equal t o 2. The second alternativ e is the only fea s i b l e one. The trace can b e read as follo ws. The rst t w o ev en ts are related to the in tro duction of t w o v ariables v 1 and v 2 , corresp onding resp ectiv ely to I and A . In Gn u-Prolog, v a r i ables are alw a ys created with the maxim um domain (from 0 to 2 28 − 1 ). Then the rst constrain t is created: fd_element (ev en t #3). This constrain t mak es t w o domain reductions (ev en ts #4 and #5): the v alues remo v ed from the domain of the rst v ariabl e ( I ) are listed in delta , the domain b ecomes { 1 , 2 , 3 } and the domain of A b ecomes { 2 , 5 , 7 } , the only consisten t v alues so far. After these reductions, the constrain t i s susp ende d (ev en t #6). The next constrain t, A#=I , is added (ev en t #7). T w o reductions are done on v ari ables A and I , the only p ossible v alue for A and I to b e equal is 2 (ev en ts #8 and #9). After these reductions, the constrain t is susp ended (ev en t #10). The rst constrain t is a w ok en (ev e n t #11). If A and I are b oth equal to 2 , I cannot b e the rank of A . I ndeed, the rank of 2 is 1 and the v a lue at rank 2 is 5 . The constrain t is the r e for e rejected (e v en t #12). The execution con tin ues and nds the solution ( A=2 , I=1 ) This requires 20 other e v en ts not s ho wn here. T r ac er Driver and Dynamic A nalyses of CLP(FD) 11 p attern ::= lab el : when evt_p attern op_synchr o action_list op_synchr o ::= do | do_sync hro action_list ::= action , action_list | action action ::= curren t( list_of_attrib u t es ) | call( pr o c e dur e ) evt_p attern ::= evt_p attern or evt_p attern (1) | evt_p attern and evt_p attern (2) | not evt_p attern (3) | ( evt_p attern ) (4) | c ondition (5) c ondition ::= attribute op2 value | op1 ( attribute ) | true op2 ::= < | > | = | \ = | >= | =< | in | notin | con tains | notcon tains op1 ::= isNamed Fig. 6. Grammar of ev en t patterns 3.3 Patterns W e use patterns similar to the path rules of B r ue gge and Hibbard (Bruegge and Hibbard 1983). Fig. 6 presen ts the grammar of patterns. A pattern con tai ns four parts: a lab el, an ev en t pattern, a sync hronization op erator and a list of actions. An ev en t pattern is a comp osition of elemen tary c onditions using logical conjunc- tion, disjunction and negation. I t sp ecies a class of execution ev en t. A sync hro- nization op erator tells whether the pattern i s async hronous ( do ) or sync hronous ( do_sync hro ). An action sp ecies either to ask th e tracer driv er to c ollect at- tribute v alues ( curren t( list_of_attributes ) ), or to ask the analyzer to call a pro- cedure call( pr o c e dur e ) . Note that the pro cedure is written i n a language that the analyzer is able to execute. This language is indep enden t of the tracer driv er. An elemen tary condition concerns an attribute of the curren t ev en t. There are sev eral kinds of attribut e s. E a c h kind has a sp ecic set of op erators to build elemen tary conditions. F or example, most of t he common attributes are in teger (c hrono, depth, no de lab el). Classical op erators can b e used with those at- tributes: equalit y , disequalit y ( 6 = ), inequalities ( < , ≤ , > and ≥ ). The p ort attribute is the t yp e of the curren t ev en t. It has a small set of p ossible v alues. The follo wing op erators can b e used with the p ort attribute: equalit y and disequalit y ( = and 6 = ) and t w o set op erators, in and notin . Constrain t solv ers manipulate a lot of con- strain ts and v ariables. Often, a trace analysis is onl y in terested in a small subset of them. Op erators in and notin , applied to iden tiers of en tities or name of the v a r i ables, can sp ecify suc h subs e ts . Op erators con tains and notcon tains are used to express conditions on domains. This set of op erators i s sp ecic to the t yp e of execution w e trace . It could b e extended to c op e with other t yp es of a t tributes. 12 L. L angevine an d M. Duc assé visu_tree: when port in [choicePoint, backTo, solut ion, failure] do current(port=P and node=N and depth=D and usertime=Time), call search_tree (P,N,D,Time) visu_cstr: when port = post do current(cstr=C and cstrRep=Rep and varC(cstr)=V arC), call new_cstr(C, Rep, VarC) visu_prop: when port = reduce and isNamed(var) and (not cs trType='assign') and delta n otcontains [maxInt] do current(cstr=C and var=V), call spy_propag(C, V) leaf: when port in [solution, failure] do_synchro current (port=P and node=N and depth=D), call new_leaf( P,N,D) symbolic: when port in [reduce,suspend] and (cstrType = 'fd_element_var' or cstrType = 'fd_exactly') do_synchro call symbolic_monitor Fig. 7. Examples of patt e rns for visualization and monitoring Fig. 8. T w o trace-based views based on the pattern visu_cstr of Figure 7. 3.4 Examples of Patterns Fig. 7 presen ts v e patterns that can b e activ ated s i m ultaneously . The rst three patterns are visualization orien ted: the rst one, visu_tree , aims at constructing the searc h-tree (creation of a c hoice-p oin t, bac ktrac king, failure and solution are the relev an t p orts) with few details ab out eac h no de: the lab el of the no de , its depth T r ac er Driver and Dynamic A nalyses of CLP(FD) 13 and the c hronological time stamp of the ev en t. This enables the displa y of no des to b e w eigh ted b y the time s p en t in their sub-tree. The second pattern, visu_cstr , requests the trace of eac h constrain t-p osting with the iden tier of the constrain t (a unique in teger), its represen tation (the name of the constrain t with its parame ters ) and the list of the in v olv ed v ariables ( varC ). Fig. 8 giv es t w o screen-shots of visualizations that are bu i lt using pattern visu_cstr . The rst picture is generated b y CLPGUI (F ages 2002). The s e cond picture is generated b y P a v ot, a graphical to ol d e v elop ed at INRIA Ro cquencourt and connected to GNU-Prol og tracer driv er 1 . The third pattern, visu_prop , requests the trace of all the domain reductions made b y constrain ts that do not come from the assignmen t pr o cedure and that do not remo v e the max i mal in teger v al ue. It stores the re du c ing constrain t and the reduced v ariable . Those data can b e used to compute some statistics and to visualize the impact of eac h constrain t on its v ariables. Those three patterns are async hronous: the requested data are sucien t for the visualiz ation and the patterns do not ha v e to b e mo died. The fourth pattern, leaf , sy nc hronizes the e x e cution at eac h leaf of the searc h- tree (solution or failure). A t those ev en ts, the new_leaf function ca n in teract with the tracer to in v estigate the e x e cution state. The last pattern, symbolic , is more monitoring-orien ted: it freezes the execu- tion at eac h domain reduction made b y a sym b olic constrain t suc h as element (on v a r i ables) or exactly . This pattern allo ws the monitoring of the ltering algorithms used for these t w o c onst rai n ts. 4 Analyzer Mediator The analyzer mediator is the in te r fac e b et w een the tracer driv er and t he analyze r s. It sp ecies to the tracer driv er what ev e n ts are nee ded and ma y execute sp ecic actions for eac h class of relev an t ev en ts. The mediator can sup ervise sev eral anal- yses at a time. Eac h analysis has its o wn purp ose and uses sp e cic pieces of trace data. The i nd e p endence of the concurren t analyses is ensured b y the mediator t hat cen tralizes the comm unication with the tracer driv er and di s tributes the trace data to the ongoing analyses. The adv an tage i s that if a piece of trace information is needed b y sev eral analyses, it i s sen t o v er the in terface only once. When a sync hronous ev en t has b een sen t to the mediator, the requests that an analyzer can send to the driv er are of three kinds. Firstly , the anal y z er can ask for additional d a t a ab out the curren t ev en t. Secondly , the analyzer can mo dify the set of activ e ev en t patterns, to b e c hec k ed b y the tracer driv er. Thirdly , t he analyzer can notify the t rac er driv er that the execution can b e resumed. The actual requests are as f o llo ws. current sp ecies a list of ev en t attributes to retriev e in the curren t execution 1 h ttp://con train tes.inria.fr/arnaud/pa v ot/ 14 L. L angevine an d M. Duc assé step :- reset , add ([step:when true dosynchro call(tracer_toplevel )]), go . skip_reductions :- curren t (cstr = CId and port = P), reset , ( P == awake -> add ([sr:when cstr = CId and port in [suspend,reject,entail] dosynchro call(t racer_toplevel)]), ; add ([step:when tr ue do_synchro call(tracer_tople vel)]) ), go . Fig. 9. Implemen tation of t w o tracing commands ev en t. The tracer retriev es the requested pieces of data. It sends the data as a list of p a irs ( attr ibute, v al ue ) . reset deletes all the activ e ev en t patterns and their lab els. remove deletes the activ e patterns whose lab els are sp ecied in t he parameter. add inserts in the activ e patterns, the ev en t patterns sp ecied in the parameter, follo wing the gramm ar describ ed in Figure 6. go noties the tracer driv er that the traced execution is to b e resumed. Fig. 9 illustrates the use of the primitiv es to impl emen t t w o tracing commands. Let us assume that the analyze r is a (p ossibly simplied) Prolog in terpr e ter, as for example in Opium (Ducassé 1999b). Command step enables executi on to go to the v ery next ev en t. It simply resets all patterns and adds one that will matc h an y ev e n t and call, wi t h sync hronous in teractions, the tracer toplev el. Command skip_reduc tions enables exec u ti on to skip the details of v ariable domain reduc- tions when encoun tering the a w ak ening of a constrain t. It rst c hec ks the curren t p ort. If it is a w ak e it asks to go to the susp ension of this c onst rai n t. There, the us e r will, for example, b e able to c hec k the v alue of the domai ns aft e r all the reductions. If the command is called on an ev en t of another t yp e, it simply acts as step . 5 Filtering Mec hanism This section de s c rib es in detail the critical issue of the ltering mec hanism. A t eac h execution ev en t , it is called to test the rele v ance of the ev en t with resp ect to the activ e patterns. No t i ce that the execution of a program with constrain ts can lead to sev eral m illions o f execution ev en ts p er second. Therefore, the ec iency of the ev en t ltering is a k ey issue. In the follo wing, w e rst describ e the algorithm of the tracer driv er. Then w e sp ecify the automata whic h driv e the matc hing of ev en ts against ac t i v e patterns. W e di s c us s some sp ecialisation issues. W e giv e some details ab out the incremen tal handling of patterns. Lastly , w e emphasiz e that ev en t attributes are computed only up on demand. T r ac er Driver and Dynamic A nalyses of CLP(FD) 15 1. proc tracerDriver( P : set of activ e patterns) 2. tag g ed ← ∅ 3. for each p ∈ P do 4. if match( p ) then tag g ed ← tag g ed ∪ { p } 5. end for 6. T ← { r equested _ data ( p ) | p ∈ tagged } 7. sen d_trace_data(T, label ( tagg ed ) ) 8. if sy nchronous ( tag g ed ) 6 = ∅ then 9. notify( sy nchronous ( tag g ed ) ) 10. repeat 11. r equest ← receive_from anal yzer() 12. execute( r equest ) 13. until r equest = go 14. end if 15. end proc Fig. 10. Algorithm of the T racer Driv er 5.1 T r ac er Drive r A lgo rithm When an execution ev en t o ccurs, the tracer is called. The tracer collects some data to main tain its o wn data structures and then calls the tracer driv e r . The algori t hm of t he tracer driv er is giv en in Fig. 10. The ltering mec hanism can handle sev eral activ e ev en t patterns . F or eac h pattern, if the curren t ev en t matc hes the p a t te r n the latter is tagged as activ ated; whatev er the matc hing result, the next pattern is c hec k ed (line s 3-5). When no more patterns ha v e to b e c hec k ed, the tagged patterns are pro cessed; the union of requested pieces of data is sen t as trace data wi th the lab els of the tagged patterns (lines 6-7). If at l east one s ync hronous pattern is tagged, a signal is sen t to the analyzer; the tracer driv er w aits for requests coming from the analyzer and pro cesses them un til the go primitiv e i s sen t b y the analyzer (lines8-14). 5.2 Pattern A utomata The m atc hing of an ev e n t against a pattern is driv en b y an automaton where eac h state is lab ele d b y an elemen tary condition with t w o p ossible transitions: true or false. Th e automaton has t w o nal states, true and false . If the true state is reac hed, the ev en t is said to matc h the pattern. Eac h automaton r e su l ts from the compilation of an ev en t pattern. This compilation is inspired b y the ev aluation of B o olean expressions in imp erativ e languages. It has b een pro v en that it mi n i - mizes the n um b er of conditions to c hec k (Wil h e lm and Maurer 1995). Examples of automata are giv en in Figure 11, section 5.4 . 5.3 Sp e cialization A c c or ding to the Port As seen in Section 3, the p ort is a sp ecial attribute since it denotes the typ e of the execution ev en t b eing traced. A p ort corresp onds to sp ecic parts of the solv er co de where a call to a function of the tracer has b een ho ok ed. F or example, in the tracer w e use, there are four ho oks for the reduce p ort, em b edded in to four sp ecic 16 L. L angevine an d M. Duc assé current cstr var cstr cstrRep varC(cstr) current current port node depth [268435455] delta backTo solution failure post reduce suspend awake entail reject schedule newConstraint newVariable choicePoint time current depth port node Ports A s y n c h r o n o u s A s y n c h r o n o u s A s y n c h r o n o u s cstrType=’fd_element_var’ Y e s Y e s cstrType=’fd_exactly’ N o F a il N o S y n c h r o n o u s S y n c h r o n o u s F a il cstrType=’assign’ isNamed(var) N o Y e s Y e s N o N o Y e s endOfTrace visu_tree visu_cstr visu_prop symbolic leaf Fig. 11. In ternal represen tatio n of the v e patterns of Figure 7 functions that mak e domain reductions in four dieren t w a ys. F urthermore, sp ecic attributes dep end on the p ort. As a c ons e q ue nce, the p ort is cen tral in the pattern sp ecication. F or most p a t te r ns, a conditio n on the p o r t will b e explicit. When an ev en t o ccurs, it is useless to call the tracer driv er if no pattern is relev an t f o r the p ort of t hi s ev en t. Therefore , for eac h p ort, a  a g in the related ho oks indicates whether the p ort app ears in at least one pattern. This simple mec hanism a v oids useless calls to the tracer driv er. 5.4 Examples of Pattern A utomata Fig. 11 sho ws the in ternal represen tatio n of the v e patterns presen ted in Figure 7, Section 3.4. The 14 p orts are represen ted on the left-hand side. Th e irrele v an t p orts are in italic. The rele v an t p orts are link ed to their corresp onding patterns. Only t w o automata are necessary since three of the p a t te r ns c hec k the p ort only . A set of actions is assigned to eac h automaton. This set is attac hed to sync hronous or async hronous and the lab el of t he pattern. 5.5 Incr emental Pattern Managem ent Since eac h activ e pattern is a sp ecic automaton (or a l ist of sp ecic automata when split), the add primitiv e has just to compile the new n patterns in to m automata, link ed them with their re s p ectiv e p orts and store the lab els with the lists of resulting automata. The remove primitiv e has ju st to delete the automata asso ciated to the sp ecied lab els and to erase the dead links. After eac h op eration, the p ort-ltering ags are up dated so as to tak e in to accoun t the new state of the activ e patterns. 6 Protot yp e Implemen tatio n In thi s Section, w e briey presen t the protot yp e implem en tation. In particular, in order for the o v e rall arc hitecture to b e e cien t , it is essen tial that the trace r is lazy . T race information m ust not b e computed if it is not expli citly required b y a pattern. Indeed, an execution has man y ev en ts and ev en ts p oten tially ha v e man y T r ac er Driver and Dynamic A nalyses of CLP(FD) 17 attributes. Most of them are not straigh tforw ardly a v ailable, they ha v e to b e com- puted from the e x e cution state or from the debugging data of the tracer. System- atically computing all the attributes at all the executi on ev en ts w ould b e t e rr i bly inecien t. F ortunately , not all the attributes need to b e computed at eac h ev en t. A ccording to the activ e patterns, only a s ubset of the attributes is needed: rstly , the attributes necessary to c hec k the relev ance of the curren t ev en t with resp ect to the patterns, and secondly , the attributes requested b y the patterns in case of m atc hing. There- fore, the tr ac er m ust not compute an y trace a t tribute b efore it i s needed. When a sp ecic attribute is needed, it is computed and its v alue is stored un til the end of the c hec king of the curren t ev en t. If an attribute is used in sev eral conditions, it is computed only once. The tracer implemen ted in the curren t protot yp e, Co deine, stric t l y fol lo ws this guideline. Some core tracer mec hanisms ar e needed to handle the debugging in- formation (see (Langevine et al. 2003) for more details). As sho wn i n Sec. 7, the o v erhead induced b y these mec hanisms is marginal, ev en though constrain t solv ers do manipulate large and complex data. Curren tly , Co deine is implemen ted in 6800 lines of C incl ud i ng commen ts. The tracer driv er, i ncluding the comm unication mec hanisms, is 1700 lines of C. The co deine tracer including the tracer driv e r is a v ailable under GNU Public Licence. The set of debugging and visualization to ols called P a v ot has b een dev elop ed b y Arnaud Guillaume and Ludo vic Langevine. Both systems are a v ail able on line 2 . 7 Exp erimen tal Results This section assesses the p erformance of the tracer driv er and its e ects on the cost of the trace generation and comm unication. Sections 7.1 and 7 .2 de s c r i b e the metho dology of the exp erimen ts and the exp erimen tal setting. Se ction 7.3 li s ts the b enc hmark programs. Sections 7. 4, 7.5 and 7.6 resp ectiv ely discuss the tracer o v erhead, the tracer driv er o v erhead and the comm unication o v erhead. 7.1 Metho dolo gy of the Exp eriments When tracing a program, some time is sp en t in the program execution ( T prog ), some time is sp en t in the core mec hanisms of the tracer ( ∆ tracer ), some time is sp en t in the tracer driv er ( ∆ driv er ), some time is sp en t generating the r e q ue s te d trace and sending it to the analysis pro cess ( ∆ g com ), and lastly s o me time is sp e n t in the analyses ( ∆ ana ). Hence , if w e call T the execution time of a traced and analyze d program, w e appro ximately ha v e: T ' T prog + ∆ tracer + ∆ driv er + ∆ g com + ∆ ana . 2 They can b e retriev ed at h ttp://con train tes.inria.fr/lange vin/co deine/ and h ttp://con train tes.inria.fr/arnaud/pa v ot/. 18 L. L angevine an d M. Duc assé The mediator is a simple switc h. The time tak en b y its execution is negligible compared to the tim e tak en b y the simplest analysis, namely the displa y of trace information. T race analysis t a k es a time whic h can v ary considerably acc or di ng to the nature of the analysis. The fo cus of this article i s not to discuss whic h analyses can b e ac hiev ed i n reasonable time but to sho w that a exible analysis en vironmen t can b e oered at a lo w o v e r he ad. Therefore, in the follo wing measuremen ts ∆ ana = 0 . 7.2 Exp erimenta l Setting The exp e r i men ts h a v e b e en run on a PC, with a 2.4 GHz P en tium iv , 512 Kb of cac he, 1 Gb of RAM, running under the GNU/Lin ux 2.4.18 op e rating system. W e used the most rece n t stable release of GNU -Prolog (1.2.16). The tracer is an instru- men tation of the source co de of this v ersion and has b een compiled b y gcc-2.95.4 . The exec u ti on times ha v e b ee n measured with the GNU -Prolog proling facilit y whose accuracy is said to b e 1 ms. The measured exec u ti ons consist of a batc h of executions suc h that eac h measured time is at least 20 seconds. The measured time is the sum of system and user times. Eac h exp erime n tal time giv en b elo w is the a v erage time of a series of ten me asu re men ts. In eac h series, the maximal r e lativ e deviation w as smalle r than 1 %. 7.3 Benchmark Pr o gr ams The 9 b enc hmark programs 3 are listed in T able 1, sorted b y increasing n um b er of trace ev en ts. Magic(100), squ a r e (4), golom b(8) and golfer(5,4,4) are part of CSPLib, a b enc hmark library for c onst rai n ts b y Gen t and W al s h (Gen t and W alsh 1999). The golom b(8) program is executed with t w o strategies whic h exhibit v ery dieren t resp onse times. Those four programs ha v e b een c h o s e n for their signican t execution time and for the v ariet y of constrain ts they in v olv e. F o u r other programs ha v e b een added to co v er more sp ecic asp ects of the solv er mec hanisms: P ascal V an Hen tenryc k's bridge problem, impl emen tation of (Diaz 2003); t w o inst anc es of the n -queens problem; and propag, whic h pro v es the infeasibilit y of 1 ≤ x ∧ y ≤ 70000000 ∧ x < y ∧ y < x. The in terest of the latter is the l ong stage of propagation in v o lving one of the simplest and the most optimized constrain ts GNU -Prolog pro vides: b ound consis- tency for a strict inequalit y . Therefore, this program the w orst kind of case for the propagation instrumen tation. The b enc hmark programs ha v e executions large enough for the measuremen ts to b e m eaningful. They range fr o m 200,000 ev en t s to ab out 4 00 millions ev en ts . F urthermore, they represen t a wide range of CLP(FD) programs. The third c olumn giv es the size of the traces of the b enc hmark ed programs for the default trace mo del. All executions but the smallest one exhibit more than a 3 Their source co de is a v ailable at h ttp://con train tes.inria.fr/langevin/co deine/b enc hmarks T r ac er Driver and Dynamic A nalyses of CLP(FD) 19 Program #ev en ts T race T prog ε R tr. Dev. ( 10 6 ) Size ( ms ) ( ns ) for T x (Gb) in % bridge 0.2 0.1 14 72 1.21 ≤ 0 . 4 que ens(256) 0.8 1.5 173 210 1.14 ≤ 0 . 2 magic(100) 3.2 1.4 215 66 1.03 ≤ 0 . 2 squar e(24) 4.2 20.8 372 88 1.05 ≤ 0 . 6 golombF 15.5 3.4 7,201 464 1.01 ≤ 0 . 4 golomb 38.4 7.9 1,721 45 1.00 ≤ 0 . 5 golfer(5, 4,4) 61.0 >30 3 , 2 55 53 1.05 ≤ 0 . 7 pr op ag 280.0 >30 3,813 14 1.28 ≤ 1 . 0 que ens(14) 394.5 >30 17,060 43 1.08 ≤ 0 . 4 T able 1. Benc hmark Programs and tracer o v erhead gigab yte, for executions sometimes less than a second. It is therefore not feasi b l e to systematically generate suc h an amoun t of information. As a matter of fact measuring these siz es to ok us hours and, in the last three cases, exhausted our patience! Note that the size of the trace is not strictly prop ortional to the n um b er of ev en t s b ecause dieren t sets of attributes are collected at eac h t yp e of ev en ts. F or example, for domain reductions, sev eral attributes ab out v ariables, constrain ts and domains are collected whil e other t yp es of ev en ts simply collect the name of the corresp onding constrain t. The fourth co lumn giv es T prog , the e x e cution time in ms of the program simply run b y GNU -Prolog. The ft h column sho ws the a v erage time of e x e cution p er ev en t ε = T prog #even ts . It is b et w een 14 ns and 464 ns p er ev en t. F or most of the suite ε is around 50ns. The three notable exceptions are pr op ag ( ε = 14 ns), que ens(256) ( ε = 210 ns) and golombF ( ε = 464 ns). The lo w ε is due to the eciency of the propagation stage for the constrain ts in v olv ed in this c omputation. The large ε s are due to a lo w er prop ortion of ne-graine d  ev en t s. 7.4 T r ac er Overhe ad The six th column of T able 1 also giv es the results of the measurem en ts of the o v erhead of the core tracer m ec hanisms, R tr ( acer ) , whic h is dened as the ratio: R tr ( acer ) = T tracer T prog . where the measure of T tracer ' T prog + ∆ tracer is the execution time of the program run b y the tracer without an y pattern a cti- v a t e d. The tracer main tains its o wn data for all ev en ts. Ho w ev er, no attribute is calculated and no trac e is generated. The sev en th column giv es the maxim um deviation for T prog and T tracer . 20 L. L angevine an d M. Duc assé 1a. when p ort=p ost and isName d(cname) do curr ent(p ort,chr ono,cident) . 2a. when p ort=r e duc e and (isName d(vname) and isName d(cname) ) do curr ent(p ort,chr ono,cident) . 3a. when chr ono=0 do curr ent(chr ono) . 4a. when depth = 5 0000 or (ch r ono>=1 and no de=9999 999) do curr ent(chr ono,depth) . 5a : patterns 1a, 2a, 3a and 4a activ ated sim ultaneously . Fig. 12. P atterns used to measure the tracer driv er o v erhead Cor e tr ac er me chanisms c an b e p ermanently activate d. F or al l the measured ex- ecutions R tracer is less than 30% in the w orst case, and less than 5% for v e traced programs. The results for R tracer are v ery p ositiv e; they mean that the core me c h- anisms of the trac er can b e systematicall y activ ated. Users will hardly notice the o v erhead. Therefore, while dev elo p i ng programs, users can directly w ork in trace d  mo de; they do not need to switc h from un traced to traced en vironmen ts. This is a great com f ort. As so on as they need to trace t he y can immediatel y get information. 7.5 T r ac er Drive r Overhe ad The measure of T driv er ' T prog + ∆ trace + ∆ driv er is the execution time of the program run b y the tracer with the ltering pro cedure activ ated for ge n e ric patterns. Only the attributes ne cessary for the requested patterns are calculated at relev an t ev en ts. In order for ∆ g com to b e zero, the patterns are designed s uc h that n o ev en t matc hes them. One run is done p er pattern. The patterns are listed in Figure 12. P attern 1a is c hec k ed on few ev en ts and on one co s tly attribute only . P attern 2a is c hec k ed on t w o costly attributes and on n umerous ev en ts. Indeed, reduce ev en ts trace the main mec hanism of the propagation and they are sig n i can tly more n umerous than the other t yp es of ev en ts. P attern 3a is c hec k ed on all ev en ts and on one c heap attribute. P attern 4a is c hec k ed on all ev en ts and systematically on three attributes. In order to measure the o v e rh e ad of the tracer driv er, for eac h of the 5 patterns a ratio R pattern is computed for all b enc hmark programs : R pattern = T driv er T prog = 1 + ∆ pattern driv er T prog . Figure 13 displa ys all the ratios compared to the a v erage time p er ev en t ( ε ) of the programs. The smallest v alue of ε , 14, corresp onds to program pr op ag and the biggest v alue, 464, corresp onds to program golom bF. In addition, the gur e sho ws the curv e S ig ma R = R 1 a + R 2 a + R 3 a + R 4 a − 3 , that adds the o v erheads of the four separated patterns. T r ac er Driver and Dynamic A nalyses of CLP(FD) 21 Time per execution event (ns) 1 2 3 4 5 6 7 8 0 50 100 150 200 250 300 350 400 450 500 Performance Ratio R5a R1a R2a R3a R4a Sigma R Fig. 13. Cost of the tracer driv er mec hanisms for patterns 1a to 5a compared to ε T r ac er driver overhe ad is ac c eptable. In Figure 13, for all but one program, R pattern is negligible for the v ery simple patterns and less than 3.5 for pattern 5a whic h is the com bination of the other four patterns. F or programs with a large ε , e v en searc h i ng for pattern 5a is neg ligible. In the w orst case, for pr op ag , an o v erhead ratio of 8 is still acceptable. No overhe ad for simultane ous se ar ch for p atterns. When n patterns are c hec k ed sim ultaneously they already sa v e ( n − 1) T tracer compared to the searc h in sequence whic h re q ui r e s the program to b e executed n times instead of one time. Figure 13 further sho ws that the curv e S ig ma R = R 1 a + R 2 a + R 3 a + R 4 a − 3 , is ab o v e the curv e of R 5 a . Hence ∆ 1 a driv er + ∆ 2 a driv er + ∆ 3 a driv er + ∆ 4 a driv er > ∆ (1 | 2 | 3 | 4) a driv er . This means that not only is there no o v erhead in the ltering mec hanism induced b y the sim ultaneous searc h, but there is ev en a minor gain, due to the factorization in the automata describ ed Sec tion 5.2. T r ac er driver overhe ad is pr e dictable. The measured p oin ts of Figure 13 can b e in terp olated with curv es of the form R driv er = a + b/ε . 22 L. L angevine an d M. Duc assé magic(100) golombF queens(256) square(24) bridge golomb golfer(5,4,4) queens(14) propag Time per execution event (ns) 1 2 3 4 5 6 7 8 0 50 100 150 200 250 300 350 400 450 500 10 100 1000 10000 100000 1e+06 1e+07 1e+08 1e+09 Performance Ratio Nu m be r o f E ve n ts R5a 1 2 3 4 5 6 7 8 0 50 100 150 200 250 300 350 400 450 500 10 100 1000 10000 100000 1e+06 1e+07 1e+08 1e+09 Performance Ratio Nu m be r o f E ve n ts R5a 1 2 3 4 5 6 7 8 0 50 100 150 200 250 300 350 400 450 500 1e+09 Performance Ratio R5a nb. of evts. (log) Nu m be r o f E ve n ts Fig. 14. Cost of the tracer driv er mec hanisms compared to the n um b er of ev en ts Figure 14 recalls the curv e for pattern 5a and giv es the n um b er of ev en ts. It sho ws that there is no correlation b et w een the size of the trace and the tracer driv er o v erhead. Those results mean that the tracer and tracer driv er o v erheads p er ev en t ca n b e appro ximated to constan ts dep ending on the patterns and these constan ts are inde- p endent of the tr ac e d pr o gr am. Indeed, let us assume that that ∆ tracer = N δ tracer and ∆ driv er = N δ driv er where N is th e n um b er of ev en ts of an execution, δ tracer and δ driv er are the a v erage t i me p e r ev en t tak en resp ectiv ely b y the core tracer mec h- anism and the tracer driv er, for all the pr o gr a ms. W e ha v e also already assumed that T driv er ' T prog + ∆ tracer + ∆ driv er , and w e ha v e R driv er = T driv er T prog , and T prog = N ε therefore R driv er ' T prog +∆ tracer +∆ driv er T prog R driv er ' 1 + N ( δ tracer + δ driv er ) N ε R driv er ' 1 + δ tracer + δ driv er ε T r ac er Driver and Dynamic A nalyses of CLP(FD) 23 6b. cstr: whe n p ort=p ost do curr ent(ch r ono,cident, cinternal). tr e e: when p ort in [failur e,b ackT o, choic ePoint,solution] do curr ent(chr ono,no de,p o rt). 7b. newvar: when p ort=newV ariable do c u r r ent(chr ono, vident, vname). dom: when p ort in [choic ePoint,b ack T o,solution] do curr ent(chr ono,no de ,p ort,name d_vars,ful l_dom). 8b. pr op ag1 : when p ort=r e duc e do curr ent(chr ono). 9b. pr op ag2 : when p ort=awake do curr ent(chr ono). Fig. 15. Ev en t patterns used to assess the trace generation and the comm unication o v erhead The measured R driv er for pattern 5a is R driv er = 0 . 95 + 100 ns ε . F or p a t te r n 5a , the a v erage time p er ev en t tak en b y the core tracer mec hani s m and the t rac er driv er ( δ tracer + δ driv er ) can th e refore b e appro ximated to 100 ns . The R driv er o v erhead could th us b e made predictable . F or a giv en program, it is easy to automatically measure ε , the a v erage tim e of exec ution p er ev en t. F or a l ibrar y of patterns δ tracer + δ driv er can b e computed for eac h pattern. W e ha v e sho wn ab o v e that the o v erhead of the sim ultaneous searc h for dieren t patterns can b e o v er appro ximated b y the sum of all the o v erheads. O ur en vironmen t could therefore pro vide estimation m ec hanisms. When ε w ould b e to o small compared to δ tracer + δ driv er the user w ould b e w arned th a t the o v erhead ma y b ecome large. 7.6 Communic ation Overhe ad The measure of T g com ' T tracer + ∆ driv er + ∆ g com is the executio n time of the program run b y the tracer. A new set of patterns are used so t hat some ev en ts matc h the patterns, the requested attr i bu te s of the matc hed ev en ts are generated and sen t to a de generated v ersion of the m ediator: a C program th a t simply reads the trace data on its standard input. W e sho w t he result of program gol om b(8) whic h has a medi an n um b er of ev en ts and has a m edian ε . The patterns are listed i n Figure 15. P attern 6b , com p osed of t w o basic patterns, allo ws a bare searc h tree to b e constructed, as sho wn b y most debugging to ols. P attern 7b (t w o basic patterns) all o ws the displa y of 3D views of v ariable up dates as sho wn in Figure 8. P attern 8b and pattern 9b pro vide t w o dieren t execution details to decorate searc h trees. Dep ending on the to ol settings, three dieren t visual clues can b e displa y ed. One is sho wn in Figure 8, Section 3.4. T able 2 giv es the results for the ab o v e patterns and some of their com binations. All com binations co r re s p ond to existing to ols. F or example, com b i ning 6b with 8b or/and 4b allo ws a Christmas tree as sho wn in Figure 8 to b e constructed with 24 L. L angevine an d M. Duc assé Program: golom b(8) ε = 45ns T prog =1 . 73s P atterns Matc hed XML T ra ce Elapsed R driv er R gcom ev en ts size time (10 6 ) (Mb ytes) (s) 6b 0.36 21 4.50 1.03 2.6 7b 0.13 111 16.17 1.02 9.35 8b 5.04 141 33.57 1.14 19.40 9b 14.58 394 89.40 1.32 51.68 (6|7)b 0.36 124 17.47 1.04 10.09 (6|8)b 5.40 162 36.08 1.15 20.85 (6|9)b 14.94 415 92.71 1.33 53.59 (6|8|9)b 19.97 556 122.72 1.44 70.93 (6|7|8|9)b 19.97 660 136.80 1.44 79.07 default tr ac e 38.36 7,910 393.08 1.96 227.21 T able 2. Cost of the trace gene r ati on and comm unication for p rogram golom b(8) t w o dieren t parametrization. The 2 nd column giv es the n u m b er of ev en ts whic h matc h the pattern. The 3 rd column giv es the size of the r e su l ting XML trace as it is sen t to the to ol. The 4 th column giv es th e elapsed time 4 . The 5 th column giv es the ratio R driv er , rec omputed for eac h patt e rn. The 6 th column gi v es the ratio R g com = T gcom T prog . Filter e d tr ac e is mor e ecient and mor e ac cur ate than default tr ac e. The last line giv es results for t he default trace. On the one hand, the default trace con tains t wice as man y ev en ts as the trace generated b y pattern (6|7|8|9)b ; it also con tains more attributes than requested b y the pattern; as a result, its size is ten times larger and its R g com o v erhead is three times larger. On the other hand, the default trace do es not con tain all the a t tributes. In that particular case, some relev an t attr i bu te s are missing in the default trace while they are presen t in the trace generated b y pattern (6|7|8|9)b . These attributes can b e reconstructed b y the analysis mo dule, but this requires further com p utati on and memory resources. As a c ons e q ue nce, the tracer driv er approac h that w e prop ose is more e cien t than sending o v er a default trace, ev en to construct sophisticated graphical views. The accuracy and the lo w er v olume o f the trace ease its p ost-pro cessing b y the debugging to ols. A n swering queries is mor e ecient than displaying tr ac es. R g com is alw a ys m uc h larger than R driv er , from 2 . 6 to 79 . 07 in our example. Therefore, queries using 4 Here system an d user time are not sucien t b ecause t w o p ro cesses are in v olv ed. T prog has b een re-measured in the same conditions. T r ac er Driver and Dynamic A nalyses of CLP(FD) 25 patterns that drasticall y lter the trace ha v e signican tly b etter resp onse time than queries that rst displa y the trace b efore analyzing it. When debugging, programmers often kno w what they w an t to c hec k. In that case the y are able to sp eci f y queries that demand a simple answ er. In suc h a case our appr o ac h is si gnican tly b etter than systematically sending t he whole trace information to an analyzer. No ne e d to r estrict the tr ac e information a priori. Man y tracers restrict the trace information a priori in order to reduce the v olum e o f trace sen t to an analyzer. This restricts the p ossibil ities of the dy nam ic analyses without prev en ting the big size and time o v erhead as sho wn ab o v e w i th the default trace whic h do es not con tain imp ortan t information while b eing h uge. With our approac h, trace information whic h is not r e q ue s te d do es not c ost m uc h, therefore our trace mo del can aord to b e v ery ric h. This mak es it easier to add new dynamic analyses. Performanc e is c omp ar able to the state-of-the -pr actic e. R g com v a r i es from 2.6 to 79.07. T o giv e a comparison, the Mercury tracer of Somogyi and He n de r son (Somo- gyi and Henderson 1999) is regularly used b y Mercury dev e lop ers. F or exec u ti ons of size equiv alen t to those of our measuremen ts, the Mercury tracer o v erhead has b ee n measured from 2 to 15, with an a v e r ag e of 7 (Jahier and Ducassé 2002). Hence th e ratios f o r patterns 6b , 7b and 6|7b are q ui t e similar to the state-of-the-practice debuggers. The other patterns sho w an o v erhead that can discourage in teracti v e usage. Ho w ev er, these patterns are though t of more for monitoring than debugging when the in teraction do es not ha v e to b e done in real tim e. Note, furthermore, that for the measured programs, the absolute resp onse time is still on the range of t w o min utes for the w orst case. When debugging, this is still acceptable, esp ecially if one considers that in the relev an t cases the alternativ es to the uses of to ols l ik e ours are lik ely to b e m uc h w orse. Our approac h therefore allo ws to ha v e the t rac er presen t but idle b y default. When a pr o b l em is encoun t e red, simple queries can b e set to lo calize roughly the source of th e problem. Then, more costly patt e rn s can b e activ ated on smaller parts of the program. This is similar to what exp erienced programmers do. The dierence with our app roac h is that they do not ha v e to either c hange to ols, or reset the parametrization of the debugge r. 8 Related W ork Kraut (Bruegge and Hibbard 1983) imple men ts a nite state mac hine to nd se- quences of execution ev en ts that satisfy some patterns, called p ath rules . Sev eral patterns are allo w ed and they can b e enabled or disabled du ri n g the exec u ti on, us- ing a lab eling p olicy . Sp ecie d a ctions are triggered when a rule is satised but th e y are limited to some debugger primi tiv es, suc h as a message displa y or incremen ting a coun ter. The mai n in terest of this to ol is to abstract the trace and to allo w the 26 L. L angevine an d M. Duc assé easy dev elopmen t of monitors. The trace analysis is necessarily sync hronous and do es not b enet from the p o w er of a comple t e programming language. Reiss and Renieris (Reiss a n d Renieris 2001) ha v e an approac h similar to ours. They also structure their dynamic analyses in to three dieren t mo dules: 1) ex- traction of trace , 2) compaction and ltering and 3) visualization. They pro vide a n um b er of in teresting compaction f unc t i ons whic h should b e in tegrated in a further v ersion of our sys te m. They , ho w ev e r, rst dump the whole trace information in les b efore an y ltering is pro cessed. With our tracer driv er, ltering is done on the y , and Section 7 has sho wn that this is m uc h more ecie n t than rst storing in les. Their app roac h, ho w ev er, is able to deal with partially ordered execution threads; adapting our framew ork to language s with par ti ally ordered threads w ould require some tec hnic al w ork. Co ca (Ducassé 1999b) and Opium (Ducassé 1999b) pro vide a trace query mec h- anism, resp ectiv el y for C and Prolo g. This mec hanism is sy nc hronous and do es not allo w concurren t analyses. It can b e easily em ulated with our tr ac er driv er and an analyzer mediator written i n Prolog. Hy + (Consens et al. 1994) writes the trac e i n to a real relational database to query it with SQL. This is ev en slo w e r than writing t he trace simply in to a le. Ho w ev er, when on the y p e rf o r m ance is not an issue, for example for p ost mortem analysis, this is a v ery p o w erful and elegan t solution whic h is straigh tforw ard to connect to a tracer with our tracer driv er. Dalek (Olsson et al. 1990) is a p o w erful extension of gdb . It allo ws users to as- so ciate sequences of execution ev en ts to sp ecic sync hronous handlers written in a dedicated imp erativ e language. This language includes primiti v es to retrie v e addi- tional trace data and to sync hronize the execution. The managemen t of handlers is not i ncremen tal. A k ey feature of Dalek, esp ecially useful in an imp erativ e lan- guage, is the explicit queue o f e v en ts that stores the ac hiev ed exec ut i on ev en ts. The user can explicitly remo v e ev en ts fr o m this queue and add higher-le v el ev e n ts. This approac h requires an exp ensiv e storage of a part of the trace but enables b oth monitoring, debugging and prol ing of programs. In EBBA (Bates 1995), exp ected p rog r am b eha viors are mo deled a s relationships b et w een execution ev e n ts. Those mo dels are then compared to the actual b eha v- ior during execution. EBBA tries to recognize rel ev an t sequences of ev en ts and to c hec k some constrain ts ab o ut suc h sequences. A kind of automaton is built to nd instan tiations of the m o dels. The ev en ts are rst generated b y the tracer b e f ore b eing ltered according to the automata. Our approac h allo ws ltering execution ev en ts directly inside the tracer, whic h is more e cien t. Nev erth e less, EBBA recog- nizes sequences of ev en ts whereas w e lter one ev e n t at time. Our approac h co u l d b e used upstream of the sequence recognition. The incremen talit y of the ev en t patterns could b e used to adapt the relev an t ev en ts to the states of the automata. UF O (Auguston et al. 2002) oers a more p o w erful language to sp ecify patterns and monitors than EBBA . The patterns can in v olv e sev eral ev e n ts, not necessarily consecutiv e. In our framew ork, the monitors ha v e to b e implem en ted in the analyzer with a ge neral programming language. A further extension should allo w at le as t the implemen tation of monitors in the trace driv er to impro v e eciency . UF O, ho w ev er, T r ac er Driver and Dynamic A nalyses of CLP(FD) 27 do es not allo w the same exibilit y as our trace r driv er, and is he a vier to use for in teractiv e debuggi ng. So far, our framew ork applies only to a single execution and do es not easi ly scale to compare n umerous executions as is done in batc h mo de b y (Jones et al. 2002). It seems, ho w ev er, p ossible to extend our framew ork so that t w o executions can b e run in paral lel with t w o tracer dr i v ers. This w ould allo w the imple men tation of the debugging analyses of (Zeller and Hildebrandt 2002) and (Sosic and Abramson 1997) whic h com p a r e t w o executions at a giv en m omen t. F or some applications, it is imp ortan t to b e able to rewind the execution. The necessary mec hanisms are orthogonal to t he ones pr e sen ted here, and can b e merged with them. In terested readers are referred to the Mercury me c hanisms (MacLart y and Somogyi 2006) or the surv e y of (Ronsse et al. 2000). The Ilog Christmas T ree (Bracc h i et al. 2001) is built b y pro cessing an XML trace pro duced b y the debugger. This tracer is generic: it can b e sp e cialized to feed a sp ecic to ol. This sp ecializ at i on requires, ho w ev er, a go o d understanding of the solv er b eha vio r and cannot b e mo died during the execution. Moreo v er, the amoun t of data a v aila b l e at eac h ev en t is v ery limi ted compared to the full state our approac h allo ws. F or instance, the set of constr a in ts and v ariables cannot b e insp ected. A debugging library for SICStus Prolog has b een implemen ted (Ågren et al. 2002; Hanák et al. 2004). Its main qualit y is the explanati ons it pro vides ab out ev en ts that narro w domains. This h e lpful information needs a di cult and costly instru- men tation of SICStus constr ai n ts: only a few ones ha v e actually b een instrumen ted. No p erformance results are a v ailable. Some tuning of the tr a ce displa y is p ossible but the tracer is based on a c omplete storage of the trace and a p ostmortem in- v estigation: this is impractical with real-sized executions. The lazy generation of the trace our tracer driv er enables leads to the same kind of trace data in a more ecien t and prac t i cal w a y . Some C(L)P debugging to ols enable users to in teract with the exec ution states. User of Oz Explorer (Sc h ulte 1997) can act on the curren t state of the execution to driv e the searc h-tree exploration. Users of CLPGUI (F ages 2002) can add new constrain ts on a partial solution. They can recompute a former state in b oth sys- tems. Those features are helpful. Our approac h is complemen tary , it addresses the comm unication from the traced execution to the de bugging to ols. 9 Conclusion In this pap er w e ha v e presen ted a tr a cer driv er w hi c h, with limited dev elopmen t eorts, pro vides a p o w erful fron t-e nd for complex debugging and monitoring to ols based on t rac e data. W e ha v e dened an expressiv e language of ev en t patterns where relev an t ev en ts are describ ed b y logical form ulæ in v olving most of the data the tracer can access. Sp ecic primitiv es enable the retriev al of l ar g e piece s of data on dema n d and the adaptation of t he ev en t patterns to the ev olving needs of trace analyzers. Exp erimen ts for CLP(FD) ha v e sho wn that the o v erhead of the core tracer mec h- 28 L. L angevine an d M. Duc assé anisms is small, there f o r e the core tracer can b e p ermanen tly activ ated; the tracer driv er o v erhead is a cceptable; there is no o v erhead in the ltering mec hanisms when searc hi n g sim ultaneously for sev eral patterns; the tracer driv er o v erhead is predictable for giv en patterns; the tracer driv er approac h that w e prop ose is more ecien t than sendi n g o v er a default trace, ev en to construct sophisticated graphi- cal vie ws ; answ ering queries is orders of magnitude more ecien t than displa ying traces; there is no nee d to restrict the trace informatio n a priori; last but not least, the p erformance of our to ol is c omparable to the state-of-the-practice while b eing more p o w erful and more generic. T raditionall y , trace r designers decide on a static bas i s what the observ ed ev e n ts should b e. As a result, compromises regarding the amoun t of information to trace are made once for all or, at b est, b efore eac h exec ut i on. With our approac h the trace con ten ts can b e m uc h ric her b ecause only what is needed is retriev ed. H ence there is less c hance that imp ortan t i nf o r m ation is missing. The t rac er driv er o v erhead is in v ersely prop ortional to the a v erage time b et w een t w o traced ev en ts. Whereas the principles of the tracer driv er are indep enden t of the traced programming language, it is b est suited for hi gh-lev el languages, suc h as constrain t logic programming, where eac h traced execution ev e n t encompasses n umerous lo w-lev el execution steps. The curren t C(L)P en vironme n ts do not pro vide all the useful dynamic analysis to ols. They can signican tly b enet from our tracer driv er whic h enables dynamic analyses to b e in tegrated at a v ery lo w cost. A cknow le dgment The authors thank Pierre Deransart an d th eir O ADymPP aC part- ners for fruitful d iscussions, as w ell as Guillaume Arnaud for th e screenshots of his P a v ot to ol and his careful b eta-test ing of Co deine. Ludo vic Langevine is indebted to M ats Carls- son and the SICStus team at Uppsala who help ed to implemen t a preliminary tracer driv er protot yp e connected to the F DBG SICStus Prolog tracer (Ågren et al. 2002). It con t ributed to the v alid a t ion of the principles describ ed in this a rt icle. References Ågren, M. , Szeredi, T. , Beldiceanu, N. , and Carls son, M. 2002. T racing and explaining execution of clp(fd) programs. In Pr o c. of W orkshop o n L o gic Pr o gr a m ming Envir onments'02 , A . T essi er , Ed. Computer Researc h Rep ository cs.SE/02070 47. A uguston, M. , Jeffer y, C. , and Under w o od, S. 2002. A fram ew ork for automatic debugging. In Pr o c e e dings fo the 17th International Confer enc e on A utomate d Softwar e Engine ering (ASE'02) , W. Emmeric h and D. Wile, Eds. IEEE Press, 217222. Ball, T. 1999. The concept of dynamic analysis. In ESEC / S IGSOFT FSE , O. Nierstrasz and M. Lemoine, Eds. Lect ure Notes in Computer Science, v ol. 168 7. Springer, 216231 . Ba tes, P. C. 1995. Debugging heterogeneous d istributed syst ems using ev en t-based mo d els of b eha vior. A CM T r ansactions on Computer Systems 13, 1 ( F eb.), 131. Bra cchi, C. , Gefflot, C. , and P a ulin, F. 2001. Com b ining propagation information and searc h-tree visualization using opl studio. In Pr o c e e dings of WLPE'01 , A. Kusalik, Ed. Computer Researc h Rep ository cs.PL/01 11040, Cyprus, 27 39. Br uegge, B. and Hibbard, P. 1983. Generalized path expressions: A high-lev el debug- ging m e c hanism. The Journal o f Systems and Soft w a r e 3 , 265 276. Elsevier. T r ac er Driver and Dynamic A nalyses of CLP(FD) 29 Carr o, M. and Hermenegildo, M. 2000. The VIFID/TRIFID to o l . See Deransart et al. (2000), Chapter 10. Consens, M. , Hasan, M. , and Mendelzon, A. 1994. Visualizing and querying dis- tributed ev en t t r aces with Hy+. In Applic ations of Datab a ses, First I nte rnational Con- fer enc e , W. Lit win and T. Risc h, Eds. Springer, Lecture Notes in Computer Scie nce, V ol. 819, 123141. Denma t, T. , Ducassé, M. , and Ridoux, O. 2005. Data mining and cross-c hec king of execution traces. a re-in terpretation of Jones, Harrold and Stask o test information visualization. In Pr o c e e dings of the 20th I EEE/A CM Internati onal Confer enc e on A u- tomate d Softwar e Engine ering , T. Ellman and A. Zisman, Eds. A CM Press. Deransar t, P. , Hermenegildo, M. , and Maluszynski, J. , Eds. 2000. A nalysis and visualizatio n to ols f or c onstr aint pr o g r amming . Lecture Notes in Compu ter Science, v ol. 1870. S pringer-V erlag. Diaz, D. 2003. Gnu Prolog, a free Prolog compiler with constrain t solving o v er nite domains. h ttp://gprolog.sourceforge.net/ Distributed under the GNU license. Ducassé, M. 1999a. Co ca: An automated debugger for C . In Pr o c e e dings of the 21st International Confer enc e on Softwar e Engine ering . A CM P ress, 504513. Ducassé, M. 1999b. Opiu m : An extend a b le trace analyser for Prolog. The Journal of L o gic pr o g r amming 39 , 177223. Sp ecial issu e on S yn thesis, T ransform at ion a n d Analysis of Logic P rograms, A. Bossi and Y. Deville (eds). F a ges, F. 2002. Clpgui: a generic graphical user in terface for constrain t logic programming o v er nite domains. In Pr o c e e dings of WLPE'02 , A. T essier, Ed. Computer Researc h Rep ository cs.SE/0207048, Cop enhagen. Gent, I. and W alsh, T. 1999. CSPLib: a b enc hmark library for constrain ts. T ec h. rep., T ec hnical r ep ort APES-09-1999. A v ailab le from h ttp://csp lib.cs.strath.ac.uk/. A shorter v ersion app ears in the Pro ceedi ngs of C P- 99. Goualard, F . and Benhamou, F. 2000. Debugging const ra i n t programs b y store in- sp ection. See Deransart et al. (2000 ) , Chapter 11. Hanák, D. , Szeredi, T. , and Szeredi, P. 2004. FDBG, the CLP(FD) debugger library of SICStus Pr olog. In Pr o c. of Iclp '04 , B. Demo en a n d V. Lifsc hitz , Eds. P oster. LNCS 3132. Harr old, M. J. , R othermel, G. , Wu, R. , and Yi, L. 1998. An empirical in v estigation of p ro gram sp ectra. In Pr o c e e dings of th e 1998 A CM SIGPLAN-SIGSOFT workshop on Pr o gr am analysi s for softwar e to ols and e n g ine ering . A CM Press, 8390. Jahier, E. and Ducas sé, M. 2002. Generic program monitoring b y trace analysis. The ory and Pr actic e of L o gic Pr o gr a mmin g 2, 4-5 ( July-Septem b er), 611643. Jeffer y, C. and Grisw old, R. 1994. A framew ork for execution monitoring in icon. Softwar e-Pr ac tic e a n d Exp erie n c e 24, 11 (No v em b er), 10251049. Jones, J. A. and Harr old, M. J. 2005. Empirical ev aluation of the T ara n tula auto- matic fault-lo calizati o n tec hnique. In Pr o c e e dings of the 2 0th IEEE/A CM inter n a tional Confer enc e on A uto m a te d Sof twar e Engine ering . A CM Press, 273282. Jones, J. A. , Harr old, M. J. , and St ask o, J. 2002. Visualization of test in f ormation to assist fault lo calization . In Pr o c e e dings of the 24th Inter n a tional Confer enc e o n Softwar e Engine ering . A CM Press, 467477. Langevine, L. , Deransar t, P. , and Ducassé, M. 2004. A generic trace sc hema for the p ortabilit y of CP(FD) d ebugging to ols. In R e c ent advanc es in Constr aint Pr o gr amming , J. V ancza, K. Apt , F. F a ges, F. Rossi, and P . Szeredi, Eds. Sprin g er-V erlag, Lect ure Notes in Articial In telligence 3010. Langevine, L. , Ducassé, M. , and Deransar t, P. 2003. A propagation tracer for Gn u-Pro l o g: f rom formal denit ion to ecien t implemen tation. In Pr o c. of the 19t h 30 L. L angevine an d M. Duc assé Int. Conf. in L o gic Pr o gr amming , C. P alamidessi, Ed. Springer-V erlag, Lecture N ot es in Computer Science 2916. Ma cLar ty, I. and Somogyi, Z. 2006. Con trolling searc h space materialization in a prac- tical declarativ e debugger. In P ADL , P . V. Hen t enryc k, Ed. Lecture Notes in Computer Science, v ol. 3819. Springer, 3144. Ma cLar ty, I. , Somogyi, Z. , and Br o wn, M. 2005. Divide-and-query and su bterm de- p endency trac king in t he Mercury declarati v e debugger. In AADEBUG'05: Pr o c e e dings of the sixth internatio n a l symp osium on A utomate d analysis-driv en debugging . A CM Press, N ew Y ork, NY, USA, 5968. Meier, M. 1995. Debugging c o n strain t programs. In Pr o c e e dings o f the First International Confer enc e on Principles and Pr actic e of Constr aint Pr o gr amming , U. M o n tanari and F. Rossi, Eds. Lecture Notes in Computer Science, v ol. 976. Sp r i nger-V erlag, 204221. Olsson, R. , Cra wf ord, R. , and Ho, W . 1990. Dalek: A GNU, im p ro v ed programm ab le debugger. In Pr o c e e dings of the Su mmer 1990 USENIX Confer enc e: June 1115, 1990 . 221232. Reiss, S. and Renieris, M. 2001. Enco ding program executions. In Pr o c e e dings of the 23r d Internati onal Confer enc e on Softwar e Engine ering , M.-J. Harrold and W. Sc häfer, Eds. IEEE Press, 221 230. R onsse, M. , Bosschere, K. D. , and Chassin de Ker g o mmea ux, J. 2000. Execution repla y and debugging. In Pr o c e e dings of the International W orkshop on A utomate d Debugging (AADEBUG 2 000) , M. Ducassé, E d . h ttp://xxx.l a n l.go v/abs/cs.SE/0011006. Schul te, C. 1997. Oz explorer: a visual constrain t progr amming to o l . In Pr o c. of the 14th Int. Conf. on L o gic P r o gr amming , L. Naish, Ed. MIT Press, 286300. Shapir o, E. 1983. A lgorithmic Pr o gr am Debugging . MIT Press, Cam bridge, MA. ISBN 0-262-19218-7. Simonis, H. and A ggoun, A. 2000. Searc h-tree visualisation. See Deransart et al. (2000), Chapter 7. Somogyi, Z. and Henderson, F . 1999. The implemen tati o n t ec hnology of the Mer- cury debugger. In Pr o c e e dings of the T enth W orkshop o n L o gic Pr o gr amming En- vir onments . V ol. 30(4). Elevier, Electronic Notes in Theoretical Computer Science. h ttp://www.elsevier.nl/cas/tree/store/tcs/free/en tcs/store/tcs30/co v er.sub.sh t. Sosic, R. and Abramson, D. 1997. Guard: A relativ e d ebugger. Softwar e - Pr actic e and Exp erienc e 27, 2, 18 5206. Wilhelm, R. and Ma urer, D. 1995. Compiler design . A ddison-W esley . ISBN: 0-201- 42290-5. Zeller, A. and Hildebrandt, R. 2002. Simplifying and isolating failure-inducin g in put. IEEE T r ansactions on Softwar e En g ine ering 28, 2, 183200.