소프트웨어 오류제거 프로그램 아시나요?

http://ropas.snu.ac.kr/2004/airac/
을 보시면 아시겠지만, AIRAC 은 배열의 바운더리를 벗어나는 버그를 찾아주는 기능만을 갖고 있는 것으로 보입니다.

RATS, FlawFinder, ITS4 등의 C/C++ 기반의 고전적인 Static Analyzer들이 주로 취약한 함수의 DB를 토대로 잠재적 버그를 지적해준다면....

Bell 연구소에서 만든 Uno는 초기화되지 않은 변수의 사용(Use of uninitialized variable), 포인터 참조 오류(Nil-pointer references), 배열 바운더리 에러(Out-of-bounds array indexing)를 잡아주고 있습니다.
Uno : http://spinroot.com/uno/

AIRAC은 Uno가 가진 위의 3가지 기능중 Out-of-bounds array indexing 버그를 잡는 기능만을 구현한 것으로 보입니다.

C/C++ 프로그래밍에선 꼭 필요한 기능이지만, 이미 많은 언어들이 위의 문제를 자체적으로 해결하고 있기 때문에 상업적인 효용성은 떨어질 것으로 생각합니다.

그러나 해당 분야에 대한 연구가 미약한 국내 상황에서, 이런 프로그램에 대한 연구가 이루어졌다는 사실 자체는 고무적인 일이라고 생각합니다.

100%라는건 배열 바운더리 체크 오류의 100%를 의미하는
것이겠죠.. 처음 뉴스 인용문에 결론 부분에는 에러 종류의 전제가 없길래 모든 종류 오류의
100%는 불가능하다는 의미였는데요..

어쨌든 바운더리 체크만이라도 100% 잡아준다니 이것도
훌륭한 기능이네요.. 정말 버그 코드를 이것저것 만들어
실험해보고 싶은 생각이.. ^^;

근데 배열을 사용하지 않고 메모리 할당/재할당을 사용하는 경우에도
100% 찾아줄수 있나요?

KAIST를 떠나시더니만, SNU에서 드디어 한껀 올리셨군요.
대단한 분이시라고... 수업때 PL 로 사람들의 기를 빼놓으셨다고 하더군요. :)

어쨌든 formal method로 그런 기능을 하는걸 만든다는 것 자체가 대단한 일 아니겠습니까...

예전에 이 도구에 대해서 시연할때 malloc 에 대해선 지원한다고
하던데요~ 아마 free 부분은 지원 안하나 봅니다.(이것 free부분에서 에러 나는거 맞죠??)

아 잠시 착각을 했군요~~~ㅡㅡ;;;;
그냥 소스 자세히 살펴보지 않고 (크지도 않는데..)
그대로 붙여 놓고 컴파일했을때.
free 부분에서 에러가 나서리~~^^;;;

본론으로~예전에 이거 학회에서 시연하는걸 봤는데
그때는 malloc 부분도 완벽히 검사해준다고 했거든요~
아무래도 버그 같은데 개발자에게 메일이라도 보내보는건 어떠신지요??

ps ...소스 컴파일 해서 실행 시키면 "세그멘테이션 오류" 가 발생해야 하지 않냐요???제 리눅스 머신에서는 안나네요~~ㅡㅡ;;;
이해할수 없는 상황

#include <stdlib.h>

int main(void)
{
            int* p = (int *)malloc( sizeof(p));
            p[256] = 49;
            printf("%d %d\n",p[256],sizeof(p));
           free(p);
            return 0;
}
notpig@se:~$ gcc test.c  
notpig@se:~$ ./a.out    
49 4
notpig@se:~$

malloc 등을 할 때.. 정말 char 하나만 들어갈 수 있도록 8비트만이 딱 할당되는게 아니라.. 세그먼트 단위로 할당되기때문에..

페이지테이블에.. 해당주소가.. 실제 메모리주소로 매핑이 되서.. 페이지오류가 발생하지 않을 듯 싶습니다 :)

c언어에서 성능을 위해 바운더리 체크를 하지 않기 때문에.. 저런 식의 코드에서도 문제는 발생하지 않은 것이겠지요.. 에러를 내보시고 싶으시다면 256 대신에.. 사용하시는 아키텍쳐에서의 기본 세그먼트사이즈보다 큰 값을 넣어보세요

