얼마전부터 저는 게임 서버가 걸핏하면 다운되는 힘든 상황을 발견했습니다. [2] 더 웃긴건, 아래 그림과 같은 에러 상자가 자꾸만 튀어나온다는 점이었습니다. 저 에러는 FATAL ERROR이기 때문에, 버튼을 누르면 프로그램이 죽어버립니다. 즉 한바탕 겜 하던 유저들이 몽땅 털려나가는 상황이 된거죠.
한참 삽질하고 나서야 문제를 해결했습니다. 그러나 이 문제의 원인은 참으로 어이없는 것이었습니다.
다음 코드는 잘 작동할까요?
void main()
{
float a;
scanf("%f",&a);
}
이걸 실행하면 의외로 다음과 같은 에러가 납니다!
그런데, 위의 구문 중 float a; 를 float a=1; 로 바꾸면 잘 됩니다.
이게 무슨 조화냐???!
20년전, RAM과 CPU가 귀하던 시절, CPU의 가격을 낮추기 위해 부동소수점 연산 유닛이 빠진 CPU가 판매됐습니다. 그리고 부동소수점 연산 유닛은 코프로세서라는 이름으로 별도 판매가 되었죠. 그래서 옛날에는 부동소수점 연산을 코프로세서(하드웨어 가속)을 쓰느냐 라이브러리(소프트웨어 에뮬레이션)을 쓰느냐를 선택할 필요가 있었죠. 그런데, 부동소수점 연산 라이브러리가 차지하는 공간도 아끼기 위해 부동소수점 라이브러리(특히 에뮬레이션의 경우)가 차지하는 공간을 필요없으면 제거하는 것이 필요했습니다. code가 64KBytes에 모두 들어가야 했으니까요. [1]
부동소수점 연산 라이브러리를 같이 링크하느냐를 따지는 여부는 컴파일러가 소스를 분석하면서 부동소수점 변수에 값을 넣는 경우가 있느냐로 결정됐습니다.
즉, 위의 에러는 부동소수점 변수가 전혀 사용되지 않은 코드에서 printf/scanf를 호출했으나, printf 내부에서 관련 함수들을 호출하면서, 결국 부동소수점 연산 모듈이 링크되지 않아서 발생하는 에러인겁니다.
그런데, 부동소수점 연산 모듈은 정적 링크만을 지원합니다. 32비트 CPU부터는 기본으로 코프로세서도 달렸기 때문에 이 모듈은 더 이상 크기를 신경 안써도 될 정도가 되었으며, 호출 빈도가 매우 높으므로 DLL로 빼는건 오히려 낭비이니까요. 사실상 무조건 부동소수점 라이브러리를 넣어도 이제는 문제될 것이 없습니다.
그러나, 20년이 지난 지금, 이제는 쥐방울만한 부동소수점 라이브러리에 신경 쓸 필요도 없는 이 시점에서, 아직도 저 기능은 잔존하고 있습니다. 그것도 버그와 함꼐!!!
이제는 DLL도 사용되는 시대입니다. DLL은 EXE와 달리 입력값의 범위가 컴파일 타임에서 찾아낼 수 없는 무제한 범위입니다. 이럴때는 DLL은 모든 케이스에 대한 정적 링크가 되거나 다른 공유 DLL에 의존하는 형태가 되어야 합니다. 그러나 바보같은 MS는 부동소수점 연산 라이브러리에 대해서는 이 두가지 형태 중 어느것도 고려하지 않았습니다. 자기네들이 DLL을 만들어냈으면서도 말입니다. 즉 DLL이라는 놈을 만들어서 뿌리기나 했지, 이것의 생리에 대한 모든 케이스는 자기네들도 잘 따져보지도 못했다는겁니다!
그래서 무슨 일이 생기느냐? 만약 DLL이 printf()를 호출하면서, DLL이 받는 입력 값 중에 부동소수점 라이브러리가 필요할 수 있는 케이스가 존재한다면, 비록 EXE에서 부동소수점 라이브러리를 갖고 있더라도 DLL 컴파일 타임에서 이미 그런 케이스가 없을 경우 어디에서도 부동소수점 라이브러리를 제공받지 않는다는 겁니다! 즉 위와 같은 에러가 납니다.
그럼 이 문제를 해결하려면 어떻게 해야 하느냐? DLL은 어쨌거나 volatile float a=1; 을 소스 어딘가에 최소 1군데는 갖고 있어야 한다는겁니다. volatile을 빼면 안되냐고요? 릴리즈로 빌드하면 참조되지 않는 변수는 아예 사라집니다. 따라서 강제로 넣어주도록 해야 합니다!
여기까지, 부동소수점 라이브러리와 DLL과 관련된 MS의 설계적 버그였습니다. 그리고, 여기에는 또 버그가 있습니다.
저 부동소수점 라이브러리가 그나마 정적 링크되고 안되고가 결정되는 기준에 버그가 있죠. DLL로 저런 문제의 코드를 짜서 실행하면 에러가 납니다.
그런데, 어쩌다가 테스트 목적으로 float a=1;을 넣고 실행하면 에러 없이 잘 됩니다. 이 상태에서 테스트 다 됐으니 테스트 코드를 막자~~ 하면서 float a=1;을 막아버고 컴파일하면? 잘 작동합니다. -_- 여기서 리빌드를 해버리면? 또 에러가 납니다!
20년전에나 이슈됐던 기능이 아직까지도 제대로 수습되지 않은 상태에서, DLL 등 여러가지 기능이 들어가면서 생길 수 있는 이슈들을 제대로 고려해놓지 않고 저런 황당한 버그를 만들어놓은 MS... 직원들 월급이 좀 모자란가 봅니다. 저런거 하나 고치지 않고 말이죠.
-----------
[1] (약 15년전 제가 MS-DOS 어셈블리 프로그래밍에 재미붙였을 당시의 기억인지라 다소 오류가 있을 수 있습니다.) 16비트 MS-DOS 프로그램 모델은 tiny, small, large 등 몇 가지가 있습니다. tiny model인 EXE나 확장자가 COM인 실행 파일의 경우 데이터까지 포함 64kbytes까지 제한됐으며, small의 경우 code만 64kbytes까지 제한됐습니다. 지금은 flat model이라고 해서, code만도 2GBytes까지 사용 가능합니다.
[2] 오픈베타중이었습니다만, 본 서버에서가 아니라 테스트 서버(본 서버에 올라가기 전에 시험을 거치는 불안정성을 경고한 서버)에서 발생했습니다.
한참 삽질하고 나서야 문제를 해결했습니다. 그러나 이 문제의 원인은 참으로 어이없는 것이었습니다.
다음 코드는 잘 작동할까요?
void main()
{
float a;
scanf("%f",&a);
}
이걸 실행하면 의외로 다음과 같은 에러가 납니다!
그런데, 위의 구문 중 float a; 를 float a=1; 로 바꾸면 잘 됩니다.
이게 무슨 조화냐???!
20년전, RAM과 CPU가 귀하던 시절, CPU의 가격을 낮추기 위해 부동소수점 연산 유닛이 빠진 CPU가 판매됐습니다. 그리고 부동소수점 연산 유닛은 코프로세서라는 이름으로 별도 판매가 되었죠. 그래서 옛날에는 부동소수점 연산을 코프로세서(하드웨어 가속)을 쓰느냐 라이브러리(소프트웨어 에뮬레이션)을 쓰느냐를 선택할 필요가 있었죠. 그런데, 부동소수점 연산 라이브러리가 차지하는 공간도 아끼기 위해 부동소수점 라이브러리(특히 에뮬레이션의 경우)가 차지하는 공간을 필요없으면 제거하는 것이 필요했습니다. code가 64KBytes에 모두 들어가야 했으니까요. [1]
부동소수점 연산 라이브러리를 같이 링크하느냐를 따지는 여부는 컴파일러가 소스를 분석하면서 부동소수점 변수에 값을 넣는 경우가 있느냐로 결정됐습니다.
즉, 위의 에러는 부동소수점 변수가 전혀 사용되지 않은 코드에서 printf/scanf를 호출했으나, printf 내부에서 관련 함수들을 호출하면서, 결국 부동소수점 연산 모듈이 링크되지 않아서 발생하는 에러인겁니다.
그런데, 부동소수점 연산 모듈은 정적 링크만을 지원합니다. 32비트 CPU부터는 기본으로 코프로세서도 달렸기 때문에 이 모듈은 더 이상 크기를 신경 안써도 될 정도가 되었으며, 호출 빈도가 매우 높으므로 DLL로 빼는건 오히려 낭비이니까요. 사실상 무조건 부동소수점 라이브러리를 넣어도 이제는 문제될 것이 없습니다.
그러나, 20년이 지난 지금, 이제는 쥐방울만한 부동소수점 라이브러리에 신경 쓸 필요도 없는 이 시점에서, 아직도 저 기능은 잔존하고 있습니다. 그것도 버그와 함꼐!!!
이제는 DLL도 사용되는 시대입니다. DLL은 EXE와 달리 입력값의 범위가 컴파일 타임에서 찾아낼 수 없는 무제한 범위입니다. 이럴때는 DLL은 모든 케이스에 대한 정적 링크가 되거나 다른 공유 DLL에 의존하는 형태가 되어야 합니다. 그러나 바보같은 MS는 부동소수점 연산 라이브러리에 대해서는 이 두가지 형태 중 어느것도 고려하지 않았습니다. 자기네들이 DLL을 만들어냈으면서도 말입니다. 즉 DLL이라는 놈을 만들어서 뿌리기나 했지, 이것의 생리에 대한 모든 케이스는 자기네들도 잘 따져보지도 못했다는겁니다!
그래서 무슨 일이 생기느냐? 만약 DLL이 printf()를 호출하면서, DLL이 받는 입력 값 중에 부동소수점 라이브러리가 필요할 수 있는 케이스가 존재한다면, 비록 EXE에서 부동소수점 라이브러리를 갖고 있더라도 DLL 컴파일 타임에서 이미 그런 케이스가 없을 경우 어디에서도 부동소수점 라이브러리를 제공받지 않는다는 겁니다! 즉 위와 같은 에러가 납니다.
그럼 이 문제를 해결하려면 어떻게 해야 하느냐? DLL은 어쨌거나 volatile float a=1; 을 소스 어딘가에 최소 1군데는 갖고 있어야 한다는겁니다. volatile을 빼면 안되냐고요? 릴리즈로 빌드하면 참조되지 않는 변수는 아예 사라집니다. 따라서 강제로 넣어주도록 해야 합니다!
여기까지, 부동소수점 라이브러리와 DLL과 관련된 MS의 설계적 버그였습니다. 그리고, 여기에는 또 버그가 있습니다.
저 부동소수점 라이브러리가 그나마 정적 링크되고 안되고가 결정되는 기준에 버그가 있죠. DLL로 저런 문제의 코드를 짜서 실행하면 에러가 납니다.
그런데, 어쩌다가 테스트 목적으로 float a=1;을 넣고 실행하면 에러 없이 잘 됩니다. 이 상태에서 테스트 다 됐으니 테스트 코드를 막자~~ 하면서 float a=1;을 막아버고 컴파일하면? 잘 작동합니다. -_- 여기서 리빌드를 해버리면? 또 에러가 납니다!
20년전에나 이슈됐던 기능이 아직까지도 제대로 수습되지 않은 상태에서, DLL 등 여러가지 기능이 들어가면서 생길 수 있는 이슈들을 제대로 고려해놓지 않고 저런 황당한 버그를 만들어놓은 MS... 직원들 월급이 좀 모자란가 봅니다. 저런거 하나 고치지 않고 말이죠.
-----------
[1] (약 15년전 제가 MS-DOS 어셈블리 프로그래밍에 재미붙였을 당시의 기억인지라 다소 오류가 있을 수 있습니다.) 16비트 MS-DOS 프로그램 모델은 tiny, small, large 등 몇 가지가 있습니다. tiny model인 EXE나 확장자가 COM인 실행 파일의 경우 데이터까지 포함 64kbytes까지 제한됐으며, small의 경우 code만 64kbytes까지 제한됐습니다. 지금은 flat model이라고 해서, code만도 2GBytes까지 사용 가능합니다.
[2] 오픈베타중이었습니다만, 본 서버에서가 아니라 테스트 서버(본 서버에 올라가기 전에 시험을 거치는 불안정성을 경고한 서버)에서 발생했습니다.
댓글
댓글 쓰기