추억속의 버그 : C, C++

저는

먼저 100개 짜리 배열 하나 선언 하고

for 루프를 도는데

strData[i] = "Test";

이렇게 해야 할것을

strData[100] = "Test";

이렇게 해 버려서 자꾸 에러 나더

라고요 그거 못찾아서 하루 종일 헤매고

현상금 까지 걸었던 기억이 있네여 ㅋㅋㅋ

요런 실수들 많이 할 거 같은데요.

if ( i = 100 ) {
...
}

원래는 조건문에 i == 100 으로 쓰려고 했던 건데, 실수로 = 를 하나 빼먹은 거죠...
문법적으로는 정상적인 할당이니까 에러도 발생하지 않는데, 실행해 보면 엉뚱한 결과가 나오구요.

그래서 지금은

상수 == 변수

형태로 쓰는 습관을 들였지요. 실수하면 에러가 발생되도록...

if ( 100 == i ) {
...
}

아래 글들은 대개 Syntatic Error/Bug인데, 이런건 뱐 스트로스트럽이 지은 C++ programming language만 제대로 읽었다면 다 해결할 수 있는 문제들고, 게다가 조금의 코딩 집중력만 향상시키면 실수가 다시 되풀이 되지는 않죠.

진짜 찾기 어려운건 Semantic Error/Bug죠.

때로는 어중간한 Bug도 있는데, 예를 들면,

if (조건1) if (조건2) {} else {};
이것을
__ if (조건1)
__ if (조건2) {}
__ else {};
이렇게 Indentation한다고 해서,
__ if (조건1)
__ {if (조건2) {}}
__ else {};
이렇게 되는 것이 아니죠.
이것은 단지
__ if (조건1)
__ if (조건2) {}
__ else {};
이것입니다.
즉 조건1에 대한 else는 없는 것이죠.

8년전에 이것때문에 머리 아파했던 기억이 나는군요. 그 후 구문이 하나만 들어간다하더라도 왠만해서는 Block을 명시적으로 지정합니다.

C를 쓰던 다른 언어를 쓰던 무슨 언어이든지간에 개인적 원칙이 있습니다. "조건이 있는 곳에 Block이 간다"라는 것이죠.

#include

class Foo {
public:
Foo(int x = 1, int y = 2);
void bar(int w = 20);
private:
int z;
};

Foo::Foo(int x = 1, int y = 2) {
z = x + y;
std::cout << z << endl;
}

void Foo::bar(int w = 20) {
std::cout << z + w << endl;
}

int main() {
Foo foo;
foo.bar();

gcc 2.95 에서는 컴파일이 잘 됩니다.
근데..요즘쓰는 gcc3.2 에서는 컴파일 시키면
foo.cpp:11: warning: default argument given for parameter 1 of
`Foo::Foo(int = 1, int = 2)'
foo.cpp:5: warning: after previous specification in `Foo::Foo(int = 1,
int = 2)'

이런 에러가 뜹니다...
즉 메소드 선언할때 값을 정해 주면 막상 그 함수에 대한 내용일때는 쓰면 안됩니다..

예전에 2.95에서는 잘 컴파일 되던것이 3.2 에서는 컴파일 되지 않더라구요...

참고 하세요...

누구나 겪을 수 있었던 경험이겠지만, 초기화 하지 않은 변수 덕분에 생기는 버그는 참 암담하더군요.

int a;
...
if (a == ...) ...

아주 흔한 버그죠? 하지만 요즘은 컴파일러가 잡아줍니다.

이런 초기화도 관련되어 있겠지만, 변수가 계속 재활용 되는 곳에서는, 특히 재활용 변수가 많다면 문제가 좀 심각할지도 모르죠.

저 같은 경우는 변수 테이블을 운영하는데 이 테이블을 초기화 해 두는 루틴이 없으니 몇몇 부분에서 말썽을 일으키더군요. 그래서 초기화 모듈을 만드는데 멤버 변수들이 몇백개나 되니 눈이 삥삥;; -_-; 이런건 초기 설계시에 잘 해야 됩니다.;;

버그 아닌 버그인듯한 이야기 하나.
Visual-C++로 프로젝트를 하나 만들어서 컴파일 했습니다. 그 프로그램은 현재 디렉토리에서 config 파일을 읽어옵니다. 기본적으로 실행파일이 생성되는 Debug 폴더에 config 파일을 넣고 돌려보니 파일을 읽을수가 없네요. 도데체 왜 이럴까 하고 수 차례 trace를 걸었지만...
...
알고봤더니 working directory가 설정되어 있지 않아서라는...
역시 버그 처럼 보이는 것도 유저불량입니다. ;-)
--
Seo, Hee-Seung.
http://anitype.net/