흠.. 저도 데모 사이트에서 테스트를 돌려보았습니다.

#include <stdio.h>
#include <time.h>

main()
{
    int a[10];
    int i;

    srandom(time());
    i = random();
    if ((i < 0) || (i >= 10)) {
        fprintf(stderr, "Wrong index: %d\n", i);
        exit(2);
    }

    printf("a[%d] = %d\n", i, a[i]);
}

처음 테스트 코드에서는 첨자 검사 하는 코드가 없었는데
동일한 메시지를 발생시켰었고요.

--

재밌는 프로그램인데, 대외발표 자료에 너무 강하게 기능설명을 하니,
좀 거시기 하네요... ㅡ.ㅡ;;

그나 저나 false alarm을 허용하더라도 (메모리 관련) 모든 오류를 다 잡아낸다는 것을 어떻게 *보장*했을까요?
가장 간단한 방법은 메모리 관련 연산을 모두 오류라고 잡아내는 것일텐데 이렇담 실용성에 문제가 있을테고... 흠..

이런 분야에 관심이 개인적으로 많아서 생각이 갑자기...

이런류의 즉, static analysis 는 실제로 커버할 수 있는

범위가 *대단히* 한정되어 있다고 봅니다.

즉, 구문 자체가 외부로 표출하는 내용만을 잡을 수 있을 뿐이고,

내부적인 오류를 잡으려면, 위의 도구로는 추측을 할 수 밖에 없습니다.

위에서 예를 제시한 coverity 도구도 유사한 것인데,

리눅스 소스코드에 대해 수행해서 몇개의 잠재된 버그를 잡았다고

하더군요. URL이 기억이 안나는데, sourceforge.net 에서 이

이론을 접목해서 개발되고 있는걸 봤습니다만..

이 제품에 대해 왈가왈부하기는 좀 그렇지만,

제가 몸담고 있는 개발분야에서는 이 툴을 내부에 잠재된 버그를

찾는데 쓰는것은 조금 꺼려지고,

coding convention이라든가, 1차적인 단순한 오류를 잡는데에

사용할 수 있을 것 같습니다.

개인적으로 볼 때, 가장 완벽한 메모리 관련 버그를 추적하는 방법은

가상머신 기법을 이용한 valgrind 와 같은 것이라고 생각됩니다.

그 활용도가 무궁무진할 것 같고, 실제로 이런 기술을 이용한

상용도구도 AIX 기반으로 zerofault 라는 제품이 있습니다.

purify나 valgrind 정도가 되어야 잠재된 버그를 왠만큼 잡을 수 있을

것 같고, 궁극적으로는 인간의 두뇌를 활용한 *code review(inspection)*

이 최고의 방법일 것 같다는...황당한 결론을 내리며..

이만 줄이겠습니다. --- 후다닥---

김성진 드림

처음엔 모든 오류를 잡아준다고하길래 놀랬는데.
가만읽어보니 메모리 사용범위만 검사해준다는것이네요..
그런경우라면 어느정도는 가능할듯.
다만 매우꼬아놓은경우..걍오류라인정해버릴수도..ㅎㅎ

그럼 이 프로그램은 전혀 오류가 없단 말인가..

'실행중에 오류가 발생하지 않음'을 어떤 방법으로 입증할 수 있을까요. '보장한다' 는 뜻은 실행중에 오류가 100% 안난다는 뜻으로 받아들였는데 그것이 현재 기술적으로 가능할지 궁금해지네요.

초보수준의 기능이지만 좀 더 보완되어 모든 실행상의 버그를 잡아주었으면 좋겠군요..

그렇게 되면 디버거와 눈싸움 하는 일도 없어지겠구요..:)

exit()은 시스템콜에 의해서 강제로 프로세스를 종료하는 것이기 때문에, 즉 일반 조건문이나 함수호출에 의한 분기가 아니므로 처리를 해 주지 않은 것 같습니다. 실제 산업에서 사용하기 위해서는 이런 기반 시스템에 대한 정보들도 설정을 해줘야 겠지요.

#include <stdio.h>
#include <time.h>

