Ameya Ketkar, A. Mesbah, D. Mazinanian, Danny Dig, E. Aftandilian
Type migration is a refactoring activity in which an existing type is replaced with another one throughout the source code. Manually performing type migration is tedious as programmers need to find all instances of the type to be migrated, along with its dependencies that propagate over assignment operations, method hierarchies, and subtypes. Existing automated approaches for type migration are not adequate for ultra-large-codebases - they perform an intensive whole-program analysis that does not scale. If we could represent the type structure of the program as graphs, then we could employ a MAPREDUCE parallel and distributed process that scales to hundreds of millions of LOC. We implemented this approach as an IDE-independent tool called T2R, which integrates with most build systems. We evaluated T2R's accuracy, usefulness and scalability on seven open source projects and one proprietary codebase of 300M LOC. T2R generated 130 type migration patches, of which the original developers accepted 98%.
{"title":"Type Migration in Ultra-Large-Scale Codebases","authors":"Ameya Ketkar, A. Mesbah, D. Mazinanian, Danny Dig, E. Aftandilian","doi":"10.1109/ICSE.2019.00117","DOIUrl":"https://doi.org/10.1109/ICSE.2019.00117","url":null,"abstract":"Type migration is a refactoring activity in which an existing type is replaced with another one throughout the source code. Manually performing type migration is tedious as programmers need to find all instances of the type to be migrated, along with its dependencies that propagate over assignment operations, method hierarchies, and subtypes. Existing automated approaches for type migration are not adequate for ultra-large-codebases - they perform an intensive whole-program analysis that does not scale. If we could represent the type structure of the program as graphs, then we could employ a MAPREDUCE parallel and distributed process that scales to hundreds of millions of LOC. We implemented this approach as an IDE-independent tool called T2R, which integrates with most build systems. We evaluated T2R's accuracy, usefulness and scalability on seven open source projects and one proprietary codebase of 300M LOC. T2R generated 130 type migration patches, of which the original developers accepted 98%.","PeriodicalId":6736,"journal":{"name":"2019 IEEE/ACM 41st International Conference on Software Engineering (ICSE)","volume":"13 1","pages":"1142-1153"},"PeriodicalIF":0.0,"publicationDate":"2019-05-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"86979803","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Despite significant advances in automatic program repair (APR) techniques over the past decade, practical deployment remains an elusive goal. One of the important challenges in this regard is the general inability of current APR techniques to produce patches that require edits in multiple locations, i.e., multi-hunk patches. In this work, we present a novel APR technique that generalizes single-hunk repair techniques to include an important class of multi-hunk bugs, namely bugs that may require applying a substantially similar patch at a number of locations. We term such sets of repair locations as evolutionary siblings - similar looking code, instantiated in similar contexts, that are expected to undergo similar changes. At the heart of our proposed method is an analysis to accurately identify a set of evolutionary siblings, for a given bug. This analysis leverages three distinct sources of information, namely the test-suite spectrum, a novel code similarity analysis, and the revision history of the project. The discovered siblings are then simultaneously repaired in a similar fashion. We instantiate this technique in a tool called HERCULES and demonstrate that it is able to correctly fix 46 bugs in the Defects4J dataset, the highest of any individual APR technique to date. This includes 15 multi-hunk bugs and overall 11 bugs which have not been fixed by any other technique so far.
{"title":"Harnessing Evolution for Multi-Hunk Program Repair","authors":"Seemanta Saha, Ripon K. Saha, M. Prasad","doi":"10.1109/ICSE.2019.00020","DOIUrl":"https://doi.org/10.1109/ICSE.2019.00020","url":null,"abstract":"Despite significant advances in automatic program repair (APR) techniques over the past decade, practical deployment remains an elusive goal. One of the important challenges in this regard is the general inability of current APR techniques to produce patches that require edits in multiple locations, i.e., multi-hunk patches. In this work, we present a novel APR technique that generalizes single-hunk repair techniques to include an important class of multi-hunk bugs, namely bugs that may require applying a substantially similar patch at a number of locations. We term such sets of repair locations as evolutionary siblings - similar looking code, instantiated in similar contexts, that are expected to undergo similar changes. At the heart of our proposed method is an analysis to accurately identify a set of evolutionary siblings, for a given bug. This analysis leverages three distinct sources of information, namely the test-suite spectrum, a novel code similarity analysis, and the revision history of the project. The discovered siblings are then simultaneously repaired in a similar fashion. We instantiate this technique in a tool called HERCULES and demonstrate that it is able to correctly fix 46 bugs in the Defects4J dataset, the highest of any individual APR technique to date. This includes 15 multi-hunk bugs and overall 11 bugs which have not been fixed by any other technique so far.","PeriodicalId":6736,"journal":{"name":"2019 IEEE/ACM 41st International Conference on Software Engineering (ICSE)","volume":"19 1","pages":"13-24"},"PeriodicalIF":0.0,"publicationDate":"2019-05-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"85333627","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
The Java Virtual Machine (JVM) is the cornerstone of the widely-used Java platform. Thus, it is critical to ensure the reliability and robustness of popular JVM implementations. However, little research exists on validating production JVMs. One notable effort is classfuzz, which mutates Java bytecode syntactically to stress-test different JVMs. It is shown that classfuzz mainly produces illegal bytecode files and uncovers defects in JVMs' startup processes. It remains a challenge to effectively test JVMs' bytecode verifiers and execution engines to expose deeper bugs. This paper tackles this challenge by introducing classming, a novel, effective approach to performing deep, differential JVM testing. The key of classming is a technique, live bytecode mutation, to generate, from a seed bytecode file f, likely valid, executable (live) bytecode files: (1) capture the seed f 's live bytecode, the sequence of its executed bytecode instructions; (2) repeatedly manipulate the control- and data-flow in f 's live bytecode to generate semantically different mutants; and (3) selectively accept the generated mutants to steer the mutation process toward live, diverse mutants. The generated mutants are then employed to differentially test JVMs. We have evaluated classming on mainstream JVM implementations, including OpenJDK's HotSpot and IBM's J9, by mutating the DaCapo benchmarks. Our results show that classming is very effective in uncovering deep JVM differences. More than 1,800 of the generated classes exposed JVM differences, and more than 30 triggered JVM crashes. We analyzed and reported the JVM runtime differences and crashes, of which 14 have already been confirmed/fixed, including a highly critical security vulnerability in J9 that allowed untrusted code to disable the security manager and elevate its privileges (CVE-2017-1376).
{"title":"Deep Differential Testing of JVM Implementations","authors":"Yuting Chen, Ting Su, Z. Su","doi":"10.1109/ICSE.2019.00127","DOIUrl":"https://doi.org/10.1109/ICSE.2019.00127","url":null,"abstract":"The Java Virtual Machine (JVM) is the cornerstone of the widely-used Java platform. Thus, it is critical to ensure the reliability and robustness of popular JVM implementations. However, little research exists on validating production JVMs. One notable effort is classfuzz, which mutates Java bytecode syntactically to stress-test different JVMs. It is shown that classfuzz mainly produces illegal bytecode files and uncovers defects in JVMs' startup processes. It remains a challenge to effectively test JVMs' bytecode verifiers and execution engines to expose deeper bugs. This paper tackles this challenge by introducing classming, a novel, effective approach to performing deep, differential JVM testing. The key of classming is a technique, live bytecode mutation, to generate, from a seed bytecode file f, likely valid, executable (live) bytecode files: (1) capture the seed f 's live bytecode, the sequence of its executed bytecode instructions; (2) repeatedly manipulate the control- and data-flow in f 's live bytecode to generate semantically different mutants; and (3) selectively accept the generated mutants to steer the mutation process toward live, diverse mutants. The generated mutants are then employed to differentially test JVMs. We have evaluated classming on mainstream JVM implementations, including OpenJDK's HotSpot and IBM's J9, by mutating the DaCapo benchmarks. Our results show that classming is very effective in uncovering deep JVM differences. More than 1,800 of the generated classes exposed JVM differences, and more than 30 triggered JVM crashes. We analyzed and reported the JVM runtime differences and crashes, of which 14 have already been confirmed/fixed, including a highly critical security vulnerability in J9 that allowed untrusted code to disable the security manager and elevate its privileges (CVE-2017-1376).","PeriodicalId":6736,"journal":{"name":"2019 IEEE/ACM 41st International Conference on Software Engineering (ICSE)","volume":"115 1","pages":"1257-1268"},"PeriodicalIF":0.0,"publicationDate":"2019-05-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"76783309","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
J. Atlee, G. Mussbacher, Betty H. C. Cheng, J. Whittle, Michael Whalen
{"title":"Organizing Committee of ICSE 2019","authors":"J. Atlee, G. Mussbacher, Betty H. C. Cheng, J. Whittle, Michael Whalen","doi":"10.1109/icse.2019.00012","DOIUrl":"https://doi.org/10.1109/icse.2019.00012","url":null,"abstract":"","PeriodicalId":6736,"journal":{"name":"2019 IEEE/ACM 41st International Conference on Software Engineering (ICSE)","volume":"18 1","pages":""},"PeriodicalIF":0.0,"publicationDate":"2019-05-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"79364136","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
{"title":"Journal First Program Committee of ICSE 2019","authors":"","doi":"10.1109/icse.2019.00015","DOIUrl":"https://doi.org/10.1109/icse.2019.00015","url":null,"abstract":"","PeriodicalId":6736,"journal":{"name":"2019 IEEE/ACM 41st International Conference on Software Engineering (ICSE)","volume":"9 1","pages":""},"PeriodicalIF":0.0,"publicationDate":"2019-05-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"89504930","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
{"title":"Message from the Social Media Chairs of ICSE 2019","authors":"","doi":"10.1109/icse.2019.00011","DOIUrl":"https://doi.org/10.1109/icse.2019.00011","url":null,"abstract":"","PeriodicalId":6736,"journal":{"name":"2019 IEEE/ACM 41st International Conference on Software Engineering (ICSE)","volume":"1 1","pages":""},"PeriodicalIF":0.0,"publicationDate":"2019-05-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"78598033","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Practitioners use infrastructure as code (IaC) scripts to provision servers and development environments. While developing IaC scripts, practitioners may inadvertently introduce security smells. Security smells are recurring coding patterns that are indicative of security weakness and can potentially lead to security breaches. The goal of this paper is to help practitioners avoid insecure coding practices while developing infrastructure as code (IaC) scripts through an empirical study of security smells in IaC scripts. We apply qualitative analysis on 1,726 IaC scripts to identify seven security smells. Next, we implement and validate a static analysis tool called Security Linter for Infrastructure as Code scripts (SLIC) to identify the occurrence of each smell in 15,232 IaC scripts collected from 293 open source repositories. We identify 21,201 occurrences of security smells that include 1,326 occurrences of hard-coded passwords. We submitted bug reports for 1,000 randomly-selected security smell occurrences. We obtain 212 responses to these bug reports, of which 148 occurrences were accepted by the development teams to be fixed. We observe security smells can have a long lifetime, e.g., a hard-coded secret can persist for as long as 98 months, with a median lifetime of 20 months.
从业者使用基础设施作为代码(IaC)脚本来提供服务器和开发环境。在开发IaC脚本时，从业者可能会无意中引入安全气味。安全气味是一种反复出现的编码模式，表明存在安全漏洞，可能导致安全漏洞。本文的目标是通过对IaC脚本中的安全气味的实证研究，帮助从业者在开发作为代码的基础架构(IaC)脚本时避免不安全的编码实践。我们对1726个IaC脚本进行定性分析，识别出7种安全气味。接下来，我们实现并验证一个静态分析工具，称为基础设施即代码脚本的安全检查器(Security Linter for Infrastructure as Code scripts, SLIC)，以识别从293个开放源代码存储库收集的15232个IaC脚本中每种气味的出现情况。我们识别了21,201次安全气味，其中包括1,326次硬编码密码。我们为1000个随机选择的安全气味事件提交了bug报告。我们获得了对这些bug报告的212个响应，其中有148个bug被开发团队接受并修复了。我们观察到安全气味可以有很长的生命周期，例如，硬编码的秘密可以持续长达98个月，平均生命周期为20个月。
{"title":"The Seven Sins: Security Smells in Infrastructure as Code Scripts","authors":"A. Rahman, Chris Parnin, L. Williams","doi":"10.1109/ICSE.2019.00033","DOIUrl":"https://doi.org/10.1109/ICSE.2019.00033","url":null,"abstract":"Practitioners use infrastructure as code (IaC) scripts to provision servers and development environments. While developing IaC scripts, practitioners may inadvertently introduce security smells. Security smells are recurring coding patterns that are indicative of security weakness and can potentially lead to security breaches. The goal of this paper is to help practitioners avoid insecure coding practices while developing infrastructure as code (IaC) scripts through an empirical study of security smells in IaC scripts. We apply qualitative analysis on 1,726 IaC scripts to identify seven security smells. Next, we implement and validate a static analysis tool called Security Linter for Infrastructure as Code scripts (SLIC) to identify the occurrence of each smell in 15,232 IaC scripts collected from 293 open source repositories. We identify 21,201 occurrences of security smells that include 1,326 occurrences of hard-coded passwords. We submitted bug reports for 1,000 randomly-selected security smell occurrences. We obtain 212 responses to these bug reports, of which 148 occurrences were accepted by the development teams to be fixed. We observe security smells can have a long lifetime, e.g., a hard-coded secret can persist for as long as 98 months, with a median lifetime of 20 months.","PeriodicalId":6736,"journal":{"name":"2019 IEEE/ACM 41st International Conference on Software Engineering (ICSE)","volume":"9 1","pages":"164-175"},"PeriodicalIF":0.0,"publicationDate":"2019-05-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"77768346","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Emad Aghajani, Csaba Nagy, Olga Lucero Vega-Márquez, M. Linares-Vásquez, Laura Moreno, G. Bavota, Michele Lanza
(Good) Software documentation provides developers and users with a description of what a software system does, how it operates, and how it should be used. For example, technical documentation (e.g., an API reference guide) aids developers during evolution/maintenance activities, while a user manual explains how users are to interact with a system. Despite its intrinsic value, the creation and the maintenance of documentation is often neglected, negatively impacting its quality and usefulness, ultimately leading to a generally unfavourable take on documentation. Previous studies investigating documentation issues have been based on surveying developers, which naturally leads to a somewhat biased view of problems affecting documentation. We present a large scale empirical study, where we mined, analyzed, and categorized 878 documentation-related artifacts stemming from four different sources, namely mailing lists, Stack Overflow discussions, issue repositories, and pull requests. The result is a detailed taxonomy of documentation issues from which we infer a series of actionable proposals both for researchers and practitioners.
{"title":"Software Documentation Issues Unveiled","authors":"Emad Aghajani, Csaba Nagy, Olga Lucero Vega-Márquez, M. Linares-Vásquez, Laura Moreno, G. Bavota, Michele Lanza","doi":"10.1109/ICSE.2019.00122","DOIUrl":"https://doi.org/10.1109/ICSE.2019.00122","url":null,"abstract":"(Good) Software documentation provides developers and users with a description of what a software system does, how it operates, and how it should be used. For example, technical documentation (e.g., an API reference guide) aids developers during evolution/maintenance activities, while a user manual explains how users are to interact with a system. Despite its intrinsic value, the creation and the maintenance of documentation is often neglected, negatively impacting its quality and usefulness, ultimately leading to a generally unfavourable take on documentation. Previous studies investigating documentation issues have been based on surveying developers, which naturally leads to a somewhat biased view of problems affecting documentation. We present a large scale empirical study, where we mined, analyzed, and categorized 878 documentation-related artifacts stemming from four different sources, namely mailing lists, Stack Overflow discussions, issue repositories, and pull requests. The result is a detailed taxonomy of documentation issues from which we infer a series of actionable proposals both for researchers and practitioners.","PeriodicalId":6736,"journal":{"name":"2019 IEEE/ACM 41st International Conference on Software Engineering (ICSE)","volume":"14 1","pages":"1199-1210"},"PeriodicalIF":0.0,"publicationDate":"2019-05-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"82487633","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
S. Abrahão, H. Bagheri, David Benavides, Reyhaneh Jabbarvand, E. Knauss, Hitesh Sajnani, Shuai Wang, Xusheng Xiao
Silvia Abrahão Universitat Politècnica de València, Spain Hamid Bagheri University of Nebraska-Lincoln, USA David Benavides Universidad de Sevilla, Spain Kelly Blincoe University of Auckland, New Zealand Casey Casalnuovo University of California at Davis, USA Antonio Filieri Imperial College London, United Kingdom Joshua Garcia University of California, Irvine, USA Alexander Grebhahn University of Passau, Germany Regina Hebig Chalmers University of Technology and University of Gothenburg, Sweden Vincent Hellendoorn University of California at Davis, USA Reyhaneh Jabbarvand University of California, Irvine, USA Eric Knauss Chalmers University of Technology and University of Gothenburg, Sweden Anne Koziolek Karlsruhe Institute of Technology, Germany Li Li Monash University, Australia Lukas Linsbauer Johannes Kepler University Linz, Austria Patrick Mäder Technische Universität Ilmenau, Germany Ripon Saha Fujitsu Laboratories of America, Inc. Hitesh Sajnani Microsoft Nicolas Sannier University of Luxembourg, SnT Norbert Seyff FHNW & University of Zurich, Switzerland Fang-Hsiang Su Facebook Michael Vierhauser University of Notre Dame, USA Shuai Wang ETH Zurich, Switzerland Xusheng Xiao Case Western Reserve University, USA Wei Yang University of Texas at Dallas, USA Tianyi Zhang University of California, Los Angeles, USA
{"title":"Artifact Evaluation Committee of ICSE 2019","authors":"S. Abrahão, H. Bagheri, David Benavides, Reyhaneh Jabbarvand, E. Knauss, Hitesh Sajnani, Shuai Wang, Xusheng Xiao","doi":"10.1109/icse.2019.00017","DOIUrl":"https://doi.org/10.1109/icse.2019.00017","url":null,"abstract":"Silvia Abrahão Universitat Politècnica de València, Spain Hamid Bagheri University of Nebraska-Lincoln, USA David Benavides Universidad de Sevilla, Spain Kelly Blincoe University of Auckland, New Zealand Casey Casalnuovo University of California at Davis, USA Antonio Filieri Imperial College London, United Kingdom Joshua Garcia University of California, Irvine, USA Alexander Grebhahn University of Passau, Germany Regina Hebig Chalmers University of Technology and University of Gothenburg, Sweden Vincent Hellendoorn University of California at Davis, USA Reyhaneh Jabbarvand University of California, Irvine, USA Eric Knauss Chalmers University of Technology and University of Gothenburg, Sweden Anne Koziolek Karlsruhe Institute of Technology, Germany Li Li Monash University, Australia Lukas Linsbauer Johannes Kepler University Linz, Austria Patrick Mäder Technische Universität Ilmenau, Germany Ripon Saha Fujitsu Laboratories of America, Inc. Hitesh Sajnani Microsoft Nicolas Sannier University of Luxembourg, SnT Norbert Seyff FHNW & University of Zurich, Switzerland Fang-Hsiang Su Facebook Michael Vierhauser University of Notre Dame, USA Shuai Wang ETH Zurich, Switzerland Xusheng Xiao Case Western Reserve University, USA Wei Yang University of Texas at Dallas, USA Tianyi Zhang University of California, Los Angeles, USA","PeriodicalId":6736,"journal":{"name":"2019 IEEE/ACM 41st International Conference on Software Engineering (ICSE)","volume":"22 1","pages":""},"PeriodicalIF":0.0,"publicationDate":"2019-05-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"79983344","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Hybrid applications (apps) have become one of the most attractive options for mobile app developers thanks to its support for portability and device-specific features. Android hybrid apps, for example, support portability via JavaScript, device-specific features via Android Java, and seamless interactions between them. However, their interoperation semantics is often under-documented and unintuitive, which makes hybrid apps vulnerable to errors. While recent research has addressed such vulnerabilities, none of them are based on any formal grounds. In this paper, we present the first formal specification of Android interoperability to establish a firm ground for understanding and reasoning about the interoperations. We identify its semantics via extensive testing and thorough inspection of Android source code. We extend an existing multi-language semantics to formally express the key features of hybrid mechanisms, dynamic and indistinguishable interoperability. Based on the extensions, we incrementally define a formal interoperation semantics and disclose its numerous unintuitive and inconsistent behaviors. Moreover, on top of the formal semantics, we devise a lightweight type system that can detect bugs due to the unintuitive inter-language communication. We show that it detects more bugs more efficiently than HybriDroid, the state-of-the-art analyzer of Android hybrid apps, in real-world Android hybrid apps.
{"title":"Towards Understanding and Reasoning About Android Interoperations","authors":"Sora Bae, Sungho Lee, Sukyoung Ryu","doi":"10.1109/ICSE.2019.00038","DOIUrl":"https://doi.org/10.1109/ICSE.2019.00038","url":null,"abstract":"Hybrid applications (apps) have become one of the most attractive options for mobile app developers thanks to its support for portability and device-specific features. Android hybrid apps, for example, support portability via JavaScript, device-specific features via Android Java, and seamless interactions between them. However, their interoperation semantics is often under-documented and unintuitive, which makes hybrid apps vulnerable to errors. While recent research has addressed such vulnerabilities, none of them are based on any formal grounds. In this paper, we present the first formal specification of Android interoperability to establish a firm ground for understanding and reasoning about the interoperations. We identify its semantics via extensive testing and thorough inspection of Android source code. We extend an existing multi-language semantics to formally express the key features of hybrid mechanisms, dynamic and indistinguishable interoperability. Based on the extensions, we incrementally define a formal interoperation semantics and disclose its numerous unintuitive and inconsistent behaviors. Moreover, on top of the formal semantics, we devise a lightweight type system that can detect bugs due to the unintuitive inter-language communication. We show that it detects more bugs more efficiently than HybriDroid, the state-of-the-art analyzer of Android hybrid apps, in real-world Android hybrid apps.","PeriodicalId":6736,"journal":{"name":"2019 IEEE/ACM 41st International Conference on Software Engineering (ICSE)","volume":"3 1","pages":"223-233"},"PeriodicalIF":0.0,"publicationDate":"2019-05-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"88949093","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
京公网安备 11010802042870号
京ICP备2023020795号-1
扫码关注我们
求助内容：
应助结果提醒方式：