Database-Backed Program Analysis for Scalable Error Propagation

Transcription

1 Dtbse-Bcked Progrm Anlysis for Sclble Error Propgtion Cthrin Weiss Cindy Rubio-González University of Cliforni, Dvis Ben Liblit University of Wisconsin Mdison Abstrct Softwre is rpidly incresing in size nd complexity. Sttic nlyses must be designed to scle well if they re to be usble with relistic pplictions, but prior efforts hve often been limited by vilble memory. We propose dtbse-bcked strtegy for lrge progrm nlysis bsed on grph lgorithms, using Semntic Web dtbse to mnge representtions of the progrm under nlysis. Our pproch is pplicble to vriety of interprocedurl finite distributive subset (IFDS) dtflow problems; we focus on error propgtion s motivting exmple. Our implementtion nlyzes multi-million-line progrms quickly nd in just frction of the memory required by prior pproches. When memory lone is insufficient, our pproch flls bck on disk using severl hybrid configurtions tuned to put ll vilble resources to good use. I. Introduction As computers become more powerful, softwre pplictions continue to grow in size. For exmple, Linux is lmost seven times lrger now thn it ws twelve yers go. As consequence, prticulr ttention is plced on sclbility when designing techniques to nlyze softwre. Unfortuntely, computer resources re often limittion when nlyzing lrge code bses. The key sclbility limittion is memory. Memory usge is often correlted with the size of the code bse under nlysis. Recent ppers [1] [10] describe sclble progrm nlyses tht re pplied to lrge code bses. The lrgest progrms nlyzed in these ppers rnge in size from 474 KLOC to 8.6 MLOC. Despite the fct tht these nlyses either hve different purposes, or follow different pproches to solving similr problems, it is noteworthy tht their memory usge rnges from 808 MB to 20 GB, with few instnces running out of memory in their prticulr configurtion settings. One rrely sees nlyses of lrger code bses, or nlyses of combintions of progrms (e.g., nlyzing kernel nd user pplictions in conjunction). Presumbly, the min reson is poor sclbility. Doop [11] nd SemmleCode (developed s CodeQuest [12], [13]) use dtbse engines to query nd nlyze progrm behvior. Dtbses routinely work with more dt thn fits in memory, so dtbse-bcked progrm nlysis could potentilly brek through the memory sclbility brrier. However, prior work hs not systemticlly explored the prcticl consequences of moving nlysis from memory-only to memory-plus-disk. For exmple, Smrgdkis et l. [14] explicitly focus on Doop configurtions tht do not bring the disk hevily into ply. In this pper, we present dtbse-bcked progrm nlysis technique tht mkes good use of vilble memory while llowing very lrge nlyses to fll bck on disk. We significntly reduce the mount of memory required, thereby llowing memory-only nlyses of lrger code bses thn ws possible in prior work. For problems tht re too lrge for memory, we identify useful memory-plus-disk configurtions to optimize use of vilble resources. We demonstrte the effectiveness of our technique by implementing sttic progrm nlysis tht trcks how error codes propgte in C/C++ pplictions, nd finds instnces in which unhndled error codes re dropped [15], [16]. Figure 1 shows n exmple of dropped error in the Firefox web browser. Function DshArryToJSVl my return one of two error codes: NS_ERROR_OUT_OF_MEMORY or NS_ERROR_FAILURE. The error code is dropped on line 4 while filing to be stored in the reference prmeter error. Ignoring this filure could cuse mozdsh to remin uninitilized, leding to confirmed potentil security vulnerbility.1 Note tht, lthough the bug fix seems trivil, finding the bug nd greeing on fix ws definitely not n esy tsk. As shown in Figure 1, error-propgtion nlysis is prticulrly importnt becuse defective error propgtion hs the potentil to cuse not only security vulnerbilities, but lso silent, unrecoverble dt corruption. Furthermore, the systems potentilly ffected cn be mssive. Applying error-propgtion nlysis to such lrge code bses is n importnt gol, but one tht fces mjor sclbility chllenges. We pply our dtbse-bcked nlysis to the Linux kernel nd the Firefox web browser. Experiments show tht we cn perform nlyses with modest resources while other nlysis tools require dedicted, lrge-memory servers. Our pproch is highly configurble, llowing it to work efficiently nd sclbly cross wide rnge of dt chrcteristics. Our contributions re s follows: We show how to encode error-propgtion nlysis (Section II) s grph sturtion problem (Section III) tuned for efficient dtbse-bcked inference. We provide n efficient nd sclble implementtion of our trget nlysis using dtbse-bcked grph indexing scheme (Section IV). We explore severl dtbse configurtions representing trde-offs between vilble memory nd time to completion (Section V)