버그는 그게 문제를 크게 일으키든, 작게 일으키든,
쉽게 잡든, 어렵게 잡든 잡고 나면 별게 아닌 것
같습니다. 버그란게 딱 이거다하고 찝어 말할 수
있다기 보다는 같은 종류의 버그라도 프로그램
환경과 여러 정황에 따라 서로 다르게 나타나기
때문에, 추억속에 버그나, 악몽같은 버그는 무수히
많지만, 그걸 기억해서 적어내는 건 버그 잡는 것
만큼 어렵네요. :-)

오래된 이야기지만 BC 3.1을 사용 할 때의 일입니다.
코딩 하기 전에 프로그램 블럭을 여러개로 만들고
작업을 하다보면 어느듯 소스코드가 1000라인을 훌쩍 넘어 서버리는 일이 발생하게 되는데..
int i;
라고 선언 된 곳에 Error 표시가 되면서
i가 선언 되지 않았다고....
한참을 헤매다가 라인 수를 보면 (ㅡ.+;) ...
결국 900라인 이하까지 줄여서 컴팔 하는데 의도 하지 않은 프로그램 블럭이 또 생기는 바람에 또한번 잔머리..
머리가 나쁘면 손발이 고생한다나..
...

이만용씨의 newbie 테스트는 어떠한가요?

/* newbie test */

#include /* for fprintf, stdout */

int
main()
{
char *ptr;

fprintf(stdout, "%s\n", ptr);
}

-g option의 오묘함에 놀란 적이 있죠~

void func(){
int a[100];
....

return a;
}

이와 같은 루틴을 작성하는 사람을 보고 있으면 종종 뒤통수를 치죠~~ 너는 지역변수도 모르냐면서~
근데 이게 정상적으로 돌아갈때가 있습니다.

바로 -g 옵션을 주면 debug flags로 인하여 지역변수를 해제 하지 않더군요~ 그래서 정상적으로 돌아가네요~

그래서 예외가 있다는 것을 확인한적이 있습니다. ㅋㅋㅋ

아주 멍청한 짓을 한번 한적이 있네요.
glibc 의 pthread와 malloc implementation 을 믿지 못해서, 테스트코드를 좀 사악하게 한번 짜서 돌려본 적이 있는데, 죽는다고 물어봤다가, 결국은 제 잘못이었다는. --;
(사실은 못 믿는 마음에 컴파일러 경고고 뭐고 보지도 않고 잘못됐다고 투덜댔었지요. )
결국 comp.programming.threads 에 올렸다가 아주 망신당하고 친절하게 지도를 받은적이 한번 있답니다. 좀 썰렁하게 긴 코드지만 -Wall 붙여서 한번 컴파일 해보시면 제가 얼마나 멍청한 짓을 했는가 바로 감잡으실...

교훈 : 잘되면 남탓이요. 못되면 내탓이라...

#include
#include

int get_sum(int x)
{
int ret, i, a;

/* just to give delay,
* the result is not important
*/
for (a=0; a<100; a++) {
ret=0;
for (i=0; i ret+=i;
}
} return ret;
}

