Study- MSC/Computer2008. 10. 1. 21:27
  예전에 비트맵을 분석해보려고 이것 저것 소스를 보다가 재밌는 코드를 본 적이 있다.
  비트맵을 파일 입출력으로 직접 읽어서 분석하는게 아니라 메모리를 할당한 후 파일에서 메모리로 전체를 복사시킨 후 파일은 닫고 메모리의 내용만 읽는 코드였다.
  흥미로운 방식이였다. 그러면서 든 생각이 그럼 바로 파일 입출력을 하는 것과 메모리에 올려서 하는 방식과 무엇이 다를까? 하는 것이였다. 그리고 이번 휴가를 통해서 바로 시험해 보았다.

실험 방법 : 어느정도 용량이 되는 TEXT 파일을 스트림에서 직접 읽는 방식과 메모리에 올려서 읽는 방식의 속도를 비교

소스 코드는 다음과 같다.


#include <stdio.h>
#include <stdio.h>
#include <windows.h>//GetTickTIme 호출

#define COUNT 1000000

//메모리를 통해서 파일을 읽는 것과 직접 FIle Stream에서 읽어 오는 것의 속도 비교

int main(void)
{

    FILE* fp;//파일을 읽을 파일 포인터
    char read[100];
    char a;
    char* str;

    unsigned int FileSize;
    int StreamTime;//스트림으로 읽었을 때의 시간
    int MemoryTime;//메모리로 했을 때의 시간

    //읽을 파일을 만드는 부분
    unsigned long i;

    if(fp = fopen("TestFile.txt","w"))
    {
        for(i = 0 ; i < COUNT ; i++)
        {
            fputs("TestFileText\n",fp);
        }

        fclose(fp);
    }


    //File Stream에서 읽기
    if(fp = fopen("TestFIle.txt","r"))
    {
        StreamTime = GetTickCount();  //시간 재기
        while(!feof(fp))
        {
            fgets(read,80,fp);
            printf("%s",read);
        };
        StreamTime = GetTickCount() - StreamTime;
        fclose(fp);
    }

    //Memory에 올린 후 읽기
    if(fp = fopen("TestFIle.txt","r"))
    {

        MemoryTime = GetTickCount();//재기 시작

        fseek(fp,0L,SEEK_END);
        FileSize = ftell(fp);//파일의 크기를 알기 위해 끝까지 이동 후 크기 저장

       
        str = malloc(sizeof(char) * FileSize);//크기 만큼 메모리 할당
        memset(str,0,FileSize);
        fseek(fp, 0L, SEEK_SET);//파일의 처음으로 이동
        fread(str,sizeof(char)*FileSize,1,fp);//파일을 메모리에 복사

        fclose(fp);//다 읽었으니 파일을 닫는다.

        printf("%s",str);//읽은 내용을 출력

        MemoryTime = GetTickCount() - MemoryTime;//측정 끝
        printf("소요 시간 : %d Tick\n",MemoryTime);

        free(str);//메모리 해제
    }

    printf("Stream : %d\nMemory : %d\n",StreamTime,MemoryTime);

    return 0;
}

실험 결과

내용 출력 하는 시간 포함해서 결과는

스트림 직접 읽기 : 45542 Tick
메모리 올려서 읽기 : 10656 Tick

약 23%정도 메모리로 읽는 방식이 더 빨랐다.
프린트 시간을 뺴서 계산 하면 더 정확한 결과를 얻을 수 있었을 것이다.

이번 실험으로 역시 메모리에 올려 놓고 돌리는 것이 속도 면에서는 더 효과적이라는 걸 직접 볼 수 있었다. 이런 것을 이용하면 Progress를 계산한다던가, 리소스 같은 것을 올려 놓고 읽으면 Loading TIme을 줄일 수 있을 것이다.
 
이렇게 메모리에 올리는 방식을 사용하는 예로 더블 버퍼링을 예로 들 수 있을 것이다. 더블 버퍼링도 메모리에 뿌릴 내용을 미리 그려 놓고 화면에 한꺼번에 뿌리는 방식을 이용한다.