2 1 Vlue CnvsRendering::GetMozDsh(Context cx, ErrorResult& error) { 2 Vlue mozdsh; 3 4 DshArryToJSVl(CurrentStte().dsh, cx, &mozdsh); // unsved error 5 6 return mozdsh; 7 } () Originl code with n unsved error on line 4 1 Vlue CnvsRendering::GetMozDsh(Context cx, ErrorResult& error) { 2 Vlue mozdsh; 3 int temp; 4 temp = DshArryToJSVl(CurrentStte().dsh, cx, &mozdsh); 5 temp = OK; // overwritten error 6 return mozdsh; 7 } (b) Trnsformed code with n overwritten error on line 5 Fig. 1. An unsved error found in the Firefox web browser. Figure 1 is the originl code in which function DshArryToJSVl my return one of two error codes: NS_ERROR_OUT_OF_MEMORY or NS_ERROR_FAILURE. Function GetMozDsh fils to propgte the error, leding to confirmed (nd now fixed) potentil security vulnerbility. Figure 1b is the code fter progrm trnsformtions tht convert the unsved error into n overwritten error. We pply our nlysis to two lrge, rel-world code bses: the Linux kernel nd the Firefox web browser. Our technique drmticlly reduces required time nd/or memory compred to prior memory-only pproch (Section V). Section VI discusses relted work nd Section VII concludes. II. Bckground Incorrect error hndling is longstnding problem in wide vriety of domins. Idelly, whenever run-time error occurs, softwre systems should respond ccordingly. Unfortuntely, tht is often not the cse. Error-hndling code tends to be poorly understood, poorly documented, nd poorly tested [17]. Unsurprisingly, then, error-hndling code is often buggy. One of the resons is tht hndling errors is in generl difficult tsk. Exceptionl conditions must be considered during ll phses of softwre development [18], introducing interprocedurl control flow tht cn be difficult to reson bout [19] [21]. As result, error-hndling code is usully scttered cross different functions nd files, mking softwre more complex nd less relible. Modern progrmming lnguges such s Jv, C++, nd C# provide exception-hndling mechnisms. Unfortuntely, C does not hve exceptions, so C progrmmers emulte exceptions in vriety of wys. The return-code idiom is mong the most populr idioms used in lrge C progrms, including operting systems. Errors re represented s simple integer codes, where ech integer vlue represents different kind of error.2 These error codes propgte through conventionl mechnisms such s vrible ssignments nd function return vlues. Even C++ progrmmers sometimes prefer the return-code idiom over lnguge-level exceptions [22] [25]. Unfortuntely, the errorcode idiom is highly error-prone. Severl pproches hve been proposed to detect or monitor error-propgtion ptterns t run time, typiclly during controlled in-house testing with fult-injection to elicit filures [26] [34]. Other pproches use dtflow nlysis to detect bugs in the propgtion of errors in system softwre nd user pplictions [15], [16], [35]. Our cse study is prticulrly inspired by the error-propgtion nlysis of Rubio-González et l. [16], which trcks errors s they propgte through C/C++ progrms. 2 For exmple, the Linux kernel defines EIO, EAGAIN, nd ENOMEM s integers 5, 11, nd 12, respectively. These error codes correspond to I/O error, try gin, nd out of memory. Error codes re not, in generl, stndrdized cross pplictions: ech progrm or librry my define its own idiosyncrtic codes. The error-propgtion nlysis is n interprocedurl, flownd context-sensitive sttic progrm nlysis tht finds the set of error codes tht ech vrible my contin t ech given progrm point. This informtion is used to detect vriety of errorhndling relted bugs in Linux file systems tht cn potentilly cuse silent, unrecoverble dt corruption [16], [36], [37]. In prticulr, the nlysis detects unhndled errors tht re overwritten with new vlue (overwritten error), go out of scope (out-of-scope error), or re returned by function but not sved by the cller (unsved error). Figure 1 shows n exmple of n unsved error. For simplicity, the nlysis trnsforms both out-of-scope nd unsved errors into overwritten errors. Figure 1b shows how to trnsform the unsved error of Figure 1 into n overwritten error. The trnsformtion consists of two steps: 1) First, the unsved error is trnsformed into n out-of-scope error. This is chieved by introducing new temporry vrible temp on line 3. The vrible is ssigned the vlue returned by function DshArryToJSVl. Becuse function DshArryToJSVl my return n error code, the trnsformed function now contins n out-of-scope error: vrible temp goes out of scope while storing n error code. 2) Second, the out-of-scope error is trnsformed into n overwritten error. For this, n ssignment is inserted t the end of the function for ech integer locl vrible. In our exmple, only one ssignment to vrible temp is inserted on line 5. Note tht OK is specil vlue introduced by the nlysis to represent non-error vlue. After this, the trnsformed function now contins n overwritten error insted of n out-of-scope error: vrible temp contins n error tht is overwritten with the vlue OK on line 5. At the high-level, ssignment sttements (or overwritten errors) constitute the progrm points of interest for the nlysis. Internlly, the nlysis cn still distinguish between the three kinds of dropped errors, which helps provide more precise dignostic informtion. The following prgrphs describe other nlysis chrcteristics. Exchnge vribles: The nlysis introduces globl vribles referred to s exchnge vribles. Exchnge vribles re used for the purpose of vlue pssing between cllers nd cllees. There is n exchnge vrible for ech function prmeter, nd function return vlue. Cllers export rguments into the corresponding exchnge vribles, nd cllees import these exchnge vribles into its forml prmeters. Similrly, 2

3 before ssignment: x y z intr intr intr fter ssignment: x y z Fig. 2. Exmple grph frgment corresponding to y = x; cllees export their return vlue into the corresponding exchnge vrible, nd cllers import this vrible into the receiver. This process mkes vlue pssing explicit. Pointer vribles: Ech pointer vrible p is treted s two loctions p nd p, nd no pointer is ssumed to lis ny other. This is neither sound nor complete, but it hs been shown to yield useful results in bug finding. Under these conditions, pointer prmeters re equivlent to cll-by-copy-return prmeters. Pointed-to vlues re copied from the cller to the cllee just s for function prmeters. Cllee vlues re copied bck into the cller. This extr copy-bck on return is wht distinguishes pointer rguments from non-pointer rguments, becuse it llows chnges mde by the cllee to become visible to the cller. Function pointers: Indirect clls re treted s nondeterministic choice mong conservtive over-pproximtion of ll possible cllees. Specificlly, clls cross functions pointers re rewritten s switch sttements tht choose mong possible implementtions nondeterministiclly. III. Anlysis Codifiction This Section describes how the error-propgtion nlysis of Section II cn be codified s grph edge sturtion problem. Section IV will describe how this grph problem is mpped into form suitble for efficient implementtion. A. Vrible-Expnded Control Flow Grph Error-propgtion nlysis requires determining the set of error codes tht given vrible my contin t given progrm point. This constitutes n interprocedurl dtflow nlysis problem. We begin with the interprocedurl control-flow grph (CFG). Replce ech sttement node in this CFG with vector of nodes: one for ech globl vrible, locl vrible, or forml function prmeter in the progrm. If x, y, nd z re progrm vribles, we might hve three nodes representing x, y, nd z t some sttement s 1, three more representing these vribles t different sttement s 2, nd so on for ech vrible t ech progrm loction. This mkes the grph significntly lrger thn the originl, but llows us to distinguish ech vrible s vlue t ech progrm point, thereby supporting flow-sensitive nlysis. We cll this new, enlrged grph the vrible-expnded CFG. It cn be seen s specific instnce of n exploded supergrph s used in the interprocedurl finite distributive subset (IFDS) frmework of Reps et l. [38]. Suppose sttements s 1 nd s 2 were sttement nodes connected by n intrprocedurl control-flow edge in the originl CFG. In the vrible-expnded CFG, connect vrible nodes t s 1 to selected vrible nodes t s 2 to reflect possible flows of vlues s result of executing s 1. Figure 2 shows n exmple grph frgment corresponding to the ssignment y = x;. Observe tht while y is overwritten with the previous vlue of x, this ssignment hs no effect on the vlues of x or z. Edges reflecting vlue flow within single function re lbeled intr for intrprocedurl flow. At ech function cll in the originl CFG, split the cll into vector of nodes for ech vrible before the cll nd distinct vector of nodes for ech vrible fter the cll. Do not directly connect before-cll nodes to fter-cll nodes. Rther, ssign ech cll site unique identifier. At cll site i, crete interprocedurl cll edges lbeled ( i connecting ctul rguments in the cller to the corresponding forml rguments t the entry point of the cllee. Conversely, crete interprocedurl return edges lbeled ) i connecting vribles t exit points from the cllee to vribles tht my receive returned vlues in the cller. Lstly, crete node for ech error code. Error codes re immutble, so these nodes need not be replicted t ech progrm loction. Connect error code nodes to vrible nodes where pproprite to reflect flow of error codes into vribles. For exmple, y = ENOMEM; dds n edge from the ENOMEM node to the node representing y fter the ssignment. Edges from error code nodes cn be interprocedurl s well, s in foo(eagain) or return EIO. We hndle dditionl progrm fetures such s prmeter pssing in the mnner of prior work on error propgtion [16]. Refer to Section II for brief summry. B. Interprocedurlly Vlid Pths The vrible-expnded CFG reflects single-step flows of vlues from one sttement to the next. Determining which error codes flow into given vrible t given progrm point requires extending these locl flows cross multiple sttements. We re looking for interprocedurlly vlid pths obeying two criteri: Within function, vlid pth must cross sequence of intrprocedurl flow edges ( intr ). Across function cll, vlid pth must enter nd exit the cllee t the sme cll site. Tht is, ech cll edge ( i must mtch corresponding return edge ) i. Mismtched clls nd returns, such s ( 1 ) 2, re disllowed s they cnnot correspond to ny properly-nested function invoction. Pths corresponding to complete, normlly-terminting execution would begin with some ( min edge representing the cll to the progrm s min routine, nd would end with corresponding ) min edge. However, we re interested in prtil executions during which error codes re propgting from one prt of the progrm to nother. Therefore, our vlid pths my begin with prefix of unmtched return edges, representing returns from clls tht were lredy in progress when the error rose. This is clled positive flow: the cller is receiving informtion returned to it by the cllee. Likewise, our vlid pths my end with suffix of unmtched cll edges, representing clls into functions tht re still in progress upon reching the sttement of interest. This is clled negtive flow: the cller is giving informtion to the cllee. If ll clls nd returns mtch, then pth is mtched flow. Thus, n interprocedurlly vlid pth for prtil execution consists of positive-flow prefix 3

4 followed by negtive-flow suffix, with rbitrry mtched flows intermixed t ny point long the pth. C. Pth Discovery Vi Edge Sturtion Discovering interprocedurlly vlid pths proceeds bottom-up. We begin with flows lredy present in the vrible-expnded CFG. Bsed on these, we infer progressively longer pths, culminting in interprocedurlly vlid pths. We codify the inference process s suite of subgrph ptterns given in Figure 3. We sturte the grph using these ptterns: whenever ny pttern mtches ny prt of the grph, dd the corresponding green dshed edge. Repet this until no new opportunities to dd edges cn be found. Once tht fixed point is reched, the nlysis results cn be red directly out of the edges lbeled vlid. Edge sturtion for interprocedurlly vlid pths cn be formulted in mny wys. All would ultimtely led to the sme results, but different formultions cn vry drmticlly in how mny intermedite edges they dd, nd therefore in how well they scle up. We hve crefully formulted the ptterns in Figure 3 to focus edge cretion on known points of interest, voiding inferring edges tht re correct but not useful. These ptterns lso leverge our dtbse engine s efficient trnsitive closures (Section IV-D) nd fst mtching ginst prtil (source, edge, destintion) ptterns (Section IV-A). Any IFDS problem would use similr ptterns, though the specific edge lbels nd reltionships would vry. We now clrify the mening nd role of ech pttern. Figure 3, mtched-seed: We do not need to know bout every vrible t every progrm loction; only some of these re ctully of interest. Before nlysis begins, we mrk these nodes of interest with self edges lbeled seed. Trivilly seed self edge is mtched flow of length zero. This zero-length mtched flow cn then serve s bsis for inferring longer flows using other ptterns tht follow. Thus, seed edges re the seeds from which longer pths grow. Figure 3b, intr-inferred: Suppose we hve lredy discovered ny inferred flow from x to b. Additionlly, there is single step of intrprocedurl flow from to x. Put these two together nd we hve slightly longer inferred flow (of the sme kind) from to b. This figure ctully represents three ptterns, with inferred vrying over {mtched, pos, neg}. In conjunction with Figure 3, these ptterns effectively crete predominntly-bckwrd nlysis tht begins t seeds nd extends pths bckwrd to error codes. Figure 3c, cllee-mtched: Suppose we hve lredy discovered ny inferred flow from x to y, nd tht x is return point from cll i. In order to know wht reches y, we need to know wht could hve hppened in tht cll. So mrk the corresponding point just inside the cll s zero-length mtched flow to itself. Tht is not very interesting in its own right, but it serves s new strting point for further nlysis of the body of the clled function. Note tht the mtched flow inferred t is ctully independent of the ) i edge nd the x node to which tht edge returns. This is n importnt property: it mens tht whtever we lern while nlyzing the cllee will be reusble if some other flow eventully reches s well. We never need to serch for mtched flows to more thn once. This figure ctully represents three ptterns, with inferred vrying over {mtched, pos, neg}. Figure 3d, promote-return: If we hve found negtive flow tht leds up to return edge, tht return edge might eventully mtch up with cll. This possibility will be explored due to the erlier rule tht dds mtched self edge. However, it is lso possible tht this return edge will never mtch up with cll, i.e., tht this return edge is the finl step in positive flow. Discovering tht positive flow is importnt, becuse it cn eventully become vlid reching pth in conjunction with the negtive flow we strted out with. So we promote this return edge into single-step positive flow, nd possibly continue working bckwrd from there. Figure 3e, return-nonneg: Unmtched returns extend positive flows, or turn mtched flows into positive flows. This figure ctully represents two ptterns, with nonneg vrying over {mtched, pos}. Figure 3f, cll-nonpos: Unmtched clls extend negtive flows, or turn mtched flows into negtive flows. However, this should only be done when the negtive flow could potentilly be prt of vlid flow to seed. This figure ctully represents two ptterns, with nonpos vrying over {mtched, neg}. Figure 3g, hoist-justified: Hoist mtched flow from cllee to cller, but only when we lredy hve some inferred flow fter the cll to justify our interest. This figure ctully represents three ptterns, with inferred vrying over {mtched, pos, neg}. Figure 3h, vlid: A vlid reching pth is positive flow followed by negtive flow, per Section III-B. Figure 3i, promote-vlid: Alterntively, vlid reching pth cn be negtive flow only with no preceding positive flow, still ending t seed of interest. Also inferring vlid reching pth from positive flow only with no preceding negtive flow is unnecessry: the b end of such pth will lwys crry seed edge from which zero-length negtive flow cn be inferred using other rules. IV. Approch In theory, Section III revels the criticl elements needed in order to perform error-propgtion nlysis. In prctice, memory nd other resource limits present significnt sclbility chllenges. Here we discuss prcticl considertions tht must be ddressed to pply the ides of Section III to lrge, relworld code bses. Sections IV-A nd IV-B describe our diskbsed grph indexing scheme. Section IV-C describes how our selected representtion is used in the min nlysis lgorithm. We describe dditionl supporting nlyses nd optimiztions in Sections IV-D nd IV-E, while Section IV-F considers effective use of limited memory nd disk for further performnce gins. A. Hexstore: Efficient Mngement of Lrge Grphs Using the grph sturtion strtegy of Section III requires suitble dt structure to represent the vrible-expnded CFG. Unfortuntely, this grph (including inferred edges) cn esily grow too lrge to fit in memory, limiting the size of progrms tht cn be nlyzed. Dtbses, however, routinely work with dt 4

