pascal-cuoq
commented
8 years ago As of the latest commit, you should be able to use this mode. Just add the option --malloc-returns-null to an existing tis-interpreter.sh command-line.
You should only add it once the interpreter is already set up and working well in its default “malloc always succeeds” mode. Even so, the new malloc results can cause some more of the target code to be explored, and you may realize that a function is called that wasn't necessary before.
One thing that may happen is that the interpreter will just use up time and memory, and will after a while look like it is only doing the same thing hundreds of times. This is not something that can easily be avoided at the moment, it just means that the test's structure is a bad fit for this mode. Let me illustrate on one example:
#include <stdio.h>
#include <stdlib.h>
int counter;
int test_1(void) {
int *p = malloc(sizeof(int));
if (!p) return -1;
*p = 1;
printf("%d", *p);
free(p);
counter++;
return 0; // all went well
}
int test_2(void) {
float *p = malloc(sizeof(float));
if (!p) return -1;
*p = 2.0f;
printf("%f", *p);
free(p);
counter++;
return 0; // all went well
}
int test_3(void) {
char *p = malloc(sizeof(char));
if (!p) return -1;
*p = 'a';
printf("%c", *p);
free(p);
counter++;
return 0; // all went well
}
int main()
{
test_1();
test_2();
test_3();
}Analyzing this program in “malloc always succeeds”:
$ tis-interpreter.sh t.c
[value] Analyzing a complete application starting at main
[value] Computing initial state
[value] Initial state computed
1
2.000000
a
[value] done for function mainAnalyzing this program in “malloc returns NULL” mode:
$ tis-interpreter.sh t.c --malloc-returns-null
[value] Analyzing a complete application starting at main
[value] Computing initial state
[value] Initial state computed
1
2.000000
2.000000
a
a
a
[value] done for function mainAs you can see, the interpreter gets more and more work to do, because the later tests are invoked for more and more possible past sequences of allocations successes and failures. Some OpenSSL tests are exactly like this: they call functions that can fail, and the functions are properly written to clean up after themselves and return an error code, but the tests do not check these error codes and continue nonetheless. These tests will not do well in tis-interpreter.sh --malloc-returns-null. Just do not run them until a better solution is found.
One solution is to “improve” the tests. Here, that would be:
$ cat t.c
…
int main()
{
if (test_1() < 0) return 1;
if (test_2() < 0) return 2;
if (test_3() < 0) return 3;
}
$ tis-interpreter.sh t.c --malloc-returns-null
[value] Analyzing a complete application starting at main
[value] Computing initial state
[value] Initial state computed
1
2.000000
a
[value] done for function mainAbout interactions between “malloc returns NULL” mode and the filesystem emulation: it happens to work rather well. Allocation failures in the filesystem code are usually correctly translated to failures of the call that was made, giving the opportunity to test what happens in the target code when these calls fail. I only tested this a little, though, so it may not be perfect yet.
A recent commit said: "prepare malloc-returns-null mode"
Can you describe that a little more?
One of the problems in checking openssl right now is that the error path for malloc() failures never gets checked, while we can check various of the other error cases.