그런데 의문점이 있어. 저렇게 하면 효과는 있지만 실제로 메모리에 대용량으로 할당하는 식으로는 잘 안할 거라고 생각해.
malloc()이런 걸로 몇 MB나 하는 걸 할당하는것도 무식하다고 생각하고 요즘 프로그램들 용량 엄청나잖아. 그런걸 보조하기 위해서 페이징같은 것이 있는거고

그래도 위 방법은 어느 정도 규모의 리소스 파일들을 읽을 때는 유용한 방법이 될 거라고 생각하는데, malloc같은 할당 함수 위에 다른 방법은 없는건지, 그리고 HEAP 영역 말고 이런 상황같은 것을 위한 다른 할당 가능 공간은 없는 건지 궁금하다. 한번 알아 봐야 겠다.


Posted by 머리
Study- MSC/Computer2007. 12. 19. 02:11
이번에 쿠분투를 설치하는데 성공하고 이것저것 만져 보는 중에 우연히 Wine라는 놈을 건들여 보게 되었다.

전에 어떤 커뮤니티 사이트에서 Wine라는걸 들어보기는 했는데 이게 어떤것인지는 전혀 몰랐었는데, 실수로 눌러서 실행시켜 보니 윈도우 어플을 띄워주는 것 같았다.

신기해서 한번 여러가지로 테스트해 보았다.

1. 알송
사용자 삽입 이미지

제대로 실행 되었고, 음악도 정상적으로 나왔다. 다만 소리가 좀 작게 나왔다. 최대로 음량을 높였는데도 겨우 들을 수 있었다. 그리고 종료시에 오류가 나는 듯 했다.

2. 인터넷 익스플로러.
IE의 경우에는 따로 리눅스용 버전이 있어서 설치를 하였다.
사용자 삽입 이미지
뭐 윈도우에서 쓰는 IE랑 똑같다고 보면 된다. 익숙한 프로그램이라 사용은 편하겠지만 절대 사용안할거다. 왜냐하면 이미지까지는 괜찮은데 플래시가 있는 웹 페이지는 엄청나게 느렸다. 네이버 초기화면 로딩하다가 세월 다 가는줄 알았으니..

3. Mamelon
이번엔 게임을 한번 시도해 보았다. DirectX같은걸 이용할건데 제대로 되려나 싶었는데
사용자 삽입 이미지

Mamelon으로 KOF2002를 실행시킨 모습



놀랍게도 매우 깔끔하게 실행이 되었다. 윈도우에서 실행한것과 다름 없이 제대로 게임 실행이 가능했으며 속도 문제도 없었고, 소리도 말끔하게 났다.

4.Warcraft3
마메론도 동작했으니 Warcraft3는 어떨까하고 실행시켜 보았는데, 흠.. 제대로 실행 되지 않았다. 뭔가 전체화면으로 되긴 되는데 실행이 안되었다. 인터넷으로 검색해보니 가능하다고는 하는데.. 뭐 이놈한텐 별 관심이 없으니.. 나중에 스타나 하게 되면 알아봐야겠다.

이외에도 네이트온도 실행이 가능했었다. Microsoft사의 개발툴도 실행시켜 봤는데 VB,VC둘다 6,2005버전 모두 실행이 되지 않았다.

상당히 흥미로운 프로그램이였다. 한번 더 알아봐서 실행가능한 프로그램들을 확장시켜 나가봐야 겠다.