5 seed x inferred y b neg x x nonneg b intr x inferred b ) i ) i pos ) i pos mtched inferred mtched () mtched-seed (b) intr-inferred (c) cllee-mtched (d) promote-return (e) return-nonneg inferred z inferred b x ( i neg seed ( i ) i pos neg seed seed x nonpos b x mtched y vlid b neg vlid b (f) cll-nonpos (g) hoist-justified (h) vlid (i) promote-vlid Fig. 3. Inference ptterns for vlid-pths nlysis. In ech pttern, itlics represent wildcrd vlues to be filled in fter mtching the pttern, while regulr upright text represents specific vlues tht must pper s given. Solid blck rrows ( ) represent edges lredy present or inferred, while green dshed rrows ( ) represent new edges to be dded when the pttern mtches. too big to fit in memory. Semntic Web reserch in prticulr offers triple stores optimized for storing nd ccessing lrge grph dt to nd from disk. With disk-bsed representtion of the vrible-expnded CFG, vilble memory cts merely s working cche or buffer, not s limiting upper bound. Good performnce on lrge grphs depends criticlly on the indexing scheme used: we must be ble to quickly find needed informtion either on disk or in memory buffers while minimizing I/O nd stying within resonble memory limits. The pproch we use, Hexstore [39], indexes grphs six-fold, ccording to ech of the permuttions of source, destintion, nd edge lbel. For exmple, Hexstore s (source, edge, destintion) index mintins sorted, disk-bsed mp indexed by source node. Ech source node mps to sorted index of outgoing edge lbels, nd ech of these edge lbels mps to sorted set of destintion nodes for the given source node nd edge lbel. Thus with one look-up we cn quickly find ll edges for given source node. With second look-up we cn quickly find ll destintion nodes for given source node nd edge lbel. Hexstore s other indices llow similr look-ups bsed on other permuted criteri. In generl, given ny one or two fixed elements of (source, edge, destintion) tuple, Hexstore cn quickly ccess the relted remining informtion. Hexstore llows storing indices on disk [40]. Reds from this persistent structure re reltively chep, while updtes require rebuilding the entire persistent structure. Reindexing is reltively quick even for lrge numbers of edges: bout 8 minutes for 100 million edges on stndrd desktop mchine with n verge hrd drive. Doing this for every new edge is imprcticl, but btch updtes cn work well for long-running nlyses. New edges cn be held in memory until enough hve ccumulted to mke it worthwhile to puse, rebuild indices, nd then continue. A disk-bsed representtion hs other dvntges besides reducing memory requirements. The entire nlysis is nturlly persistent; it cn esily be interrupted mid-nlysis nd resumed lter, even on different mchine. Distributed nlysis is lso strightforwrd: multiple mchines cn trivilly shre the sme disk-bsed representtion of the initil vrible-exploded CFG, with ech mchine exploring different pths in prllel. Pooling discovered edges would require cross-mchine coordintion. However, the idempotent nd monotonic nture of edge sturtion mkes this esier to mnge. For exmple, we lwys hve the option to redundntly discover edges tht hve lredy been discovered elsewhere. This lets us reduce or eliminte cross-mchine communiction in exchnge for extr locl work. B. Index Optimiztions It is convenient to refer to grph nodes by unique nmes. We use nmes of the form function.loction vrible to refer to the vlue of given vrible t prticulr numbered loction of given function. Loction numbers re derived from simple intrprocedurl numbering of CFG nodes. Locl vribles nmes re systemticlly renmed to be globlly unique. In prctice, these nmes re interned nd mpped into unique ID numbers suitble for use s index offsets. Unfortuntely, the sheer number of such unique nmes would require n uncceptbly lrge string intern tble. To our knowledge, this problem hs not previously risen in populr Semntic Web dt sets. Reltive to those grphs, our dt set contins much lrger number of nodes tht re much less densely connected: most of our nodes hve only one incoming nd one outgoing edge. We optimize the string intern pool nd dt indices by treting function nmes s nmespces. Loction numbers nd vribles re tuples in those nmespces. Thus, rther thn interning complete function.loction vrible string, we insted intern nd ssign ID numbers to just the function nd vrible nmes. We then combine these with the loction (lredy numericl) to form unique triple of numbers. This triple cn then be used s the key to look up the vlue of given vrible t given loction in given function in vrious Hexstore indices. 5

6 C. Grph Sturtion The min nlysis itertes over the set of ll ssignments, fter pplying the progrm trnsformtions described in Section II. For ech of these ssignments, we perform two grph sturtions s described in Section III: one determines the new vlue of the vrible fter the ssignment, while the other determines the previous vlue of the sme vrible before the ssignment. We refer to this pir of sturtions s one nlysis instnce. During ech nlysis instnce we mintin work list with recently discovered edges so tht we only look for new pttern mtches where new discoveries were mde. After ech instnce completes, we print its results for dignostic purposes, then continue to the next ssignment. In prctice, vribles re often overwritten by constnts. In this cse, sturtion to determine the vrible s new vlue completes within one step. Sturtion to find the old vlue commonly tkes much longer. The min nlysis opertes on grph representtion with implicit identity edges. Implicit flows re mterilized s needed to mtch inference ptterns from Figure 3, but re never persistently stored in memory or on disk.3 New edges inferred during sturtion re lwys fully explicit, nd ultimtely comprise the bulk of the sturted grph s shown in Tble I. D. Globl Vrible Bypss Assignments to globl vribles re rre: most globl vribles flow unchnged through nerly ll functions except for the few plces where one or nother is explicitly overwritten. If sturtion leds through mny function clls with mny edges to trverse, we my dd vst number of edges without receiving ny new informtion. However, if we know in dvnce tht certin grph regions do not modify certin globl vribles, we cn bypss those res entirely during sturtion. By voiding this unnecessry work, we cn reduce both time nd memory requirements while preserving correctness. To chieve this, we use severl pre-nlyses to determine which functions modify which globl vribles. One intrprocedurl nlysis determines which globl vribles my or must be modified directly by ech function. A second intrprocedurl nlysis determines which functions my or must be clled directly from within ech function. During grph sturtion, our nlysis monitors which specific vrible corresponds to given inferred edge. When sturtion could trverse into clled function (Figures 3c to 3e), we consider whether the resulting edge corresponds to globl vrible tht must never be chnged during tht cll. This requires computing n interprocedurl trnsitive closure cross the intrprocedurl my/must fcts recorded erlier. Hexstore s indices re idelly suited to computing trnsitive closures such s these, using number of queries liner in the size of the result set [39]. Hexstore lso hs the dvntge of being ble to compute this informtion on demnd when needed by the sturtion nlysis. Intermedite inferences re memoized for possible reuse during lter grph sturtion itertions. 3 This pproch is nlogous to video plyer tht decompresses nd displys video frmes on-the-fly without ever storing the entire decompressed strem. If we determine tht the globl vrible in question would not be modified during the cll, then we bypss the cll entirely. We do not descend into the cllee s suggested by Figures 3c to 3e. Insted, we bridge the globl vrible s vlue cross the cll s n inferred identity flow. The effect is similr to tht of the hoist-justified pttern in Figure 3g, but without spending time nd memory to find mtched x Ñ y flow cross the cllee. E. Unrechble Code After Infinite Loops Linux intentionlly contins numerous infinite loops immeditely fter code tht detects ftl errors. Without treting these crefully, our predominntly-bckwrd nlysis might discover extr flows of vlues originting in code tht could never ctully run. To exclude these, we impose n extr rechbility check whenever sturtion discovers n ssignment from constnt to vrible. The rechbility check determines whether the ssignment itself cn be reched from the entry of the contining function. This check is performed on-demnd within our nlysis. We check intrprocedurlly only: we do not ttempt to filter out unrechble code tht follows cll to non-returning function. However, this simple intrprocedurl check proves sufficient in prctice. F. Memory nd Disk Mngement Our nlysis tool is very flexible in how it uses memory nd disk storge. We cn leve the initil grph in memory while keeping inferred edges in memory only up to certin number. After tht we cn discrd inferred edges (possibly rediscovering them lter) or insted dd them to persistent disk storge. As described in Section IV-A, writing ech discovered edge to disk one-by-one is prohibitively slow. Btched updtes, however, re quite prcticl. Another option is to leve the initil grph persistently on disk nd to keep some or ll discovered edges in memory. Intuitively, while the nlysis cn cter to lmost rbitrry memory constrints, the more dt tht cn be mnged in memory the fster the nlysis runs. V. Experimentl Evlution We hve conducted severl experiments to evlute the usefulness of our dtbse-bcked pproch. We introduce the benchmrks nd hrdwre configurtion used for our experiments in Section V-A. Section V-B discusses correctness with respect to reference implementtion. The reminder of this Section presents our experiments with different nlysis configurtions nd vrying memory usge constrints. Our first experimentl setup (Section V-C) compres the performnce of the ll-in-memory configurtion of our tool to the in-memory error-propgtion nlysis of Rubio-González et l. [16]. Our second experiment (Section V-D) demonstrtes n optimized configurtion strtegy for progrms whose initil edges fit esily in memory, but whose mny inferred edges must periodiclly be flushed to disk. Lstly (Section V-E), we introduce complementry configurtion for progrms with very lrge initil grphs, but reltively few inferred edges. 6

7 Progrm TABLE I Sizes of progrms nlyzed Edges Lines of code Assignments Initil Inferred Ext3 175,631 15, ,699 4,582,498 ReiserFS 186,334 13, ,234 4,527,496 Linux 1,144, ,784 3,316,392 1,368,826,792 Linux* 1,144, ,783 3,316,391 1,269,389,507 Firefox 3,026,254 68,653 10,636,371 13,045,589 A. Benchmrks nd Hrdwre Configurtion We evluted our implementtion on suite of benchmrks of vrying size nd complexity. Our Ext3 nd ReiserFS benchmrks re prts of the Linux operting system kernel tht implement specific file systems. We include these reltively smll exmples becuse nlysis of error mngement in file system code ws the min focus of prior work in this re. Our Linux nd Linux* benchmrks represent much lrger portion of the Linux kernel. These two differ only in tht the Linux* benchmrk excludes single ssignment tht consistently required n unusully long time to nlyze. This ssignment ppers deep within widely-used memory mngement module; its pre-ssignment vlue cn come from myrid other loctions throughout the kernel. As it hppens, nlysis ultimtely showed tht this specific ssignment does not constitute n error-propgtion bug. The incrementllyreduced Linux* benchmrk is prcticl nlysis trget if one is willing to skip single difficult (but ultimtely nonbuggy) ssignment.4 The full Linux benchmrk shows expected performnce if everything must be checked without even single exception. These four Linux-derived benchmrks re written in C. Of course, error-propgtion nlysis is lso importnt beyond Linux nd C. Our Firefox benchmrk is the complete source code to the open-source web browser. Firefox is written in C++, but uses the return-code idiom insted of exceptions. Tble I summrizes the size nd complexity of our dt sets, mesured in vrious wys. The nture of this complexity is very different for the Linux nd Firefox benchmrks. Firefox hs roughly equl numbers of initil nd inferred edges, mening tht the initil grph ccounts for significnt frction of Firefox s totl memory needs. By contrst, Linux s initil grph is one third the size, but hs twice s mny ssignments, nd nlysis of these infers one hundred times s mny edges. Thus, nlyzing Linux puts much greter burden on efficient mngement of inferred edges. This lso suggests tht flows in Linux re significntly longer nd more complex thn those in Firefox. Experiments were run on one 2.67 GHz CPU of 12-wy Intel Xeon desktop worksttion, with 24 GB of RAM, 8 GB of swp spce, nd commodity 7,200 RPM SATA hrd drive, running Red Ht Enterprise Linux 6.3. In Tbles II, IV nd V, 4 Outliers such s this problemtic ssignment stnd out esily in our nlysis logs. Furthermore, nlyses re disk-bcked nd sved per ssignment. Thus, one cn esily stop, recognize nd exclude n outlier, then resume without it. RAM (GB) columns refer to the pek memory used t ny moment during the entire nlysis of given benchmrk. B. Implementtion nd Correctness We offer two front ends for converting source code into grph form for nlysis. First, we hve dpted CIL-bsed [41] front end used in prior work by dding the intrprocedurl my/must nlyses described in Section IV-D. CIL hndles C (but not C++), including non-stndrd C extensions used in the Linux kernel. Second, we hve developed n entirely new front end derived from Clng nd LLVM [42] [44]. Custom LLVM psses implement the my/must nlyses nd grph genertion. Clng hndles both C nd C++, but not some C extensions used by Linux [45]. We use the CIL-bsed front end for ll Linux-derived benchmrks, nd the LLVM-bsed front end for Firefox. Our gol is to perfectly replicte the nlysis results of prior error-propgtion work while drmticlly reducing memory requirements nd thereby improving sclbility. To provide bsis for comprison, we rern ll experiments from scrtch using reference implementtion provided by Rubio-González et l. [16]. This implementtion trets error propgtion s pth problem over weighted pushdown systems. It uses the WALi weighted pushdown system librry [46] version 3.4 to compute meet-over-ll-pths solutions before nd fter ech ssignment. WALi is generl frmework tht must be instntited using dt structures selected specificlly for the problem t hnd. The WALi implementtion of error-propgtion nlysis represents trnsfer functions (lso referred to s weights) using binry decision digrms (BDDs) [47] s implemented by the BuDDy BDD librry [48] version 2.4, crefully hnd-tuned for performnce on this problem. In the reminder of this Section, we refer to this reference implementtion s the WALi-bsed nlysis or simply WALi. We refer to our dtbse-bcked pproch s the Hexstore-bsed nlysis or simply Hexstore. The reminder of this Section focuses on evluting performnce nd sclbility. However, we hve lso crefully checked the correctness of the nlysis results in ll reported experiments, tking the WALi-bsed nlysis s reference. Our Hexstorebsed nlysis results exctly gree with those of the WALibsed nlysis t ech of the 338,320 ssignments cross ll five of our benchmrks. The only difference observed between the two implementtions consists of 1,331 Firefox ssignments tht Hexstore reports but WALi does not. We hve mnully inspected 824 out of these 1,331 ssignments. We found tht ll involve synthetic ssignments introduced t the end of functions to cler locl vribles tht re bout to go out of scope. Most of these locl vribles, in turn, re temporry vribles introduced by our front end. The dditionl ssignments missed by WALi, then, predominntly rise s side effects of internl representtions nd re not significnt prcticl concern. We believe these re ctully unrechble code, such s functions never clled from the min entry point. Our Hexstore-bsed nlysis works bckwrd, stopping once it reches constnt such s EIO. Unlike WALi, it does not try to prove tht the originting constnt ssignment is itself rechble. This cn cuse Hexstore to report results for 7

8 TABLE II Performnce of in-memory nlyses. - mrks WALi nlyses tht require more thn 24 GB of RAM plus 8 GB of swp spce. RAM (GB) Time (minutes) Progrm WALi Hexstore WALi Hexstore Ext ReiserFS Linux Linux* Firefox unrechble ssignments tht WALi s forwrd nlysis would not report. C. In-Memory Only A dtbse-bcked pproch cn potentilly fll bck on disk if dt grows too lrge for memory. To estblish bseline for comprison, we first experimented with Hexstore configurtion tht is strictly memory-bsed. We held ll indices representing the initil grphs in memory. We lso held inferred edges in memory, but checked how mny we hd ccumulted by the end of ech nlysis instnce (i.e., fter nlyzing ech ssignment). If we hd more thn two million, then we purged ll inferred edges from memory nd strted fresh for the next ssignment. Keeping inferred edges round lets us void some redundnt work, but mnging lrge dt structures dds overhed. Empiriclly, we found tht discrding fter two million edges ws good blnce. Unlike WALi, Hexstore ws designed with disk in mind nd is not necessrily optimized for memory-only performnce. We therefore expected tht the WALi-bsed nlysis would be significntly fster thn memory-only configurtion of the Hexstore-bsed nlysis. Tble II shows our results, compring both time nd memory required to complete ech nlysis. Contrry to our expecttions, Hexstore outperformed WALi on ll counts. For the smller Ext3 nd ReiserFS benchmrks, Hexstore is nerly s fst s WALi nd uses fr less memory. We ttribute Hexstore s superior performnce to severl fctors. As mentioned in Section IV-D, Hexstore s indices llow it to compute trnsitive closures very efficiently. These indices re lso very compct, with the lst level of ech stored s denselypcked, cche-friendly, sorted vector. Less memory lso mens less time spent llocting, filling, nd mnging tht memory. Hexstore succeeded on ll three lrge benchmrks where WALi filed outright due to memory exhustion. For the ske of completeness, we lso rn the WALi nlyses on lrge, dedicted server not vilble to most developers. WALi required 39 GB of RAM to nlyze Firefox. In theory, WALi would require 22 GB to nlyze Linux or Linux*. In prctice, memory pressure from the operting system nd other processes doomed the ttempt on our developer-grde worksttion: the WALi nlysis rn for severl hours, swpped hevily, nd ws eventully killed by the operting system when both RAM nd swp were depleted. Even if mple swp spce were vilble, common wisdom holds tht dtbse-mnged I/O outperforms TABLE III Comprison of in-memory nlysis times for lrge benchmrks. Reltive times re the rtio of Hexstore to WALi. Absolute (minutes) Progrm WALi Hexstore Reltive Linux Linux* Firefox generic OS swpping [49]. Thus, swpping lone is unlikely to solve the memory sclbility brrier. The lrge server needed for WALi hs fster CPUs (3.07 GHz) thn the humble desktop described in Section V-A nd used for Tble II. Yet Hexstore completes the lrge nlyses drmticlly fster, s shown in Tble III. Hexstore uses just 40% to 56% s much time s WALi requires for the lrge benchmrks.5 D. Optimized Index Mngement for Mny Inferred Edges Per Tble II, nlyzing Linux entirely in memory required 11 GB of RAM. This significntly improves upon WALi, for which 24 GB of RAM plus 8 GB of swp ws insufficient. However, we wished to reduce memory consumption even further, to mke nlysis on common desktop computers fesible. As we described in Section V-A, the mjority of memory needed to nlyze Linux comes from the inferred edges. For this experimentl setup we therefore mintined the reltively compct initil index in memory s well s some (but not ll) inferred edges. We discrded inferred edges between nlysis instnces once more thn two million hd ccumulted, using the threshold described in Section V-C. Since we needed to llow this threshold to be exceeded during n nlysis instnce, we introduced second threshold: the flush-to-disk threshold. If the flush-to-disk threshold ws exceeded t ny point during sturtion, ll inferred edges indices were immeditely flushed to disk, ll on-disk Hexstore indices were rebuilt, nd the inmemory index representtion reset. Once n index ws flushed to disk, newly-inferred edges were mintined in memory gin until the flush-to-disk threshold ws exceeded, nd so on. Therefore, inferred edges hve to be retrieved from both the in-memory indices, s well s from disk. Disk is slower thn memory, of course. It is therefore crucil to choose the flush-todisk threshold crefully: we must not exceed memory constrints, but lso should not wste time rebuilding the persistent indices too often. This setup is prticulrly beneficil for dt sets where individul nlysis instnces discover too mny inferred edges to fit comfortbly into memory. For this setup we expected to see n upper memory consumption bound not to be exceeded, but more nlysis time required compred to in-memory only nlyses. For Firefox it did not mke sense to rise the flush-to-disk threshold bove 1,000,000, since no Firefox nlysis instnce ever infers more 5 All times in Tble III were mesured using the sme lrge, dedicted server with 3.07 GHz CPUs; ll other experimentl results in this pper used the slower 2.67 GHz CPUs of our desktop worksttion. Thus, the Hexstore nlysis times in Tble III re consistently slightly smller thn corresponding times in Tble II. 8

9 TABLE IV Linux nlysis performnce when flushing excessive inferred edges to disk. mens never flush to disk. Progrm Flush-to-disk threshold RAM (GB) Time (minutes) Linux Linux 20,000, , Linux 10,000, , Linux* Linux* 10,000, thn 1,000,000 edges. However, Linux contins 99,437,285 edges for one prticulr nlysis instnce. In this cse n pproprite flush-to-disk threshold might significntly reduce memory consumption. Tble IV presents the results for this experiment. Anlyzing Linux with flush-to-disk threshold of 20 million edges cuts memory requirements by 13% in exchnge for tripling nlysis time. Decresing the flush-to-disk threshold to 10 million does not further reduce pek memory; in fct, memory requirements grow slightly. This lower threshold lso increses nlysis time by 47%, demonstrting tht excessive flushing cn be counterproductive. Some memory overhed is required to merge dt ccessed from disk s well s for recording interprocedurl my/must fcts computed on demnd. This collection of fcts my grow firly lrge for lrge numbers of functions nd globl vribles. This is why flushing t 10 million edges does not hlve memory consumption reltive to flushing t 20 million edges. We rn Linux* only with threshold of 10 million edges: no single nlysis instnce infers more thn 15 million edges, so threshold of 20 million edges would be equivlent to no threshold t ll. We found flushing t 10 million edges incresed nlysis time without reducing memory consumption. In fct, 9.57 GB of memory seems to be lower bound for both Linux nd Linux*. We ttribute this to the ccumultion of my/must fcts tht re never discrded from memory. E. Optimized Index Mngement for Mny Initil Edges The initil grph is used frequently during nlysis, so keeping its indices in memory improves performnce significntly. Unfortuntely, this my simply be impossible if the initil grph is too lrge. However, while Hexstore mintins six indices (per Section IV-A), not ll re used eqully often. Our nlysis works predominntly bckwrds, so the most hevily-used index is tht which mps from destintion nodes to edge lbels to source nodes: we cll this the DES index. It my mke sense to mintin only the initil grph s DES index in memory nd ccess ll other initil-grph indices from disk. This leves more memory vilble for storing indices over inferred edges. This cn id in nlyzing dt sets tht hve lrge initil grph but tht infer only moderte number of edges during ech nlysis instnce. Our Firefox benchmrk is one such exmple. Tble V shows tht mintining only the initil DES index nd inferred edges in memory reduces memory consumption by 45% when nlyzing Firefox. This is understndble given TABLE V Firefox nlysis performnce for different initil index mngement strtegies Strtegy RAM (GB) Time (minutes) only initil DES in RAM ll initil indices in RAM tht the initil edges constitute 43% of Firefox s entire grph dt. Mintining the frequently-ccessed DES index in memory llows the nlysis to complete within resonble time-frme of slightly less thn two hours. If ll indices were ccessed from disk, nlysis would tke nerly 24 hours. These results re prticulrly striking considering tht the WALi-bsed pproch required over 39 GB of RAM to perform the sme nlysis. With this configurtion we cn nlyze Firefox on contemporry lptop computer within resonble time. For exmple, t the time of this writing, the best-selling lptop on Amzon.com costs $249 nd comes with 4 GB of RAM [50]. F. Hexstore Configurtion Guidelines Hexstore is very flexible. It is to be expected tht proper tuning is necessry to chieve optiml performnce for dt sets of this size. Even commercil dtbses require fir mount of tuning in order to perform well. To chieve best performnce results using our Hexstore-bsed nlysis, we recommend dhering to the following configurtion guidelines. A purely in-memory configurtion is resonble strting point. We recommend trying this first, especilly since this configurtion is fstest. Hexstore s more efficient representtion mens tht mny problems tht did not fit in memory before my now fit with no need for secondry storge. If memory must be conserved, though, the first priority is to keep the most hevily-used indices in memory. For our predominntly-bckwrd nlysis, the top priority is the DES index tht mps destintions to edges to sources. Any remining memory should be devoted first to other indices representing the initil grph, nd then to inferred edges, with periodic discrding or flushing to disk s needed to keep within llotted memory bounds. We recommend pplying the configurtions in the described order to find dt-set-optiml setup. VI. Relted Work ) Sclble Progrm Anlysis: Modulr sttic progrm nlysis [51] [54] hs been proposed to reduce nlysis running time nd memory cost. The ide is to nlyze prts (e.g., functions) of very lrge progrms seprtely nd then compose the nlyses of these progrm prts to obtin informtion on the whole progrm. One dvntge of this pproch is tht the process my be prllelizble, depending on the interctions between the different prts of the progrm. Another pproch is to use sprse nlysis techniques to improve sclbility [4], [55] [57]. The key ide is tht for given progrm nlysis, mny prts of the progrm my not be relevnt. Excluding irrelevnt prts of the progrm effectively shrinks the nlysis problem. 9