int main()
{
    int a[10];
    int i;

    srandom(time());
    i = random();
    if ((i < 0) || (i >= 10)) {
        fprintf(stderr, "Wrong index: %d\n", i);
        return 2;
    }
    printf("a[%d] = %d\n", i, a[i]);
    return 0;
}

exit() 대신에 return문을 사용하니 정확히 작동 합니다.

아,, 그렇겠네요..
exit() 이 프로그램을 종료해서 제어가 그 뒤로 가지 못하게 한다는 정보를 가지고 있지 못하면
일반적인 함수콜로 생각해서 수행i 가 범위안에 있지 않아도 함수 수행을 끝내고
순차적으로 그 다음 문장이 수행될 수 있라고 생각할 수 있으니 그럴 수 있겠네요.

몇개 더 테스트 해 봤는데,, 잘 되는 녀석도 있고, 잘 안되는 녀석도 있네요.

#include <stdio.h>
#include <time.h>
#include <malloc.h>

int
func()
{
    srandom(time());
    i = random() % 10;
    
    return i;
}

int
func1()
{
    return random() % 6;
}

int
func2()
{
    return random() % 6;
}

int
func3()
{
    int *ia;
    int n;
    
    n = random() % 10 + 1;
    ia = (int *)malloc(n * sizeof(int));

    n = random() % n;
    /* 위치 A */

    /* 경고 발생. 글쎄? */
    printf("ia[%d] = %d\n", n, ia[n]);
}
        
main()
{
    int a[10];
    int i;

    /* 잘됨! */
    i = func();
    printf("a[%d] = %d\n", i, a[i]);

    /* 경고발생! 잘됨! */
    i = func1() + func2();
    printf("a[%d] = %d\n", i, a[i]);
    
    func3();
}

func3() 안의 문장은 static한 분석으로 malloc() 실패를 제외하면 에러가 없을 듯 한데 경고로 잡네요.

경고행 옆에 나오는 주석을 보면

    n = random() % n;

매번 문장 수행마다 인덱스와 배열의 크기를 추적할 때,
변수의 가능범위를 계산해서 구체적인 수치영역으로 구해 놓기 때문에 발생한 문제가 아닐까 추측이 되는데요..
위의 경우에는 배열의 크기는 n0이고, n0의 범위는 [1, 10],
위치 A에서 n의 범위는 [0, n0 - 1] 식으로 유지를 했으면
오류로 판단하지 않을 수 있지않았을까 생각이 드네요.
배열크기가 [1, 10]이고 인덱스의 범위가 [0, 9]인 것은 맞지만,
문장별 수치구체화 과정을 통해 인덱스값 = [0, 배열크기 - 1] 이라는 정보를 소실하면서
경고를 발생시킨 것이 아닌가 생각됩니다. ㅡ.ㅡ;;

int
func4()
{
    int *ia;
    int n;
    int n0;
    
    n0 = random() % 10 + 1;
    ia = (int *)malloc(n0 * sizeof(int));
    n = random() % n0;
    printf("ia[%d] = %d\n", n, ia[n]);
}

새버젼도 아직 갈길은 멀어보이네요.

#include <string.h> 

int
main(void) 
{ 
    int* p, *q=(int*)0;
    *p = 0;
    *q = 0;
    memset( (void*)0, 0, 256 );
    return 0;
}

게다가 다중 스레드까지 고려한다면
메모리 침범만 검사하기도 벅찰것 같은데요...

airac의 목적은 모든 프로그램의 버그를 static 하게 찾아내는 것이 아니라고 생각됩니다. 홈페이지를 보다보니 아래와 같은 링크가 있어서 첨부합니다.

http://ropas.snu.ac.kr/2005/airac5/vs-airac/

위와 같이 static analysis의 장점인 빠른 속도로 기존의 컴파일러/에러 체크 방법으로 작성한 거대 공개/상용 프로그램들의 소스를 체크하여 숨겨진 시한폭탄같은 이런 버그들을 발견할 수 있다면 그로써 가치가 충분하다고 생각됩니다. 따라서 '에게 이런 종류의 버그들은 발견못하네?' 가 아니라 '이런 종류의 버그는 다 잡아낼 수 있다고?!' 라고 놀라는 게 더 정확한 반응이 아닌가 싶습니다. 그 정도만 해도 디버깅 범위를 상당히 좁혀나갈 수 있으니까 말입니다.

