OSD: A Source Level Bug Localization Technique Incorporating Control Flow and State Information in Object Oriented Program

OSD: A Sou r ce Le v e l Bug Loc a l iz at io n Te ch ni q ue In co rp or at in g Co n tr ol F l ow an d St a t e In fo r ma ti o n i n Obj ec t O ri en te d Pr og ra m Partha Pratim Ray IEEE Student Member Cooch Behar,West Beng al, India parthapratimray@hotmail.com Abstract —Bug l o c a l i z a t i o n i n object oriented program h a s always been an important iss ue i n s ofteware e ngineering. In this paper , I pr opose a sour ce lev el b u g l o c a l i z a t i o n technique fo r object oriented embedd ed pr og ra ms . My prop osed technique, presents th e idea of debugging an obj ect oriented program i n class level, i ncorp orating the object st ate inf ormation into the C la s s Depende nce G r a p h ( ClDG). Giv e n a pro gram (h a vi ng buggy statement) and an input that fails and others pass, my appro ach uses concrete as well as sym bolic execution to synthesize the passing inputs t hat mar ginally from the failing input in their contr ol flow b eha vior . A comparison of t he ex ecution t races of the fai ling i nput and t he passing i nput prov ides necess ary clues t o the root-cause of the failure. A state trace difference, regard ing t he res pecti ve n ode s of the ClDG is obtaine d, w hich leads to detect the bug in the pro gram. I . I N T R O D U C T I O N From the last few years embedd ed systems have established itself as un avoidable criteria in h uman society . Due to its l o w c o d e s i z e a n d l e ss c o m p l e x i t y e mbedded sys tems are being implemented i n the most sophisticated and critica l applications. W ith this advent of ha v oc implication of em bedded sy ste ms, the whole science co mmunity is now moving tow ards object oriented metho ds to fulfill the excessiv e nee d o f these s ystems. The power of handl ing comp lexity is the ad ded adv antage to the object oriented techno logies t hat enable the m to compete the other traditio nal tec hniques like as proce du ral approach. Debugging denotes the process of detecti ng root causes o f unexpected observable be havior in progra ms ( such as a pr o- gram crash, a n unexpected ou tput value bei ng p roduced or an assertion violatio n). Debugging p rogram errors is a dif fi cult process, and often takes a significant fraction o f the ti me i n the program dev elop ment stage. Even today , debuggi ng remains much o f a man ual activity , w ith t he ac tual deb uggin g time dependent on the size and complexity of t he program being debugged, the nature o f mani festation of t he bug a nd the level of f amiliarity and expertise of t he p rogrammer . The sta ndar d practice of debugging till date in t he software commun ity is to manually inspect the execution trace ex hibiting the bug inside a debugger and try and locate the error cause(s) from an observed error . In the past decade, t here have been se veral attempts to automate the debuggin g activ ity b y full y a uto mated / semi- automated formal analysis of the pr ogram a nd/or the failed execution trace for softw are pro grams. These methods, in sp ite of rich theoretical foundation s and pr omising a utomated bu g finding capabili ties, ha ve foun d a low degree of acceptance and penetration in the research and ind ustrial com munity t ill d a te. The main c hallenge is to d evelop a scalable sol ution that can handle so ftwares of sizeable c omplexity and p in-po int the r oot cause(s) of a n o bserved error with a high level of acc uracy . Each so ftware needs to under go a very crucial stage o f its life cycle-- debugging process. Whene ver a progra m behaves un expectedly thus prod ucing wrong o utput is liable to be called a b uggy p rogram. I n e ff ect to remove the bug from t he pro gram t he debugging methodolo gy sho uld be ver y stable one. Though di fferent techniques ar e already av aila ble to debug a n object oriented progra m, they all are not very suitable for the targeted pro blem, such as h aving a pro minen t state chart i n form of UM L. In this type of cases I need to imply a new technique that add s object state i nformation of the class bei ng executed, into the ClDG. This helps i n knowing the ro ot cau se o f t he bug, introd uced in the pro gram under execution. The Class Dependence Graph (ClDG) represents the contr ol and data depende ncies within a class [1]. For a given class, the ClDG co nsists o f a set o f p r ogram dep endence graphs (PDGs) [2] with addit ional ed ges to represent inter-proced ural control a nd d ata d ep e nd en ce s . A s tat e ment i n a p ro ce d ur e is represented by a s t a t e m e n t vertex . Control a nd d ata dependences between program statements ar e represented by contr ol dependence and data dependence ed ges, respectively . In this paper I first take a b u ggy obj ect or iented pro gram and generate a state c hart UML dia gram a nd ClDG. After the models are gener ated I input so me test cases i nto the buggy program, that results a fail and pass traces. T hen one of the pass cases i s selected t he match class depe ndence flow to the failed one. T his r esults in obj ect state comparison between t he pair of pass and fail cases. Hence produci ng the bug rep ort telling the position of bug i nside the buggy pro gram. This pap er is organized as follows: Sectio n I I presents rela ted w ork. Sectio n I I I presents an ov erview of my approach. Section IV presents detailed methodolo gy , while Section V ends with concl usion. I I . R E L AT E D W O R K Many testing tec hnique has been alread y proposed in literat ure for testing in traditio nal programs [4]. Lit era ture [7] tells about the selection of regression tests in obj ect o riented programs. [8] i ndentifies t he test coverag e requirements f o r modified softwares. In [3 ], a model based regression test selecti on methodolo gy ha s been presented. E xisting model-ba sed approaches for traditional pr ograms [9] construct graphical models based solely o n source code analysis of the programs. [1 2] proposes real time sof tware debuggin g technique. [13] tells about exception handling in respect to testing of software. [14] als o tel ls some improvement on exception hand ling in testing area. [16] tells about t he sta te chart based object or iented integrated testing. I n [17] dif ferent aspects of testi ng and debuggi ng has been pr esented well. Different search algorithms fo r regression test cases has b een proposed in [18]. I I I . O V ERV I E W O F O S D A P P RO A C H I ha ve na med my techniq ue O bject S tate-based Debugging for object o riented progra m (OSD). M y tec hnique is essentia lly based on first constr ucting mo dels for buggy pro gram that is state chart and ClDG. Then state tr ansition table i s cr eated according to the state c hart. H ere one thing i s to be noted that ClDG is incorporated with the state chart. That means each node of ClDG is accomp anied w ith a state (state of o bject of same class). Then a test suite t 1 ,...,t i ,...t j ,...t k , is applied as input int o the buggy program. This results i n so me pass and some fail ca ses. Suppose the set o f pass cases is t 1 ,... ,t j- 1 ,t j+1 ,...,t k and the fail set is t j (single ele ment). Now at t his point OS D, contro l dependence flow co mparison i s made between f ail set-t j and all of pass set-t 1 ,...,t j-1 ,t j+1 ,...,t k . After the co mparison, t i is the so le test inpu t that matches the most to t j (in respect to co ntrol dependence flow). At t his sta ge of OSD State compariso n occ urs b etween t i and t j , r esulting bug report that p oints o ut the bug in so urce code level. The important step s o f my appro ach hav e been shown in Figure 1; the rounded corner blocks represent i nitial i nput test suite, control depende nce flow compariso n, state comparis o n, bug report etc. T he rectang ular blocks represent buggy ob je ct oriented program, C lDG, s t ate c har t UML , state t ra n si t io n table and other o utput test case and sets etc. I now br iefly discuss the d ifferent steps i n volv ed in my app roach. 1) The Bu ggy object oriented pr ogram is t he source code written in C++ lang uage. It is b asically a buggy co de where the lo gic of an elev ator controller (embedded system) is illustrated. My target is to debug thi s code. 2) T he State chart U ML is the finite s tate machine model corresponding to the buggy p rogra m. 3) The State transition table is generated from state chart UML model. It contai ns various initial and final states with t heir co ndition and operation e mbedded. Fig. 1. Overvie w approach to O SD 4) T he ClDG mo del repr esents the class depe ndence graph of the buggy pro gram itsel f. 5) T he Con tr ol dep endence flow comparison bloc k co m- pares the co ntrol depe ndence flow bet ween t he failed and all o ther passed input. 6) T he State co mparison block co mpares the states of t i and t j , b etween the node s o f ClD G. 7) The B ug report is the final repor t r egarding bug present inside the buggy program, which can point out the location of bug in so urce code le vel. 8) T he t 1 ,...,t i ,..., t j ,...,t k is t he inp ut test suite. 9) The t 1 ,..,t i ,...t j-1 ,t j+1 ,..., t k is the p ass inp ut of the previou s told suite. 10) T he t j is the failed inp ut from the input s uite. 11) T he t i is the best chosen inp ut from the set o f pass inputs belo nging to initial test suite. I V . D E TA I L E D A P P R O A C H In this section I will describe the d etailed methodolo gy of Object State based Debuggi ng (OSD). First thing that I wi ll present i n this portion is the buggy pro gram. A. Buggy Object Oriented Pr ogram The Fi gure 2 is the code sni ppet of a n elev ator co ntroller written in C++. The co ntroller has t w o main parts. • Request Re solver – resolves various floor req ues ts into single requested flo or . • Contr ol – moves elev ator t o its requested floor . 1) Description: Elev ator [11] moves either up or d own to reach the requested floor . Once at the requested floor , open the door for at least 10 seconds, a nd keep it open until the requested floor changes. It is e nsured that the door is never open while moving. E lev ato r does not chang e directions unless there are no higher requests whe n moving up or no low er requests when movi ng down. I n this pap er , I hav e ta ken the building to be three storied (h aving number o f floors equal to three that is - ground -0, first- 1, seco nd-2) for simplicit y . 2) Pr efixes intr oduced in pr og ram: T he numbers have bee n assigned s e q u e n t i a l l y t o e a c h s tat e ment i n t h e or d e r t hey appear in the source code for identifying t hem in the ClDG. The prefixes S, E, CE and C denote statements, method entr y , class entr y and call nodes respectively . 3) Bug intoduced: I n respect to my inves tigatio n I hav e i ntroduced a bug inside the code. Line n umber 13 and 14 in unitControl() method of Co ntrol class. T his res ults in door open when any o ne, requests a floor ( which is 1 in this case) from a lower floor ( say floor number 0). This r epels the door to b e op en for 1 0000 milliseconds, thus not inv o kin g the expec ted task ( movement). T his restricts the person (standing at gro u nd floor) to go first floor . T his co de works well ot herwise. 4) Concurr ency er ror ignoran ce: T his c o d e snippet i s purely an example of concurrency . Hence the hazards regarding concurrency such as d eadlock, synchro nization etc. have been ignored at time. B. State chart I ha ve obta ined a state chart UML diagram fro m Fi gure 2. The diagram is show n in the Figure 3. The state chart show s four di ff erent states – Idle, Going Up, Going Down, Door Open as t he probab le states. Possible transitions fro m one state t o anot her is based on input (E. g., req > floor, req < floor etc.). Actions are occurred in each state (E . g . , the Goi ngUp state u,d,o ,t = 1 ,0,0,0 (up = 1, d own, op en, and timer start = 0). C. State transition table T able I refers to the state transition tab le generated fro m Figure 3. The transition table contains initial state, co nd iti on, operation / actio n, final state. There is another state Not Defined – ND, that can p lay an imp ortant role in providing object state information to th ose states which can always Fig. 2. Buggy Object Oriented Program snippet Fig. 3. State chart gener ated from Figure 2 Fig. 4. C lDG of the whole program (Obtained from Figur e 2) not satisfy the given state char t criteria. Going up = u, G oing Do wn = d, Door open = o, ti mer start = t are d iff erent noti ons of actio ns, that frequently occur in each s tate of t he class (o bj ect state infor mati on) under execution. T ABLE I State tra nsition table gener at ed fr om F igure 3 D. ClDG r epr esen tation of the buggy pr og ram In this sectio n, I w il l generate the ClDG corr esponding to the buggy object oriented p rogram (Figure 2). Along with t his representation, I demonstrate another ClDG incorpor ated w ith state in formation of class Co ntr ol , from the progra m. I cho ose this class regardless of other t wo modules o f p rogram ( i.e. class RequestResolver and vo id ma in ). F ig. 5. State information incorpora ted to ClDG of the class Control 1) State i n f o r m a t i o n i n c o r p o r a t i o n t o C l D G : From t h e progra m show n in Figure 2, it can ea sily be s aid th at the class Co ntr ol is the main module that controls over the ele v ator movement. Hence, for sim plicity I am interested only to this module of t he pro gram. H ere I hav e i ntroduced a critical metric – object stat e information, into the v ario us node s of the ClDG o f the c lass Con tr ol . The similar i s s how n in the Figure 5. Where each rectangular bo x is associated with the state in formation to the corr esponding nodes o f t he ClDG. E. T est suite deployment In this por tion, I w i l l feed t he buggy p rogram with input test suite. This results in a test suite decision table. T his tabl e show s all the co mbination t hat can form from a t hree storied bu ilding architecture, cap turing its three floors a nd the co rrespondi ng r equests. T his table shows all t he nodes belong to class Contr ol . The ‘ +’ sign represents the full execution of the respecti ve nod es, while ‘- ’ sign tells about the b ypassing nodes. Fi nally t he co mbination of inputs result i n t he fail or pass mark, shown i n Figure 6. All test ca se s invo lvi ng < fl oo r , req > are sho wn in t he Figure 6. From this, I g o t th e clear view o f con trol dependence flow i n respect to the nodes of ClDG. The < 0, 1 > input results in failure, where as others pa ss. Analyzing t he whole test suit decision table, it can pr omptly be said that input <0, 1 > and <1 , 2 > are clo sely matched to each other (in respect of control depe ndence flow). Initial State Condition Operation (Action) Final State Idle req == floor u,d,o,t =0,0,1,0 Idle Idle req > floor u,d,o,t =1,0,0,0 Going Up Idle req < floor u,d,o,t =0,1,0,0 Going Down Going Up req > floor u,d,o,t =1,0,0,0 Going Up Going Up ! req > floor u,d,o,t =0,0,1,0 Door Open Door Open timer < 10 u,d,o,t =0,0,1,1 Door Open Door Open ! timer < 10 u,d,o,t =0,0,1,0 Idle Going Down req < floor u,d,o,t =0,1,0,0 Going Down Going Down ! req < floor u,d,o,t =0,0,1,0 Door Open Fig. 6. T est suite decis ion table for class Control Fig. 7. State comparison betw een the fail ure and passing test cases F . State information compa rison Here I pres ent the state i nformation co mparison b etween the above pair of test inputs; the failed input <0, 1 > a n d the passing i nput <1, 2>. T he Figure 7 illustrates the whole process. Nd, Id , Do, Gu, Do represents Not de fined, Id le, Do or open, Goi ng up, Goi ng down respectively . From t he F igure 7 , it is clear to understand that the two i nputs <0, 1 > and < 1, 2 > di ff ers at node number S13 and S14, i n respect of states ( Gu at S13 and Do at S14 ) , show n in rounded form. G. State comparison matrix State comparison matrix is such a matrix that represents the state alig nment o f failing inpu t to the passing o ne. T he Fi gure 8 sho ws t he state comparison bet ween <0 , 1 > a n d <1, 2 > . The left most column presents the s tate info rmation o f passing input (<0, 1> ) . Whereas the upper most row presents the state information of failing i nput (< 1, 2> ). T he matrix b asically show s a s traight line starting from upper left most corner to the low er right most. The line represents the state align men t between these t w o test i nputs. There is a slope in the l ine, S13 and S14 numbered col umns. H. Sour ce level bug detection Now if, I take the i nformation from the above paragrap h and search the reason o f t he misbehavior of t he line in the matrix , I can find that a co uple of st ate c ha ng e occurred during the execut ion of the code. While in vestigating this reason, I found that line n umber 13 of the program inv o lves an if statement , which when executes the bug is infiltrated i nside the code making it buggy . Fig. 8. State comparison matrix Fig. 9. Bug localiz ation in source code le vel The if statement is tr ue when it satisfies the r eq==1 condi tion, resulting the co ntrol flow to j ump at line num ber 19. This keeps the door op en, maki ng the Door o pen state true. T he Figure 9 shows the buggy segment inside the code. V . C O N C L U S I O N In this paper I h a v e propo sed a ne w method ology for debugging erro rs in the ob ject oriented progra ms in source code level. I have given an O SD model as an imple mentation of obj ect state information into Cl DG. I have proven the debugging method ology, inco rporating a previously known buggy program into a d ebugged o ne. Currently I a m b u s y wi t h the i mplementation of th e OSD model. R E F E R E N C E S [1] Gre gg R other mel and Ma ry Jean Harrold. Selec ting re gre s sion tests for objec t- oriented softw a re. In Proc. of the I nt l. C onf. on Sof twar e Mainten ance - 1994, pages 1425, V ictor ia, BC, Canada, Sep 1994. [2] Jeanne F err a nte, Karl J. Ot tenstein , and Joe D. W arren. T he progr am d epe n- den ce graph and its use in op timizat ion. A CM T ransactio ns on Progr a mming Languages and Systems, 9(3):31 9349, Jul 1987. [3] Swarnendu Biswas, R ajib Mall, M anora njan Satpathy an d Srihari Suku- maran. A Mod el-Base d Regr ession T est Selec tion Approach for Emb ed- ded Applica tions. SIGSOFT Software Engineeri ng Notes, July 2009. [4] M . All en and S. Hor witz. Slici ng ja v a prog rams that thro w and catch exce ptions. In In PEPM 03: Proceedings of th e 2003 A CM SIGPLA N wor k shop on Par tial e valuat ion and semant ics-base d progra m mani pu- lation, pages 4454, 2003. [5] R . Gupta, M. Harro ld, and M. Soa. Program s lici ng base d regr ession testing techni ques. Journal of Softw are T esting, V ericat i on, and R eli a- bil ity , 6(2):831 12, June 1996. [6] M. Harrol d, J. Jones, T . Li, D. Liang, A. Orso, M. Pennings, S. Sinha, S. A. Spoon, and A. Gujarathi. Regr ession test selectio n for java softwar e. In Procee dings of the 16th A CM SIGPLAN Confere nce on Object Oriente d Programming, Systems, Languages a nd Applic atio n s, pages 312326, J anuary 2001. [7] G. Rothermel and M. Harr old. Selecti ng re gre ssion t e gration t est ing. In Procee dings of W orld Academy of Science, Engineering and T echnol- ogy , volume 16, Nov ember 2006. [8] G. Rothermel and M. Harrol d. Selecting tests and identifying te st cov erage requir ements for modied softw a re. I n Proceedin gs of the A C M I nterna tional Symposium on Softwar e T esting and Analy s is, pages 169184, A ugust 1994. [9] G. R otherme l and M. Harr old. A safe, ecient regression test selectio n technique. A CM Tr ansaction s on Softw are Engineering and Methodol- ogy , 6(2):17321 0, April 1997. [10] G. Rothermel, M. Harr old, and J. Dedhia. Re gression test select io n for C++ s oftw are. Software T esting, V erication and R eliab ility , 10:771 09, Ju ne 2000. [11] Embedded Systems Design: A Unified Hardwar e/Softw are Introductio n, (c) 2000 V a hid/G i v argis. [12] J. Tsai, K. Fang, and Y . B i. O n real- time softw are testing a nd deb ug- ging. In Proceedings of the Fourtee nth Annual I nternat ional Computer Softw are and Applicat ions Conferen ce,, pages 512518, 1990. [13] S. Sinha and M . Harrold. Analy sis of programs with exception-h andli ng constr u cts. I n I n Pro ceedings of the Intern ational C onfer ence on Soft- w are Maintena nce, pages 348357, 1998. [14] S. Ji ang, S. Zhou, Y . Shi, and Y . J iang. Impro ving the preciseness of dependence analysis u sing ex ception In Proceedings of the 15th I nternation al Conference o n Computing IEEE, pa ges 277282, 2006. [15] S. Sinha and M. Harrold. Analysis and testing of analysis. progr ams with except ion-ha ndling constructs. IEEE Tr ansactions on Softw are Enginee ring , 26(9):84 9-871,200 0. [16] R. Zhao and L. Lin. An uml s tatech art diagr am-based mmpath gener a - tion approach for object-or iented inte gr ation t est ing. In Proceedings of W orld Acade my of Science, Engineer ing and T echn ology , volume 16, Nov ember 2006. [17] R. Ma ll . Fundamentals of Softw are Enginee ring. Prentice Hall of India, 2nd edi tion, 2 008. [18] Z.Li, M. Harman, and R. Hier ons. Search algor ithms for r egr essi on test case p r ior itizat ion. IEEE Tr ansactio ns on Software Engineering, pages 495-505 , March 1996.