밤새가며 디버깅하다가 남의 버그인것을 발견했다면?

송지석의 이미지

이럴 때 어찌해야 할까요?

맡은 일에서 새 기능 구현쪽 작업을 하던 중이었습니다 - 리눅스 커널 모듈쪽이고 거기에 붙는 라이브러리와 또 그걸 사용하는 라이브러리 + 어플까지 좀씩 손봐야 했죠.
그런데 중간 테스트해보니 OOM killer(메모리 부족시 뜨는 킬러)가 뜨면서 프로세스들을 죽여버리거나 셸을 닫거나 난리가 났습니다.
큰일났다 싶어(커널에서 vmalloc을 쓰긴 하거든요) 디버깅해보는데 도저히 안나오더라구요. 이게 커널 OOM killer 버그인건지, 아님 제 코드에 버그인건지.. 근데 vmalloc쓰는 부분을 없애도 나오구..
새벽까지 머리 쥐어뜯으며 이리저리 살펴보는데 (이런 경험 많으시죠? 감정이입해보셔요. 왕짜증.. 원츄)
결국 어플쪽 손봤던 사람이 만들다 만, malloc들을 크게 잡아놓은 게 있었군요.
256MB 짜리 임베디드 보드가 그 코드때문에 어플을 돌리기만 하면 메모리가 full이 나는 거였습니다.

그래서 남의 버그 때문에 고생한 셈이 됐는데.

문제는 말이죠.
저는 매주 주간보고를 해야 한단 말입니다.
어떤어떤 일이 무슨무슨 일로 잘 됐느니 늦었느니 기타등등 보고해야하는데요.

무슨 일이 늦거나 결과가 안좋았을 때 그게 제 버그면 할 말이 없는데
남의 버그면 이걸 윗사람에게 말하기도 뭐하고.. 그렇다고 그냥 넘어가면 제가 능력이 없거나 버그를 만든 것 처럼 보이고..

여러분이라면 어떻게 하실래요?

ps. 개인적인 경험으론 옛날 회사에서 5년 전에 버그라고 코드를 고쳤던 적이 있는데, 5년 후에 전화와서 버그 아닌데 왜고쳤냐고 그래서 황당했던 일도 있답니다. 코드가 없으니 뭐라고 반박도 못하겠고..

houyhn의 이미지

당연히 있는 그대로 얘기해야 하죠. 그래야 다음부터 같은 실수를 반복하지 않을수 있으니까요.

남의 눈치 보면서 할말 못하는 조직이라면 이미 날샜다고 봐야죠.

지리즈의 이미지

장비나 커널 탓을 하는 겁니다.

그분이 비록 다소 무리한 코드를 삽입했으나...
임베디드가 아닌 일반 시스템이라면 그렇게 까지 문제가 아니지만...
임베디드 보드의 한계상 이 문제가 크게 붉어져 나왔다 blah~ blas~

There is no spoon. Neo from the Matrix 1999.

There is no spoon. Neo from the Matrix 1999.

tifler의 이미지

뒤집어 쓰시는게 경험상 좋을듯 합니다.
"디버깅하는데 시간이 걸렸다. 결국은 해결했다." 까지만...
이후에 궂이 팀장이 물어온다거나, 다른 사람들이 상세한 내역을 듣고자 한다면...
그때 다른 사람이 심어놓은 버그 때문이었다는걸 얘기해도 늦진 않을겁니다.

하지만, 사전에 그 버그를 심어놓은 분께는 이러한 사실과 이런식으로 얘기하겠다고
언지를 주는것이 좋을듯 하구요.

세상 살면서 피해를 본다고 생각들 경우가 많지만, 한순간 입니다.
이후에 이런일이 당사자에게 없으리란 보장도 없구요.

넓게 보아요 ^^;
/***********************
* while(1) sleep(INFINITE);
***********************/

/***********************
* while(1) sleep(INFINITE);
***********************/

M.W.Park의 이미지

버그를 생산한(?) 사람에게 똑같이 밤샐만한 보답 버그나 일을 줘야죠. ^^;

-----
오늘 의 취미는 끝없는, 끝없는 인내다. 1973 法頂

-----
오늘 의 취미는 끝없는, 끝없는 인내다. 1973 法頂

vulpes의 이미지

그러다 피박쓰면 ㄷㄷㄷㄷㄷㄷ

--
"It's too bad that stupidity isn't painful" - Anton LaVey

밤여우 Tech: http://foxtech.tistory.com
트롤은 말려 죽입시다 - http://kldp.org/files/trollfreeKLDP.user_.js__0.txt

--
"It's too bad that stupidity isn't painful" - Anton LaVey

밤여우 Tech: http://foxtech.tistory.com
트롤은 말려 죽입시다 - http://kldp.org/files/trollfreeKLDP.user_.js__0.txt

won-kyu.park의 이미지

디버깅을 해서 찾은 사람이나 버그를 만드신 분이나 두 분을 위해서 바른대로 쓰는 것이 맞다고 생각합니다.
다만, 버그 만드신 분이 성격이 너무 좋지 않으면 좀 고민을...

wkpark의 이미지

소스코드 버그를 고칠때 그 고친 소스코드에 장황한 주석을 달아둡니다.

문제 생기면 그때 누군가 찾아보겠고, 그 주석도 발견하게 되겠고, 보고를 하는 몫은 그분의 몫이 되겟지요.ㅋ

온갖 참된 삶은 만남이다 --Martin Buber

sheep의 이미지

오늘 비슷한 일을 겪었습니다...

오래클에서 에러가 뜨길래 제가 버그처리하는 제품에 있는 코드인줄 알고 디버깅 한나절 했는데...

오래클 자체에러였습니다...

결론은 오래클 업데이트해야 된다는거...

--------
From Buenos Aires, Argentina
No sere feliz pero tengo computadora.... jaja
닥치고 Ubuntu!!!!!
To Serve My Lord Jesus
blog: http://sehoonpark.com.ar
http://me2day.net/sheep

--------
From Buenos Aires, Argentina
No sere feliz pero tengo computadora.... jaja
닥치고 Ubuntu!!!!!
To Serve My Lord Jesus
blog: http://sehoonpark.com.ar
http://me2day.net/sheep

bookgekgom의 이미지

오라클?

---------------------------------------------------------------------------------------------------------------
루비 온 레일즈로 만들고 있는 홈페이지 입니다.

http://jihwankim.co.nr

여러 프로그램 소스들이 있습니다.

필요하신분은 받아가세요.

송지석의 이미지

의견들 감사합니다. :-)
역시 사는 건 길게 봐야겠지요 ^^

rommance.net

BSK의 이미지

있는 그대로 사실 그대로 자기얘기를 하세요.

자기 의견도 얘기 못하면 이 바닥에서 정신적, 육체적으로 힘들어집니다.

/* ....맑은 정신, 건강한 육체, 넓은 가슴으로 세상과 타협하자. */

/* ....맑은 정신, 건강한 육체, 넓은 가슴으로 세상과 타협하자. */

JuEUS-U의 이미지

저도 비슷한 일이...
교수님이 준 코드에서 Segment Fault가 뜹니다.... 오마이갓 = ㅅ=);;;
Hex2Dec에서 오류를 뿜는군요;;;

rubenz의 이미지

걍 말하세요...
말한다고 기분 나뻐 한다면... 어차피... 신경 안써도 될 인물 입니다..
^^