10 Our technique is complementry to these pproches, nd could be combined with them to improve sclbility even further. b) Dtlog for Progrm Anlysis: The IFDS style of inferring new fcts from old is closely relted to bottom-up evlution of Dtlog progrms. The inference ptterns in Figure 3 could be recst s Dtlog inference rules, s cn wide vriety of other progrm nlysis problems [11] [14], [58] [64]. Doop encodes Jv points-to nlyses in dilect of Dtlog for evlution on the commercil LogicBlox dtbse engine [11]. Direct comprison between our pproch nd Doop is not meningful, s the two perform different nlyses on different source lnguges. Insted, one might reimplement our pproch using LogicBlox s Dtlog dilect nd engine, or conversely implement disk-bcked, LogicBlox-comptible Dtlog engine top Hexstore. SemmleCode uses nother Dtlog dilect to encode vriety of progrm queries. These re trnslted into SQL nd executed on ny reltionl dtbse [12], [13]. However, prior Semntic Web reserch suggests tht triple stores outperform reltionl dtbses for certin grph trversl tsks, such s trnsitive closure. This is due to the use of highly-optimized indices tht significntly reduce the number of expensive joins [39], [65]. Reps [66] described how to use the mgic-sets trnsformtion for logic progrms [67] [69] to convert exhustive dtflow nlyses into demnd-driven nlogues. This method lone is not sufficient to produce our inference ptterns from nïve, exhustive formultion. However, this nd other optimiztions from the logic-progrmming nd deductive-dtbse communities could certinly simplify prts of tht process, mking it esier to formulte new nlyses for extreme sclbility. c) Lrge Grph Dt nd the Semntic Web: The Semntic Web community ctively encourges exploring new wys to mnge nd reson over lrge grph dt. One exmple is the Billion Triple Chllenge held nnully in conjunction with the Interntionl Semntic Web Conference (ISWC) [70]. Prticipnts re provided with dt set contining Semntic Web grph with one billion edges nd try to come up with new pplictions working with this dt. Another Semntic Web trend is to put Semntic Web technologies into ppliction context, thereby providing new problem-solving methods to other res. For exmple, the Workshop on Semntic Web Enbled Softwre Engineering (SWESE) ws creted to improve softwre development ctivities by pplying Semntic Web technologies. Semntic Web inference nturlly requires computing trnsitive closures of reltions. Keivnloo nd Rilling [71] exploited inference engines to improve source code clone detection, but did not focus on single-instnce sclbility. Motivted by the need for web-scle dt mngement, we hve seen some progress on grph-optimized index structures nd dtbse systems [39], [65], [72], [73]. However, in recent yers reserch ctivity hs shifted from improving singleinstnce Semntic Web dt mngement to leverging cloud services nd offloding sclbility concerns to distributed storge nd compute systems [74], [75]. These developments bode well for long-term future sclbility of dtbse-bcked progrm nlyses: while we hve lredy reduced single-mchine resource needs, distributing progrm nlysis into the cloud will llow even greter leps of sclbility. VII. Conclusion As softwre grows in size nd complexity, min memory imposes restrictions in the sclbility of progrm nlyses. Fortuntely, the dtbse community smshed through the memory brrier long go; modern Semntic Web dtbse cn represent billions of reltions (edges) mong entities (nodes) using tunble mix of min memory nd secondry disk storge. This suggests wy for sttic progrm nlyses to brek through the memory brrier s well. We hve presented reformultion of error-propgtion nlysis s grph sturtion problem in the style of Reps et l. s IFDS frmework. Our inference ptterns re crefully designed to crete demnd-driven, predominntlybckwrd nlysis tht voids wsted effort wherever possible. To mnge the lrge grphs needed for this nlysis, we hve dpted Hexstore, Semntic Web dtbse. Hexstore is especilly well-suited to efficiently storing, querying, nd trnsitively-closing millions or even billions of relted entities. Hexstore cn be configured to use flexible mixture of memory nd disk, llowing us to solve error-propgtion nlyses in frction of the time nd/or memory required by prior work. Even when using no disk t ll, our Hexstore-bsed nlyses of lrge progrms finish 44% to 60% fster nd use 50% to 88% less memory. Incorporting disk storge llows further memory svings in exchnge for longer nlysis times. Our dtbsebcked strtegy, configured to use both memory nd disk, cn nlyze over one million lines of Linux* in seven hours nd under 10 GB of RAM: very resonble lloction for overnight processing on ny decently-equipped developer worksttion. Using prior pproches, Firefox s three million lines of code required twelve minutes, 39 GB of RAM, nd dedicted server to hndle the worklod. Our dtbse-bcked pproch requires something closer to lptop: it completes in eight minutes nd less thn 5 GB of RAM, or cn even be restricted to just 2.6 GB of RAM if one hs two hours to spre. Using the configurtion guidelines in Section V-F, developers equipped with our Hexstore-bsed, dtbse-bcked nlysis engine cn continue to scle importnt progrm nlyses up to meet the demnds of lrge softwre tody nd into the future. Acknowledgment We thnk the nonymous reviewers for their invluble feedbck. This reserch ws supported in prt by NSF grnts CCF , , , , nd ; DoE grnt DE-SC ; DARPA subcontrct R18682; nd gifts from Orcle nd Mozill. Opinions, findings, conclusions, or recommendtions expressed herein re those of the uthors nd do not necessrily reflect the views of the sponsors. The first nd third uthors re deeply grteful to the orgnizers of Dgstuhl Seminr 07491, without whose kind invittions we likely would hve never met, mrried, or written this pper. 10