Anonymous | Login | Signup for a new account | 2022-08-13 02:51 UTC | ![]() |
Main | My View | View Issues | Change Log | Roadmap |
View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||
0000950 | Taste | [All Projects] ASN.1 Compiler v4 | public | 2021-08-30 16:27 | 2021-09-16 12:43 | ||||
Reporter | gmamais | ||||||||
Assigned To | gmamais | ||||||||
Priority | normal | Severity | minor | Reproducibility | always | ||||
Status | closed | Resolution | fixed | ||||||
Platform | OS | OS Version | |||||||
Summary | 0000950: [FAQAS] Progress on test generation for the ASN.1 case study | ||||||||
Description | Dear Thanassis, We have applied our mutation analysis framework to the auto-generated code produced by the ASN1CC compiler, particularly the auto-generated code has been produced with the ASN.1 grammar you've shared with us during the last year. The analysis was done in two phases, that is, phase (1) mutation analysis, and phase (2) test generation. During phase (1), we applied mutation analysis to the auto-generated code (i.e., the test.c source code), and we generated 5.323 code-driven mutants, that is, 5.323 syntactic altered versions of the original code. Through its test suite, we identified 3.104 mutants, but 2.219 mutants remain undetected, giving a mutation score of 58.13%. Now, we started analyzing on the details the content of these 1.717 tests, but we noticed something peculiar about one of them, that I'll describe in the following: The original mutated code is the following one and concerns the function T_INT_IsConstraintValid: flag T_INT_IsConstraintValid(const T_INT* pVal, int* pErrCode) {
} Our test generation tool tells us that for this case, an input value that kills the mutant is pVal=0. We found this a bit strange, since the original test suite already considers pVal=0 as an input (it also considers pVal=50). To be sure, we also checked the test source code that invokes T_INT_IsConstraintValid: flag T_INT_enc_dec(const T_INT* pVal, int* pErrCode, const char* filename) And it seems that after the invocation of T_INT_IsConstraintValid, the value of pErrCode is never checked, and probably this is the reason why the mutant that modifies the value of pErrCode is not detected. To summarize, the test suite lacks a verification of the value contained by pErrCode (i.e., it shall check that it does not contain an error code). Is our conclusion correct? We will progress with analyzing the rest of the generated tests but first we would like to have some feedback from your side. Thanks in advance, –– Oscar Cornejo, PhD UNIVERSITÉ DU LUXEMBOURG CAMPUS KIRCHBERG mail from Maxime Maxime.Perrotin@esa.int Hi both, I believe that the "issue" is here: errCode has been mutated inside IsConstraintValid, and then set again to 0 without an intermediate check, so indeed the mutation is not detected. So instead of if (ret), we should/could have if (0 == errCode && ret) Kind regards ESA - European Space Agency Maxime Perrotin ESTEC | ||||||||
Tags | No tags attached. | ||||||||
Attached Files | |||||||||
![]() |
|
(0003796) gmamais (developer) 2021-08-30 16:28 |
Fixed according to Maxime proposal. |
(0003799) maxime (administrator) 2021-09-16 12:43 |
Thanks! closing |
![]() |
|||
Date Modified | Username | Field | Change |
2021-08-30 16:27 | gmamais | New Issue | |
2021-08-30 16:27 | gmamais | Status |
new => assigned |
2021-08-30 16:27 | gmamais | Assigned To |
=> gmamais |
2021-08-30 16:28 | gmamais | Note Added: 0003796 | |
2021-08-30 16:28 | gmamais | Status |
assigned => resolved |
2021-08-30 16:28 | gmamais | Resolution |
open => fixed |
2021-09-16 12:43 | maxime | Note Added: 0003799 | |
2021-09-16 12:43 | maxime | Status |
resolved => closed |
Copyright © 2000 - 2011 MantisBT Group |