Posted by 머리
Study- MSC/Computer2007. 10. 26. 19:46
와.. 드디어 우분투를 성공적으로 설치하는데 성공하였다. 일단 스크린샷부터.
사용자 삽입 이미지


  멋지지 않은가? 인터넷도 완벽히 되고 한글도 완벽히 된다. 그리고 무엇보다 가장 좋은 것은 네이트온을 까는데 성공하였다!!


  이로써 노트북으로 게임을 잘 하지 않는 나로써는 윈도우를 사용할 이유가 거의 사라졌다.. 개발용은 이놈이 더 강력하고, 인터넷도 이놈으로 하면 되고 네이트온도 무리없이 되고.. 좋군. 아 참고로 이 글도 우분투에서 파이어폭스를 통해서 남기고 있는 것.

  참 까는데 고생 많이 했다. 한글도 제대로 안되고, 네이트온 깔때도 고생 많이 하고.. 그래도 지금 이렇게 되는 것 보니까 그동안 고생한것이 하나도 아깝지 않다. 또 배운것도 많았다. su랑 sudo가 어떤것인지 잘 몰랐는데 이제는 어렴풋히 잡히는 것 같고, 에러메세지 엄청 확인하고 이것 저것 해보면서 고쳐 나가면서 좀 익힐 수 있었다.

  참 이놈이 신기한건 멀티 데스크톱이라 해야 하나? 한번에 네 개의 화면이 사용 하능하다. 듀얼 모니터가 아니더라도 참 넓게 쓸 수 있다는 말이다. 좋구나.. 글꼴도 꽤 이쁘고..

  음.. X윈도우로 이걸 사용하면 실력이 안늘겠지? 웬만하면 콘솔로 놀아야겠지만, 아무튼 우분투 공부, 기대된다 얼른 개발환경 갖추고 공부해야지!!
Posted by 머리
Study- MSC/Computer2007. 10. 21. 11:20

  하아.. 이 시험기간에 대박으로 사고쳐 버렸다..

  무슨 생각이였는지 우분투를 깔아보려 하다가 하드를 완전히 날려먹었다.

  우분투까지는 제대로 깔렸다. 대충 세팅하고 윈도우로 재부팅하려 했는데 이거 뭐... 윈도우가 맛이 가 버렸네.. 여기까지는 괜찮았다. 그냥 윈도우 덮어 깔면 되니까..

  문제는 여기서부터였다. 윈도우를 덮어 깔고 나니까 노트북이 이상하게 OS를 못알아채네? 우분투, 윈도우 둘다.. 허..무슨일이지 이건.. 아무리 파티션 설정하고 별짓을 해봐도 제대로 되지가 않는다.. 우분투는 알아서 잘 깔리는데 윈도우를 깔려니까 왜 파티션은 익식해놓고 거기에 깔리지는 않는거지? 우분투랑 같이 깔으려고 하면 윈도우가 항상 말썽이더라.

  결국은 6시간동안 별 짓을 다하다가 새벽 4시에 윈도우만 달랑 깔고 끝냈다.

  결과는 파티션 만지다가 D드라이버까지 다 날려먹고.. 진짜 슬프네.. 1년동안 공부한 소스코드 2GB를 날려먹었다. 다른 프로그램은 어떻게 구하면 되지만 그건 진짜.. 아..

  지금은 파티션을 20 20 20 20 1 19GB 이렇게 나눠서 첫 20GB는 OS용 20GB 3개는 백업용, 1GB와 19GB는 리눅스용 스왑과 루트.. 아직 리눅스는 또 고장날까봐 겁나서 깔지도 않았지만..

사용자 삽입 이미지

파티션 나눠 놓고 포맷 중

  사진은 파티션 나눠놓고 아직 포맷을 안해놔서 포맷 중인 사진. 저런걸 3개 해야 한다. 언제 다해?

  시험기간에 대박으로 사고 하나 쳤구나..
Posted by 머리
Study- MSC/Computer2007. 9. 17. 01:23

  마우스가 표준 입력 장치로 보편화 된 지도 오래 되었지만 아직까지도 키보드는 필수이다. GUI로 마우스가지고 웬만한 작업은 다 한다지만 그래도 마우스로 일일히 갖다대는 것보다 단축키가 더 편할 때가 많다.
  그렇다고 모든 단축키를 다 외울필요는 없고, 단축키를 쓰면 오히려 더 불편한 경우도 있다. 자기에게 가장 알맞는 단축키를 쓰면 되지.
  다음은 내가 평소에 컴퓨터를 하면서 자주 쓰는 단축키 들이다.

1. Microsoft Internet Explorer
새로 고침 - F5
주소창 : F4 -> ESC (바로 주소창에서 주소를 입력할 수 있다. 가장 많이 쓰는 단축키.)

2. SK Communications NateON Messenger
기본 연락(쪽지,대화 중 기본 설정 값) - Enter
쪽지 보내기 - Ctrl + B
채팅 하기 - Ctrl + M