사실 이런 종류의 런타임 에러들은 발전된 프로그래밍 언어로 코딩시에는 피할 수 있는 종류의 에러들이므로 아무래도 기존의 작성된 코드들의 유지/보수와 관련있는 프로젝트가 아닌가 생각됩니다.

주제넘게 개발진도 아닌 제가 프로그램의 목적이나 용도를 말했는데 이건 모두 제 개인적인 생각임을 밝혀둡니다.

좋은 null pointer 테스트 고맙습니다.
사실 테스트하신 것은 airac5 기반으로 쉽게 찾을 수 있는 부류의 것입니다. (새버전...)
(진짜 어려운 문제는 다른곳에 있습니다: 동시에
허위경보줄이기 & 분석비용줄이기 & "안전함" 유지하기)

비슷하게, 저희를 괴롭히는 테스트를 올려주시면 고맙겠습니다.
특히, 실제 현장에서 골치아팠는데, airac5가 별 효과를 내지 못하는 경우 말입니다.
airac5 돌려보니 너무 많은 허위경보(false alarm)을 내거나 분석시간이 너무 오래걸리는 경우등.

이곳이나 아니면 airac5 forum:
http://ropas.snu.ac.kr/phpbb2/viewforum.php?f=2 입니다.

-이광근

"문맥상 적합" = "프로그래머의 의중"이라고 이해하겠습니다.
하면 airac5가 판단하지는 못합니다.

그러나 가능한것은,
프로그램의 어느 메모리를 어느 식들이 접근해서 값을 쓰게되는 지는
자동분석 가능합니다.
이것도 충분히 디버깅에 도움이 되는 정보겠군요.
고맙습니다.

아뭏튼, buffer overrun관련 저희가 괴로와 해야 할
현장의 c 소스를 올려주시면 대단히 고맙겠습니다.
-이광근

이런 건 어떨까요...

#include <stdio.h>
#include <stdlib.h>


void *
xmalloc(int size)
{
    void *ptr;

    ptr = malloc(size);
    if (ptr == NULL) {
        exit(1);
    }
    return ptr;
}

void
xfree(void *ptr)
{
    if (ptr)
        free(ptr);
}


void
set_arr(int *arr, int from, int to, int val)
{
    int i;

    for (i = from; i <= to; i++) {
        arr[i] = val;
    }
}

void
set_arr2(int **arr, int from1, int to1, int from2, int to2, int val)
{
    int i, j;

    for (i = from1; i <= to1; i++) {
        for (j = from2; j <= to2; j++) {
            arr[i][j] = val;
        }
    }
}



int
main()
{
    int *arr;

    // 1. memory allocation with a customized function
    arr = (int *)xmalloc(10 * sizeof(int));
    arr[10] = 0; // false negative
    xfree(arr);

    // 2. highlight where?
    arr = (int *)malloc(10 * sizeof(int));
    set_arr(arr, 0, 1, 0);
    set_arr(arr, 0, 2, 0);
    set_arr(arr, 0, 3, 0);
    set_arr(arr, 0, 4, 0);
    set_arr(arr, 0, 5, 0);
    set_arr(arr, 0, 6, 0);
    set_arr(arr, 0, 7, 0);
    set_arr(arr, 0, 8, 0);
    set_arr(arr, 0, 9, 0);
    set_arr(arr, 0, 10, 0); // highlight me, plz~
    free(arr);

    // 3. some tricky pointer operation
    arr = (int *)malloc(10 * sizeof(int));
    set_arr2(&arr, 0, 0, 0, 10, 0); // false negative
    free(arr);

    return 0;
}

2. 호출된 함수에서의 오류 위치만을 표시해 주는 게 좀 난감할 수 있습니다. 그 함수를 호출하는 곳이 백만 군데 정도 된다면 대략 좌절입니다. 궁극적으로는 call-trace를 표시해 줘야 하지 않을까 싶습니다.

3. 장난 삼아 만든 경우이지만, 유사한 루틴을 가끔씩 실제로 볼 수 있습니다.

----

교수님께서 여기까지 직접 확인하시는군요- 멋진 툴로 발전시켜 주시길 기대하고 있겠습니다!

// var.c
int i = 0;

// tt.c
extern char i;