Pub Date : 2022-08-21DOI: 10.1109/ISSREW55968.2022.00078
Li Huang, B. Meyer, M. Oriol
In software verification, a successful automated program proof is the ultimate triumph. The road to such success is, however, paved with many failed proof attempts. The message produced by the prover when a proof fails is often obscure, making it very hard to know how to proceed further. The work reported here attempts to help in such cases by providing immediately understandable counterexamples. To this end, it introduces an approach called Counterexample Extraction and Minimization (CEAM). When a proof fails, CEAM turns the counterexample model generated by the prover into a a clearly understandable version; it can in addition simplify the counterex-amples further by minimizing the integer values they contain. We have implemented the CEAM approach as an extension to the AutoProof verifier and demonstrate its application to a collection of examples.
{"title":"Improving Counterexample Quality from Failed Program Verification","authors":"Li Huang, B. Meyer, M. Oriol","doi":"10.1109/ISSREW55968.2022.00078","DOIUrl":"https://doi.org/10.1109/ISSREW55968.2022.00078","url":null,"abstract":"In software verification, a successful automated program proof is the ultimate triumph. The road to such success is, however, paved with many failed proof attempts. The message produced by the prover when a proof fails is often obscure, making it very hard to know how to proceed further. The work reported here attempts to help in such cases by providing immediately understandable counterexamples. To this end, it introduces an approach called Counterexample Extraction and Minimization (CEAM). When a proof fails, CEAM turns the counterexample model generated by the prover into a a clearly understandable version; it can in addition simplify the counterex-amples further by minimizing the integer values they contain. We have implemented the CEAM approach as an extension to the AutoProof verifier and demonstrate its application to a collection of examples.","PeriodicalId":178302,"journal":{"name":"2022 IEEE International Symposium on Software Reliability Engineering Workshops (ISSREW)","volume":"11 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2022-08-21","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"116672841","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}
Pub Date : 2022-08-17DOI: 10.1109/ISSREW55968.2022.00035
Gunnar Kudrjavets, Jeff Thomas, Aditya Kumar, Nachiappan Nagappan, Ayushi Rastogi
For decades, the guidance given to software engi-neers has been to check the memory allocation results. This validation step is necessary to avoid crashes and undefined behavior. However, in user mode, in modern operating systems (OS), such as Android, FreeBSD, iOS, and macOS, the caller does not have an opportunity to handle the memory allocation failures. This behavioral trait results from the actions of a system component called an out-of-memory (OOM) killer. We identify that the only mainstream OS that, by default, lets applications detect memory allocation failures is Microsoft Windows. The false expectation that an application can handle OOM errors can negatively impact its design. The presence of error-handling code creates an illusion of reliability and is wasteful in terms of lines of code and code size. We describe the current behavior of a sample of popular OSs during low-memory conditions and provide recommendations for engineering practices going forward.
{"title":"When malloc() Never Returns NULL—Reliability as an Illusion","authors":"Gunnar Kudrjavets, Jeff Thomas, Aditya Kumar, Nachiappan Nagappan, Ayushi Rastogi","doi":"10.1109/ISSREW55968.2022.00035","DOIUrl":"https://doi.org/10.1109/ISSREW55968.2022.00035","url":null,"abstract":"For decades, the guidance given to software engi-neers has been to check the memory allocation results. This validation step is necessary to avoid crashes and undefined behavior. However, in user mode, in modern operating systems (OS), such as Android, FreeBSD, iOS, and macOS, the caller does not have an opportunity to handle the memory allocation failures. This behavioral trait results from the actions of a system component called an out-of-memory (OOM) killer. We identify that the only mainstream OS that, by default, lets applications detect memory allocation failures is Microsoft Windows. The false expectation that an application can handle OOM errors can negatively impact its design. The presence of error-handling code creates an illusion of reliability and is wasteful in terms of lines of code and code size. We describe the current behavior of a sample of popular OSs during low-memory conditions and provide recommendations for engineering practices going forward.","PeriodicalId":178302,"journal":{"name":"2022 IEEE International Symposium on Software Reliability Engineering Workshops (ISSREW)","volume":"1 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2022-08-17","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"125549254","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
扫码关注我们
求助内容：
应助结果提醒方式：