3. 한글과컴퓨터 한글
문단 설정 - Alt + T
줄 설정 - Alt + L
표 만들기 - Ctrl + N,T

4. Microsoft Visual C++ 6.0
컴파일 - F7
빌드 & 실행 - Ctrl + F5
오류 위치 이동 - F4
브레이크 포인트 설정/제거 - F9
디버깅 모드 실행 - F5
한 줄씩 실행 - F11
한 블록 씩 실행 - F10
전체 선택 - Ctrl + A
자동 들여쓰기 - Alt + F8

5. Microsoft Visual Basic 6.0
실행 - F5
한 라인 씩 실행 - F8
컨트롤 추가 - Ctrl + T

6. GameHI Sudden Attack
빠른 시작 - Ctrl + Q
준비하기 - Ctrl + R
시작하기 - Ctrl + S

7. Microsoft WIndows XP & etc
파일 메뉴 - Alt + F
복사 - Ctrl + C
잘라내기 - Ctrl + X
붙여넣기 - Ctrl + V
실행 취소 - Ctrl + Z
작업 전환 - Alt + Tab
작업 관리자 - Ctrl + Alt + Del
바탕화면으로 - Windows Key + D
블록 설정 - Shift + Ctrl + 방향키
떨어져 있는 복수 개의 파일 선택 - Ctrl + 방향키로 선택 - Space Bar
끝 페이지까지 가기 - End
첫 페이지까지 가기 - Home
휴지통에 넣지 않고 지우기 - Shift + Del

  이정도? 그리 많지는 않다. 거의 쓰는 프로그램들이 정해져 있으니.. 빠르다 싶은 거라기 보다는 익숙해서 쓰는 것이 옳을 것이다. 참고로 나는 마우스가 5버튼이라 4,5버튼을 이용해서 빠르게 앞 페이지와 뒤 페이지로 이동이 가능하다(ex : IE의 뒤로, 앞으로 버튼)

Posted by 머리
Study- MSC/Computer2007. 9. 9. 01:40

  유닉스 공부 해보려고 도서관에서 책 빌려서 깔아 보려고 했는데.. 어제는 빌린 레드햇 책 부록 CD가 맛이 가서 CD 부팅이 안되길래 오늘 다시 빌리러 가니까 레드햇 책이 없더라.. 그래서 할수없이 페도라 책 아무거나 빌려서 거기걸로 깔아 보려고 했는데.. 정말.. 마소의 노예라는 말이 확실히 느껴지더라.

  파티션 하나 잡아 보는데 두시간이 걸렸다. 별 짓을 다해봐도 도저히 파티션이 두개 이상은 안잡히는 것이다. 이거 혼자서 끙끙대 본다고 한 두시간 있다가 논리파티션 나누면 간단히 되는걸 알았다. 그런데 문제는 이거 하다가 용량 잘못 계산해서 다시 파티션 나누고 다시 깔았다는거.. 젠장..

  어찌 어찌 설치 하니까 이번엔 무선랜이 안잡히네? 노트북이라 무선으로 인터넷 하는데 좀 치명적이다. 아직 지원 안하는가 보다 하면서(참고로 드라이버 이름은 Intel(R) PRO/Wireless 3945ABG Network Connect이더라) 그냥 콘솔에서 대충 갖고 놀면서 살자 하는 식으로 콘솔로 들어가보니 어랍쇼? 이상하다.. 이상한 에러메세지가 계속 뜨네..메세지를 굳이 C로 표현하자면

while(1)
{
printf("sky2 어쩌고 phy 어쩌고 read\n");
}

  에러 메세지 간단했는데 기억 하기 귀찮아서.. 뭐 아무튼 저런식으로 계속 에러 메세지가 뜬다. 겨우 겨우 X윈도우로 넘어와서 시스템 종료해도 저 메세지는 계속 뜨네.. 종료할 생각도 안하고..

  아 어떡하지.. 그냥 페도라 날릴까.. 레드햇 구해서 해버려? 으휴..

Posted by 머리
Study- MSC/Computer2007. 8. 31. 15:47
디버깅과 탐정놀이