void *thread_main_sub_sub(void *arg)
{
char *res;
char *nullmem;

nullmem=(char)malloc(1000);

printf("I'm %s [%d]\n",__FUNCTION__, pthread_self());
printf("I'm %s [%d], calc sum 1000000=%d\n", __FUNCTION__,
pthread_self(), get_sum(1
000000) );
printf("I'm %s [%d], byebye\n", __FUNCTION__, pthread_self());

free(nullmem);
}

void *thread_main_sub(void *arg)
{
pthread_t newtid=0;
char *res;

char *nullmem;

nullmem=(char)malloc(1000);
printf("I'm %s [%d], calling new thread [%d]\n",__FUNCTION__,
pthread_self(), newti
d);
pthread_create( &newtid, NULL, thread_main_sub_sub, NULL);
printf("I'm %s [%d], calc sum 100000=%d\n", __FUNCTION__,
pthread_self(), get_sum(10
0000) );
printf("I'm %s [%d], byebye\n",__FUNCTION__, pthread_self());
pthread_join( newtid, &res);

free(nullmem);
}

void *thread_main(void *arg)
{
pthread_t newtid=0;
char *res;

pthread_create( &newtid, NULL, thread_main_sub, NULL);
printf("I'm %s [%d], calling new thread [%d]\n", __FUNCTION__,
pthread_self(), newti
d);
pthread_join( newtid, &res);
}

#define MAX_THREAD 10

main()
{
pthread_t tid_arr[MAX_THREAD];
pthread_t tid2;
int i;
char *res;

for (i=0; i pthread_create( &tid_arr[i], NULL, thread_main, NULL);
printf("Creating thread [%d]\n", tid_arr[i]);
}

for (i=0; i pthread_join( tid_arr[i], &res);
printf("thread [%d/%d] joined\n", tid_arr[i], MAX_THREAD);
}

printf("Exiting... \n");
exit(0);
}

----------------

이게 답입니다.

Yep. Ignoring all those warning messages from gcc will get you into trouble. It runs w/o
problems with the changes listed at the end.

Basically
- use the right type cast for malloc
- use the right type for the return value of pthread_join
[though I'd pass NULL like the man page suggests if you are not going to use the return value]

There are plenty of other bugs (e.g., not checking return values for errors), but I'll leave
fixing them to you. :-)
--Mark
---------------------

diff mytest.c test.c
22c22
< /* char *res; */
---
> char *res;
25c25
< nullmem=(char*)malloc(1000);
---
> nullmem=(char)malloc(1000);
28,29c28,29
< printf("I'm %s [%d], calc sum 1000000=%d\n", __FUNCTION__,pthread_self(),
< get_sum(1000000) );
---
> printf("I'm %s [%d], calc sum 1000000=%d\n", __FUNCTION__,
> pthread_self(), get_sum(1000000) );
38c38
< void **res;
---
> char *res;
42,43c42,43
< nullmem=(char*)malloc(1000);
< printf("I'm %s [%d], calling new thread [%d]\n",__FUNCTION__,
---
> nullmem=(char)malloc(1000);
> printf("I'm %s [%d], calling new thread [%d]\n",__FUNCTION__,
49c49
< pthread_join( newtid, res);
---
> pthread_join( newtid, &res);
57c57
< void **res;
---
> char *res;
62c62
< pthread_join( newtid, res);
---
> pthread_join( newtid, &res);
72c72
< void **res;
---
> char *res;
80c80
< pthread_join( tid_arr[i], res);
---
> pthread_join( tid_arr[i], &res);

질문 입니다. ㅡ.ㅡ;

ARM 크로스 컴팔용 GCC 에서

16비트 = 하프워드 volatile 은 잘 되는 것 같은데.

32비트 = 풀워드 volatile 에 문제가 있는 것 같습니다.

16비트 * 2 = 32비트 억세스 플래시로 구성하고 있는데.

자꾸 하위워드만 살아남고 상위가 죽어버리는 거에용.. ㅡ.ㅡ; 이거 컴팔러 뻑인가요?

다른 문제 일까요?