SW 엔지니어로서, 디버깅은 사실 탐정놀음과 비슷합니다.
어디가 원인인지 찾아내는 게임...

디버깅 기법을 탐정들의 스타일에 따라 분류해 봤습니다.

- 하드보일드형

모든 문장과 문장 사이에 printf를 추가한다.
어떤 문장이 문제를 일으키는지 끈기 있게 추적한다.
한줄씩 따라가다보면 문제가 되는 문장을 찾을 수 있기 마련이다.

가끔 담배를 피우러 나가는 것을 잊지 않는다.
잠은 사무실에서 아무렇게나 자는 편이 좋다.

- 안락의자형

가만히 앉아서 모니터를 뚫어져라 응시한다.
전혀 움직이지 않고 몇시간이고 코드를 쳐다본다.
가끔 혼자서 뭐라고 중얼중얼 거리기도 하는데 옆사람은 못알아 듣는다.
그러나 갑자기 마구 타이핑을 하더니 버그를 잡아낸다.

다 좋은데 옆에서 보기엔 미친것 같다.

- 완전범죄형

프로그램을 짤 때 부터 애시당초 머리속으로 무척 많은 생각을 한다.
코드 한줄 한줄 마다 모든 부가효과(side effect), 예외상황(exception), 잘못된
입력을 염두에 둔다.
심지어 멀티 슬레드 코드로 사용되는 경우도 생각하고, 에러 리턴 코드도
구조적으로 만든다.

버그없는 코드는 완전범죄만큼이나 불가능 하다.
결국엔 항상 사소한 것에서 문제가 발생한다.

- CSI 과학수사대형

소스 디버거의 브레이크 포인트는 기본이다. 조건부 브레이크-포인트는
물론이요
스택 트레이스를 한다.
퓨리파이어 같은 소프트웨어로 메모리 leakage도 검사한다.
gprof나 VC-profiler로 프로그램의 병목도 찾아낸다. spi++같은 것도 능숙하게
사용한다.

다른 사람보다 항상 제일 늦게 디버깅을 마친다.

- 미스 마플형

엔지니어들이 디버깅하다 안되서 휴게실에 나가 담배를 태운다.
이런저런 문제점들에 대해 논의를 하고 있는데 옆에서 쓰레기통 비우던
아줌마가
말한다.

"그럴땐 대게 클래스 destructor에서 널 포인트를 지우는 바람에 그렇게
되는데..."

- 명탐정 코난형

디버깅을 시작한다.
어려운 코드를 들여다 보니 잠만온다.
일어나면 코드가 디버깅 되어 있다.

옆에서 네이버 지식인을 습격하고 있는 초딩이 의심스럽다.

- 소년탐정 김전일형

버그의 원인이 될만한 모듈을 고립시킨다.
코드를 고치려다 버그가 하나 더 발생한다.
버그가 하나 더 발생한다.
버그가 하나 더 발생한다.
이건 연쇄 버그다.
시스템이 크래쉬 한다.

....어쨌거나 버그는 이 안에 있다.

- 에큘 포아로형

주위의 프로그래머를 전부 모아놓고 자기가 버그를 잡기까지의

추론 과정을 발표한다. 각 함수 별로 버그가 될 수 없는 이유를

증명하는 식으로 하나씩 소거한다. 결국 마지막에 남는 놈이 버그이다.

자신의 회색 키보드에 대한 자랑을 빼놓지 않는다.

- 브라운 신부형

멍청한 눈으로 editor 프로그램을 띄웠다가 닫았다가를 반복한다. 가끔은
웹브라우저를 띄워 웹서핑을 하다가도 뭔가 깜빡 잊고 있었다는 것처럼 다시
키보드를 두드린다. 디버거를 실행하지만 명령어를 기억하지 못해서
다시 종료하려고 하나 종료하는 것도 잘 몰라서 아예 터미널 창을
날려버리는 등의 삽질을 계속 해댄다. 모르는 사람이 보기엔 개발 경력이
전혀 없는 초짜 개발자로 보인다.

그러다가 갑자기 프로그래머의 본성 및 심지어는 프로그래밍 철학에
대해서 중얼거리면서 프로그래머가 버그를 만드는 심리를 꿰뚫는 날카로운
통찰력으로 단번에 버그를 잡아낸다. 그러나 결코 요행수로 찾아내는
게 아니라 왜 그 버그가 발생하는지를 합리적으로 설명해낸다.

- 파일로 반스 형:

남들이 원인이라고 하는 부분은 절대 원인이 될 수 없다고 한다.
이유를 물으면 "탭 사이즈를 4로 쓰는 사람은 그런 버그는 만들지
않아" 따위의 말을 하며 디버깅도 프로그래머의 심리를 분석해야
한다고 주장한다. 처음부터 원인을 다 알고 있는듯이 굴지만 절대
말해주지는 않는다.


- 엘러리 퀸 형:

소스 코드를 찍어서 뿌려 놓고는 "독자에게 도전한다. 단서는
공평하다!"고 외친다. -_-


- 셜록 홈즈형 :

잡으라는 버그는 잡지 않고 파일 이름과 헤더만 보고 뭐 하는 프로그램인지
맞추기 놀이 따위나 하고 있다. 디버깅할 때는 꼭 옆에 의대 친구를 앉혀
놓고 작업한다. (코멘트와 문서 작성은 모두 의대 친구에게 시킨다.) 버그가
잡히지 않으면 갑자기 바이올린을 꺼내 연주한다.
...
의대 친구가 개업한 이후엔 디버깅하다 때때로 "수능 봐서 의치한..."이라
중얼거린다.

출처 : 우균 교수님 홈페이지 : http://pl.cse.pusan.ac.kr

Posted by 머리
Study- MSC/Computer2007. 8. 29. 01:52

  몇 분 전에 있었던 일이다.


  MSYS랑 MinGW깔아서 연습하고 있었는데

  실수로 무한 루프를 돌게 코드를 짰다.


  그렇게 컴파일 하고 실행시키니 역시 빠져나오질 못했다. 그래서 그냥 응용프로그램 끄듯이 MSYS를 껐었다. 처음엔 아무 이상이 없었다.


  그러다가 무한 루프가 도는 이유를 정확하게 잡지 못하고 디버깅하고 컴파일하고 실행시키길 3번..


  갑자기 컴퓨터가 엄청나게 느려졌다. 왜 이러지 싶었는데 혹시나 그 프로그램이 아직도 돌아가고 있나 싶어서 작업 관리자의 프로세스를 확인해 보았다.


  역시나.. 그 프로그램이 무한루프를 돌면서 CPU를 50 가까이 잡아먹고 있었고, 그게 3개나 켜져 있었다. 당장 꺼버리니 나아졌다.


  아무리 메신저랑 웹 브라우저 몇 개를  켜 놓고 있었다지만 램이 1GB나 되었는데 그런 상황까지 벌어 졌었다.


  보통 윈도우 상에서 콘솔 기반 프로그래밍을 할때,  포인터를 잘못 만진다거나, 무한루프가 돌거나, 동적 할당을 해제 안했다거나 하는 오류를 범하면 웬만한건 윈도우가 알아서 종료시켜 준다. 대표적으로 MSVC에서 포인터 잘못 만졌을때 윈도우에서 오류 메세지를 보여주면서 강제로 종료시켜 버린 것은 많이 봤을 것이다.  하지만 모든 컴퓨팅 환경이 그렇게 친절하다고 생각하면 큰 오산이다. 예를 들어 예전 도스 환경이나 유닉스 쉘 환경에서 프로그래밍 하던 프로그래머들이 이런실수를 범했다면 어떘을까? 단순이 프로그램 하나가 강제 종료되는 수준이 아닌 자칫하면 시스템 자체가 다운되어 버리는 사태가 발생할 수 도 있을 것이다. 특히 동적 할당 같은 경우는 해제를 잘 안해 주면 처음엔 프로그램이 잘 돌아가다가 나중에 다운되어 버리는 기막힌 상황이 발생한다. 이런건 디버깅위치를 찾는것도 어렵다.


  사실, 공부할 때 이런 에러들을 겪으면서 이게 만약 윈도우 환경이 아닌 다른 환경이였다면 어땠을까? 하는 생각을 하긴 했었다. 그런데 이렇게 실감을 하니 더 무서워졌다. 좋은 경험 하나 했다. 앞으론 더 섬세히 코딩하는 습관을 들여야겠다.

Posted by 머리
Study- MSC/Computer2007. 8. 29. 01:51

  타입 캐스팅 관련 부분을 읽고 있다가 쉬어가는 식으로 아리안 5호의 폭발 사고 이야기가 있길래, 인터넷에서 찾아 본 내용이다.

 

  1996년 4월 프랑스에서 발생한 아리안(Ariane) 5호의 폭발사고는 소프트웨어 안에 숨어있는 버그의 위력을 실감할 수 있는 사례다. 5억 달러에 달하는 거금이 투입된 유럽의 상업용 우주선 아리안 5호는 발사된 지 불과 40여초 만에 공중에서 폭발하여 수많은 사람들을 망연자실하게 만들었다. 당시 사고로 깊은 충격을 받은 유럽 우주기구(Europe Space Agency)와 프랑스 우주연구센터는 즉각 조사팀을 구성해 로켓의 폭발 원인을 찾아내기 위한 정밀조사에 착수했다. 이 같은 정밀조사를 통해 채 한 달도 안 돼 폭발 원인이 드러났다. 5억 달러를 허공에 흩뿌린 충격적인 사고의 원인이 에이다(Ada)로 작성된 소프트웨어 내부에 존재하는 버그로 밝혀졌다. 그 당시 조사팀의 보고 내용이 폭발 사고를 일으킨 소프트웨어가 우주선의 운항과 직접적인 연관성이 없었다고 밝혀져 더 큰 충격을 주기도 했다.
사고는 64비트 숫자 값을 16비트 정수로 변환하는 과정에서 일어났다. 문제가 된 모듈은 보다 작은 수에 한해서 정상적으로 작동하는데 그 보다 큰 수가 입력되는 바람에 수치 오버플로우(numeric overflow)가 발생하였다.
이 오버플로우는 우주선을 운행하는 중앙 소프트웨어에게 터무니없이 잘못 계산된 고도가 전달되도록 만들었고, 그 이상한 값을 읽고 당황한 소프트웨어는 눈 깜빡할 사이에 자동 폭발 장치를 작동시켰다.


출처 : http://blog.naver.com/hippo1969?Redirect=Log&logNo=20035014367

 

  어처구니 없는 사고가 아닐 수 없다. 참고로 말하자면 이 부분은 프로그래머가 이 부분의 코드를 작성한 것이 아니라, 아리안 4호의 동일 기능 부분의 코드를 그대로 복하사면서 생긴 사고라고 한다. 무조건적인 코드 복사의 남발이 부른 결과인 것이다. 같은 기능이라도, 로켓의 스펙이 달라졌는데 좀 더 체크를 했으면 이런 어이없는 사고는 발생하지 않았을 것이다.

Posted by 머리
Study- MSC/Computer2007. 8. 29. 01:49

  얼마 전에 동아리 홈페이지에다 올려 놓은 글이 있었다.(이거 말했다간 익게에 내가 올렸다는거 들키는데..)


  if(조건 a && 조건 b) 이렇게 되어 있을 때 조건 a가 False라면 조건 b를 확인할까 안할까?


  답은 확인하지 않는다이다. 효율을 따져보면 당연한 이야기일 것이다. a가 틀렸는데 굳이 뒤에까지 체크할 필요가 없으니까. 이렇게 연산할 때 한쪽에서 그 연산의 값이 판단되면 연산을 멈추는 규칙을 숏 서킷 규칙(Short Circuit Rule)이라고 한다. &&연산자 이외에, ||도 마찬가지이다.


  이 규칙은 프로그래밍 언어가 도입되기 전에 논리 회로에서 사용되고 있는 것이라고 한다.

  그런데 이런 규칙이 오히려 프로그래머에게 혼동을 줄 수 있는 경우가 있다. 그래서 한가지 팁이 있다면, &&으로 비교하지 않고, 비트 연산자인 &로 비교하면, 숏 서킷 규칙이 적용되지 않는다.

Posted by 머리