프로그래머와 엔지니어의 민속(1부)

이것은 버그가 때때로 어떻게 완전히 놀라운 징후를 보이는지에 대한 인터넷의 이야기 모음입니다. 아마도 당신에게도 할 말이 있을 것입니다.

바닐라 아이스크림에 대한 자동차 알레르기

명백한 것이 항상 답은 아니며, 사실이 아무리 믿기 어려운 것처럼 보일지라도 여전히 사실임을 이해하는 엔지니어를 위한 이야기입니다. General Motors Corporation의 Pontiac 사업부는 다음과 같은 불만 사항을 접수했습니다.

제가 당신에게 편지를 쓰는 것은 이번이 두 번째입니다. 대답하지 않는다고 해서 당신을 비난하지는 않습니다. 이상하게 들리니까요. 우리 가족은 매일 밤 저녁 식사 후에 아이스크림을 먹는 전통이 있습니다. 아이스크림 종류는 매번 바뀌는데, 저녁 식사 후에는 온 가족이 어떤 아이스크림을 살지 고르고 나서 가게로 갑니다. 나는 최근에 새 폰티악을 샀고 그 이후로 아이스크림을 사러 가는 여행이 문제가 되었습니다. 있잖아요, 바닐라 아이스크림을 사고 가게에서 돌아올 때마다 차가 시동이 안 걸리거든요. 다른 아이스크림을 가져오면 아무 문제 없이 차가 출발합니다. 아무리 어리석게 들리더라도 진지하게 질문하고 싶습니다. “바닐라 아이스크림을 가져오면 시동이 걸리지 않고, 다른 맛의 아이스크림을 가져오면 쉽게 시동이 걸리는 폰티악의 정체는 무엇입니까?”

상상할 수 있듯이 부서장은 편지에 대해 회의적이었습니다. 하지만 만약을 대비해 엔지니어를 보내 확인을 했습니다. 그는 아름다운 지역에 살고 있는 부유하고 교육을 잘 받은 남자를 만났다는 사실에 놀랐습니다. 그들은 저녁 식사 후 바로 만나서 아이스크림을 사러 가게에 가기로 합의했습니다. 그날 저녁은 바닐라였고, 그들이 차로 돌아왔을 때 시동이 걸리지 않았습니다.

엔지니어는 저녁에 세 번 더 왔습니다. 처음으로 아이스크림은 초콜릿이었습니다. 차가 시작되었습니다. 두 번째로는 딸기 아이스크림이 나왔습니다. 차가 시작되었습니다. 셋째 날 저녁에 그는 바닐라를 가져가라고 요청했습니다. 차가 시동을 걸지 않았어요.

합리적으로 추론한 엔지니어는 차가 바닐라 아이스크림에 알레르기가 있다는 사실을 믿기를 거부했습니다. 그래서 나는 자동차 소유자가 문제에 대한 해결책을 찾을 때까지 계속 방문하겠다고 동의했습니다. 그리고 그 과정에서 그는 메모하기 시작했습니다. 그는 모든 정보, 시간, 휘발유 종류, 도착 시간 및 상점에서 돌아 오는 시간 등을 기록했습니다.

엔지니어는 자동차 소유자가 바닐라 아이스크림을 구입하는 데 더 적은 시간을 소비한다는 것을 곧 깨달았습니다. 그 이유는 매장 내 상품 배치 때문이었습니다. 바닐라 아이스크림이 가장 인기가 많았고, 찾기 쉽도록 매장 전면에 별도의 냉동고에 보관해 두었습니다. 그리고 다른 품종도 다 매장 뒤쪽에 있어서 딱 맞는 품종을 찾아서 결제하는데 훨씬 더 많은 시간이 걸렸어요.

이제 엔지니어의 질문은 엔진이 꺼진 순간부터 시간이 덜 지났다면 왜 자동차가 시동되지 않았습니까? 문제는 바닐라 아이스크림이 아니라 시간이었기 때문에 엔지니어는 빠르게 답을 찾았습니다. 바로 가스 잠금 장치였습니다. 매일 저녁 이런 일이 일어났는데, 차 주인이 아이스크림을 찾는데 더 많은 시간을 할애하자 엔진은 충분히 식혀져 쉽게 ​​시동이 걸렸다. 그리고 그 남자가 바닐라 아이스크림을 샀을 때 엔진은 여전히 ​​너무 뜨거웠고 가스 잠금 장치가 녹을 시간이 없었습니다.

도덕: 완전히 말도 안 되는 문제라도 때로는 현실이 되는 경우가 있습니다.

충돌 큰쥐

이것을 경험하는 것은 고통스럽습니다. 프로그래머로서 당신은 자신의 코드를 첫째, 둘째, 셋째로 비난하는 데 익숙해지며, 그 중 만 번째는 컴파일러를 비난하는 것입니다. 그리고 목록 아래로 내려가면 이미 장비를 비난하고 있습니다.

하드웨어 버그에 대한 나의 이야기는 다음과 같습니다.

Crash Bandicoot 게임의 경우 메모리 카드를 로드하고 저장하는 코드를 작성했습니다. 그렇게 잘난 척하는 게임 개발자에게 그것은 마치 공원을 산책하는 것과 같았습니다. 작업이 며칠이 걸릴 것이라고 생각했습니다. 그러나 나는 결국 XNUMX주 동안 코드를 디버깅하게 되었습니다. 그 과정에서 다른 문제를 해결했지만 며칠마다 몇 시간 동안 이 코드를 다시 사용했습니다. 그것은 고통이었습니다.

증상은 다음과 같습니다. 게임의 현재 플레이를 저장하고 메모리 카드에 액세스하면 거의 항상 모든 것이 잘 됩니다... 그러나 때때로 뚜렷한 이유 없이 읽기 또는 쓰기 작업 시간이 초과됩니다. 짧은 녹화로 인해 메모리 카드가 손상되는 경우가 많습니다. 플레이어가 저장을 시도하면 저장에 실패할 뿐만 아니라 지도도 파괴됩니다. 쓰레기.

얼마 후 Sony의 프로듀서인 Connie Bus가 당황하기 시작했습니다. 우리는 이 버그가 있는 게임을 출시할 수 없었고, 1주 후에도 문제의 원인이 무엇인지 이해하지 못했습니다. Connie를 통해 우리는 다른 PSXNUMX 개발자들과 접촉했습니다. 비슷한 현상을 겪은 사람이 있습니까? 아니요. 아무도 메모리 카드에 문제가 없었습니다.

디버깅에 대한 아이디어가 없을 때 남은 유일한 접근 방식은 "분할하여 정복"하는 것입니다. 즉, 여전히 문제를 일으키는 상대적으로 작은 조각이 남을 때까지 잘못된 프로그램에서 점점 더 많은 코드를 제거하는 것입니다. 즉, 버그가 포함된 부분이 남을 때까지 프로그램을 하나씩 잘라내는 것입니다.

하지만 문제는 비디오 게임에서 덩어리를 잘라내는 것이 매우 어렵다는 것입니다. 중력을 에뮬레이션하는 코드를 제거한 경우 어떻게 실행하나요? 아니면 캐릭터를 그리는 걸까요?

따라서 우리는 유용한 일을 하는 것처럼 보이지만 실제로는 오류를 포함할 수 없는 매우 간단한 일을 수행하는 스텁으로 전체 모듈을 교체해야 합니다. 게임이 최소한 작동하려면 그런 목발을 작성해야 합니다. 이것은 느리고 고통스러운 과정입니다.

요컨대 나는 해냈다. 게임을 실행하기 위해 시스템을 구성하고 렌더링 하드웨어를 초기화하는 등의 초기 코드가 남을 때까지 점점 더 많은 코드 조각을 제거했습니다. 물론 이 단계에서는 모든 그래픽 코드에 대한 스텁을 만들어야 하므로 저장 및 로드 메뉴를 만들 수 없습니다. 그러나 (보이지 않는) 저장 및 로드 화면을 사용하여 사용자인 척하고 저장한 다음 메모리 카드에 쓰도록 요청할 수 있습니다.

이로 인해 여전히 위의 문제가 있는 작은 코드 조각이 남게 되었습니다. 하지만 여전히 무작위로 발생하고 있었습니다! 대부분의 경우 모든 것이 잘 작동했지만 때때로 결함이 발생했습니다. 게임 코드를 거의 다 제거했는데도 버그는 여전히 살아 있었습니다. 이것은 수수께끼였습니다. 나머지 코드는 실제로 아무것도 수행하지 않았습니다.

어느 순간, 아마도 새벽 XNUMX시쯤에 한 가지 생각이 떠올랐습니다. 읽기 및 쓰기(입력/출력) 작업에는 정확한 실행 시간이 필요합니다. 하드 드라이브, 메모리 카드 또는 Bluetooth 모듈로 작업할 때 읽기 및 쓰기를 담당하는 하위 수준 코드는 클럭 펄스에 따라 작업을 수행합니다.

시계의 도움으로 프로세서에 직접 연결되지 않은 장치는 프로세서에서 실행되는 코드와 동기화됩니다. 클럭은 전송 속도, 즉 데이터가 전송되는 속도를 결정합니다. 타이밍에 혼란이 있다면 하드웨어나 소프트웨어, 또는 둘 다도 혼란스러운 것입니다. 그리고 이것은 데이터가 손상될 수 있기 때문에 매우 나쁩니다.

코드의 어떤 부분이 타이밍을 혼동한다면 어떻게 될까요? 테스트 프로그램 코드에서 이와 관련된 모든 것을 확인했고 PS1의 프로그래밍 가능 타이머를 1kHz(초당 1000틱)로 설정한 것을 확인했습니다. 이는 꽤 많은 양이며 기본적으로 콘솔이 시작되면 100Hz로 실행됩니다. 그리고 대부분의 게임은 이 주파수를 사용합니다.

게임 개발자인 Andy는 움직임이 더 정확하게 계산되도록 타이머를 1kHz로 설정했습니다. Andy는 지나치게 노력하는 경향이 있으며, 중력을 모방한다면 최대한 정확하게 수행합니다!

그러나 타이머 속도를 높이는 것이 프로그램의 전체 타이밍에 영향을 미쳐 메모리 카드의 전송 속도를 조절하는 시계에 영향을 준다면 어떻게 될까요?

타이머 코드를 주석 처리했습니다. 오류가 다시 발생하지 않았습니다. 그러나 실패가 무작위로 발생했기 때문에 이것이 우리가 그것을 고쳤다는 의미는 아닙니다. 그냥 운이 좋았더라면 어떡하지?

며칠 후 나는 테스트 프로그램을 다시 실험해 보았다. 버그가 재발하지 않았습니다. 전체 게임 코드베이스로 돌아가 프로그래밍 가능한 타이머가 메모리 카드에 액세스하기 전에 원래 값(100Hz)으로 재설정된 다음 다시 1kHz로 재설정되도록 저장 및 로드 코드를 수정했습니다. 더 이상 충돌이 발생하지 않았습니다.

그러나 왜 이런 일이 일어 났습니까?

다시 테스트 프로그램으로 돌아왔습니다. 1kHz 타이머를 사용하여 오류 발생 패턴을 찾으려고 노력했습니다. 결국 누군가가 PS1 컨트롤러를 가지고 플레이할 때 오류가 발생한다는 것을 알게 되었습니다. 나는 이 작업을 거의 직접 수행하지 않는데 코드 저장 및 로드를 테스트할 때 왜 컨트롤러가 필요합니까? -이 의존성을 눈치 채지도 못했습니다. 그런데 어느 날 우리 아티스트 중 한 명이 제가 테스트를 마치길 기다리고 있었습니다. 아마 그 순간 저는 욕을 하고 있었을 것입니다. 그리고 초조하게 그의 손에 있는 컨트롤러를 빙빙 돌렸습니다. 오류가 발생했습니다. "무엇을 기다립니다?!" 자, 다시 해보세요!”

이 두 가지 이벤트가 서로 연결되어 있다는 것을 깨달았을 때 오류를 쉽게 재현할 수 있었습니다. 메모리 카드에 녹화를 시작하고 컨트롤러를 움직여서 메모리 카드를 망쳤습니다. 나에게 그것은 하드웨어 버그처럼 보였습니다.

나는 코니에게 와서 내가 발견한 것에 대해 이야기했습니다. 그녀는 PS1을 설계한 엔지니어 중 한 명에게 정보를 전달했습니다. 그는 “불가능하다”며 “하드웨어 문제일 수는 없다”고 답했다. 나는 Connie에게 우리를 위한 대화를 준비해 달라고 부탁했습니다.

엔지니어가 나에게 전화했고 우리는 그의 서투른 영어와 나의 (매우) 서투른 일본어로 논쟁을 벌였습니다. 마침내 나는 "컨트롤러를 움직이면 버그가 발생하는 30줄 테스트 프로그램을 보내겠습니다."라고 말했습니다. 그는 동의했다. 시간 낭비이고 새 프로젝트 작업으로 너무 바쁘지만 우리가 Sony의 매우 중요한 개발자이기 때문에 포기하겠다고 말했습니다. 나는 테스트 프로그램을 정리해서 그에게 보냈습니다.

다음날 저녁(우리는 로스앤젤레스에 있었고 그는 도쿄에 있었습니다) 그는 나에게 전화를 걸어 얄밉게 사과했습니다. 하드웨어 문제였습니다.

정확히 무슨 버그인지는 모르겠지만 소니 본사에서 들은 바에 따르면 타이머를 충분히 높은 값으로 설정하면 타이머 크리스탈 근처에 있는 마더보드의 구성 요소에 간섭이 발생한다고 합니다. 그 중 하나는 컨트롤러의 전송 속도를 설정하는 메모리 카드용 전송 속도 컨트롤러였습니다. 저는 엔지니어가 아니기 때문에 뭔가를 엉망으로 만들었을 수도 있습니다.

하지만 결론은 마더보드의 구성 요소 간에 간섭이 있었다는 것입니다. 그리고 1kHz로 작동하는 타이머로 컨트롤러 포트와 메모리 카드 포트를 통해 동시에 데이터를 전송할 때 비트가 손실되고 데이터가 손실되며 카드가 손상되었습니다.

나쁜 소

1980년대에 나의 멘토 세르게이(Sergei)는 소련의 PDP-1800 복제품인 SM-11용 소프트웨어를 작성했습니다. 이 마이크로컴퓨터는 소련의 중요한 교통 허브인 스베르들롭스크 근처의 기차역에 방금 설치되었습니다. 새로운 시스템은 마차와 화물 운송 경로를 지정하도록 설계되었습니다. 그러나 여기에는 무작위 충돌 및 충돌을 일으키는 성가신 버그가 포함되어 있습니다. 누군가가 저녁에 집에 돌아갈 때 넘어지는 일은 항상 발생했습니다. 그러나 다음날 철저한 조사에도 불구하고 컴퓨터는 모든 수동 및 자동 테스트에서 올바르게 작동했습니다. 이는 일반적으로 특정 조건에서 발생하는 경쟁 조건이나 기타 경쟁 버그를 나타냅니다. 늦은 밤 전화에 지친 Sergei는 문제의 원인을 파악하고 먼저 마샬링 야드의 어떤 조건으로 인해 컴퓨터 고장이 발생했는지 이해하기로 결정했습니다.

먼저, 설명되지 않은 모든 낙상에 대한 통계를 수집하고 날짜별, 시간별 그래프를 작성했습니다. 패턴은 분명했다. 며칠 동안 관찰한 후 Sergei는 향후 시스템 오류가 발생할 시간을 쉽게 예측할 수 있다는 것을 깨달았습니다.

그는 곧 역이 우크라이나 북부와 러시아 서부에서 인근 도살장으로 향하는 기차에 실린 소를 분류할 때만 중단이 발생한다는 사실을 알게 되었습니다. 도살장은 카자흐스탄에서 훨씬 더 가까운 농장에서 공급되었기 때문에 이것은 그 자체로 이상했습니다.

1986년 체르노빌 원자력 발전소가 폭발했고, 방사능 낙진으로 인해 주변 지역이 사람이 살 수 없게 되었습니다. 우크라이나 북부, 벨로루시, 러시아 서부의 광대한 지역이 오염되었습니다. 도착하는 객차에서 높은 수준의 방사선이 의심되는 Sergei는 이 이론을 테스트하는 방법을 개발했습니다. 주민들은 선량계를 소지하는 것이 금지되었기 때문에 세르게이는 기차역에서 여러 군인들에게 자신을 등록했습니다. 보드카를 몇 잔 마신 후 그는 군인에게 의심스러운 마차 중 하나의 방사선 수준을 측정하도록 설득했습니다. 그 수치는 정상 수치보다 몇 배나 높은 것으로 나타났습니다.

소가 방사능을 많이 냈을 뿐만 아니라, 그 수준이 너무 높아서 역 옆 건물에 있던 SM-1800의 메모리에서 무작위로 비트가 손실되었습니다.

소련에는 식량 부족이 있었고 당국은 체르노빌 고기를 다른 지역의 고기와 혼합하기로 결정했습니다. 이를 통해 귀중한 자원을 잃지 않고 전반적인 방사능 수준을 줄일 수 있었습니다. 이 사실을 알게 된 Sergei는 즉시 이민 서류를 작성했습니다. 그리고 시간이 지남에 따라 방사선 수준이 감소하자 컴퓨터 충돌이 저절로 멈췄습니다.

파이프를 통해

옛날 옛적에 Movietech Solutions는 회계, 티켓 판매 및 일반 관리를 위해 설계된 영화관용 소프트웨어를 만들었습니다. 플래그십 앱의 DOS 버전은 북미 중소 영화관 체인에서 꽤 인기가 있었습니다. 따라서 최신 터치 스크린 및 셀프 서비스 키오스크와 통합되고 모든 종류의 보고 도구를 갖춘 Windows 95 버전이 발표되었을 때 빠르게 인기를 얻은 것도 놀라운 일이 아닙니다. 대부분의 경우 업데이트가 문제 없이 진행되었습니다. 현지 IT 직원이 새 장비를 설치하고 데이터를 마이그레이션하며 비즈니스를 계속했습니다. 지속되지 않았을 때를 제외하고. 이런 일이 발생하면 회사는 "The Cleaner"라는 별명을 가진 James를 파견했습니다.

별명이 사악한 유형을 암시하지만 청소기는 강사, 설치자 및 만능꾼의 조합일 뿐입니다. James는 며칠 동안 고객 현장에서 모든 구성 요소를 조립한 다음 직원들에게 새 시스템 사용 방법을 가르치고 발생한 하드웨어 문제를 해결하며 본질적으로 초기 단계에서 소프트웨어를 지원하는 데 며칠을 보냈습니다.

그러므로 이 바쁜 시기에 James가 아침에 사무실에 도착했고, 책상에 도달하기도 전에 평소보다 카페인이 가득한 매니저가 그를 맞이한 것은 놀라운 일이 아닙니다.

"유감스럽지만 가능한 한 빨리 노바스코샤 주 아나폴리스로 가셔야 합니다." 전체 시스템이 다운되었고 엔지니어들과 밤새 작업한 후에도 무슨 일이 일어났는지 알 수 없었습니다. 서버의 네트워크에 장애가 발생한 것 같습니다. 그러나 시스템이 몇 분 동안 실행된 후에야 가능했습니다.

— 예전 시스템으로 돌아가진 않았나요? - 제임스는 완전히 진지하게 대답했지만 정신적으로는 놀라서 눈을 크게 떴습니다.

— 정확합니다. IT 전문가가 "우선순위를 변경"하고 기존 서버를 떠나기로 결정했습니다. James, 그들은 1950개 사이트에 시스템을 설치하고 프리미엄 지원 비용만 지불했으며 이제 그들의 사업은 XNUMX년대처럼 운영되고 있습니다.

제임스는 몸을 살짝 꼿꼿이 세웠다.

- 그건 또 다른 문제입니다. 좋아요, 시작해 보겠습니다.

아나폴리스에 도착했을 때 그가 가장 먼저 한 일은 고객의 첫 번째 문제가 있는 극장을 찾는 것이었다. 공항에서 찍은 지도에서는 ​​모든 것이 괜찮아 보였지만 원하는 주소 주변 지역은 의심스러워 보였습니다. 게토는 아니지만 느와르 영화를 연상시킨다. James가 시내 도로변에 주차했을 때 매춘부가 그에게 다가왔습니다. 아나폴리스의 규모를 고려하면 도시 전체에서 아나폴리스가 유일한 곳일 가능성이 높습니다. 그녀의 모습은 즉시 대형 스크린에서 돈을 받고 섹스를 제안한 유명한 캐릭터를 떠올렸다. 아니요, Julia Roberts에 관한 것이 아니라 Jon Voight에 관한 것입니다.영화 "Midnight Cowboy"에 대한 암시 - 대략. 레인].

매춘부를 보낸 후 James는 영화관에갔습니다. 주변 환경은 좋아졌지만 여전히 쇠퇴한 듯한 느낌을 줍니다. 제임스가 너무 걱정한 것은 아니다. 그는 전에도 비참한 곳에 가본 적이 있습니다. 그리고 이곳은 강도라도 지갑을 빼앗고 "고마워요"라고 말할 정도로 예의바른 캐나다였다.

영화관 옆쪽 입구는 축축한 골목에 있었습니다. 제임스는 문으로 걸어가서 노크했다. 곧 그것은 삐걱거리며 살짝 열렸다.

- 청소부이신가요? - 안에서 쉰 목소리가 들렸습니다.

- 네, 저예요... 다 고치러 왔어요.

James는 영화관 로비로 걸어 들어갔습니다. 다른 선택의 여지가 없었던 듯 직원들은 방문객들에게 종이 티켓을 나눠주기 시작했습니다. 이로 인해 더 흥미로운 세부 사항은 말할 것도 없고 재무 보고도 어려워졌습니다. 하지만 직원들은 제임스를 안도의 인사로 맞이하고 곧바로 서버실로 데려갔습니다.

언뜻보기에는 모든 것이 괜찮았습니다. James는 서버에 로그인하여 평소 의심스러운 장소를 확인했습니다. 괜찮아요. 그러나 많은 주의를 기울여서 James는 서버를 종료하고 네트워크 카드를 교체한 다음 시스템을 롤백했습니다. 그녀는 즉시 본격적으로 일하기 시작했습니다. 직원이 다시 티켓을 판매하기 시작했습니다.

James는 Mark에게 전화를 걸어 상황을 알렸습니다. James가 예상치 못한 일이 발생하는지 확인하고 싶어할 수도 있다는 것을 상상하는 것은 어렵지 않습니다. 그는 계단을 내려가 직원들에게 무슨 일이 일어났는지 묻기 시작했습니다. 분명히 시스템이 작동을 멈췄습니다. 그들은 그것을 껐다가 켜서 모든 것이 작동했습니다. 그러나 10분 후에 시스템이 다운되었습니다.

바로 이 순간에도 비슷한 일이 일어났습니다. 갑자기 티켓팅 시스템에서 오류가 발생하기 시작했습니다. 직원들은 한숨을 쉬며 종이티켓을 집어들었고 제임스는 서둘러 서버실로 향했다. 서버에서는 모든 것이 좋아 보였습니다.

그러자 직원 중 한 명이 들어왔습니다.

— 시스템이 다시 작동하고 있습니다.

제임스는 아무것도 하지 않았기 때문에 당황했습니다. 보다 정확하게는 시스템을 작동하게 만드는 것은 없습니다. 그는 로그아웃하고 전화기를 집어 회사 지원 라인에 전화했습니다. 곧 같은 직원이 서버실에 들어왔습니다.

- 시스템이 다운되었습니다.

제임스는 서버를 쳐다보았다. 흥미롭고 친숙한 패턴의 다양한 색상의 모양이 화면에서 춤을 추고 있습니다. 파이프가 혼란스럽게 몸부림치고 얽혀 있습니다. 우리 모두는 어느 시점에서 이 화면 보호기를 본 적이 있습니다. 그것은 아름답게 렌더링되었고 말 그대로 최면을 걸었습니다.

James가 버튼을 누르면 패턴이 사라졌습니다. 그는 서둘러 매표소로 가서 도중에 자신에게 돌아오는 직원을 만났습니다.

— 시스템이 다시 작동하고 있습니다.

당신이 정신적인 얼굴 손바닥을 할 수 있다면, 그것이 바로 제임스가 한 일입니다. 화면 보호기. OpenGL을 사용합니다. 따라서 작동 중에 서버 프로세서의 모든 리소스를 소비합니다. 결과적으로 서버에 대한 각 호출은 시간 초과로 종료됩니다.

James는 서버실로 돌아와서 로그인하고 화면 보호기를 빈 화면이 있는 아름다운 파이프로 교체했습니다. 즉, 프로세서 자원을 100% 소모하는 화면 보호기 대신 자원을 소모하지 않는 화면 보호기를 또 설치했습니다. 그런 다음 추측을 확인하기 위해 10분을 기다렸습니다.

James가 다음 영화관에 도착했을 때, 그는 화면 보호기를 끄기 위해 방금 800km를 비행했다고 매니저에게 어떻게 설명해야 할지 고민하고 있었습니다.

달의 특정 단계에서 충돌이 발생함

실화. 어느 날 달의 위상에 따라 달라지는 소프트웨어 버그가 발생했습니다. 달의 실제 위상에 대한 근사치를 계산하기 위해 다양한 MIT 프로그램에서 일반적으로 사용되는 작은 루틴이 있었습니다. GLS는 이 루틴을 LISP 프로그램에 내장하여 파일을 작성할 때 거의 80자 길이의 타임스탬프가 있는 줄을 출력합니다. 메시지의 첫 번째 줄이 너무 길어져서 다음 줄로 이어지는 경우는 매우 드뭅니다. 그리고 프로그램이 나중에 이 파일을 읽을 때 저주를 받았습니다. 첫 번째 줄의 길이는 정확한 날짜와 시간뿐만 아니라 타임스탬프가 인쇄된 시점의 단계 사양 길이에 따라 달라집니다. 즉, 버그는 말 그대로 달의 위상에 따라 달라졌습니다!

첫 번째 종이판 전문 용어 파일 (Steele-1983)에는 설명된 버그를 유발하는 줄의 예가 포함되어 있지만 식자기가 이를 "수정"했습니다. 이후 이것은 "달 위상 버그"로 설명되었습니다.

그러나 가정에는 주의하세요. 몇 년 전 CERN(유럽 핵 연구 센터)의 엔지니어들은 대형 전자-양전자 충돌기에서 수행된 실험에서 오류를 발견했습니다. 과학자들에게 결과를 보여주기 전에 컴퓨터가 이 장치에서 생성된 엄청난 양의 데이터를 적극적으로 처리하기 때문에 많은 사람들은 소프트웨어가 달의 위상에 민감하다고 추측했습니다. 절망에 빠진 몇몇 엔지니어들이 진실을 파헤쳤습니다. 달이 통과하는 동안 지구의 변형으로 인해 27km 길이의 고리의 기하학적 구조가 약간 변경되어 오류가 발생했습니다! 이 이야기는 "입자 물리학에 대한 뉴턴의 복수"로 물리학 민속학에 등장했으며, 가장 단순하고 오래된 물리학 법칙과 가장 발전된 과학적 개념 사이의 연관성을 보여주는 예입니다.

화장실 물을 내리면 기차가 멈춘다

내가 들어본 최고의 하드웨어 버그는 프랑스의 고속 열차에서 발생했습니다. 이 버그로 인해 열차가 비상 제동을 걸었지만 승객이 탑승한 경우에만 가능했습니다. 이러한 경우마다 열차 운행이 중단되어 점검되었으나 아무 것도 발견되지 않았습니다. 그런 다음 그는 다시 라인으로 보내졌고 즉시 추락하여 멈췄습니다.

점검 중에 기차를 타고 여행하는 엔지니어가 화장실에갔습니다. 그는 곧 씻겨 나갔습니다. BOOM! 비상 정지.

엔지니어는 운전자에게 연락하여 다음과 같이 물었습니다.

— 브레이크를 밟기 직전에 무엇을 하고 있었나요?

- 하산할 때 속도를 줄였어요...

정상 운행 중에 열차가 하강할 때 수십 번 속도를 늦추기 때문에 이것은 이상했습니다. 기차는 계속 나아갔고, 다음 내리막길에서 운전사는 다음과 같이 경고했습니다.

- 천천히 갈게요.

아무 일도하지.

— 마지막 제동 중에 무엇을 했나요? -운전사에게 물었습니다.

- 음... 화장실에 있었어요...

- 그럼 화장실에 가서 우리가 다시 내려갔을 때 하던 대로 하세요!

엔지니어는 화장실로 갔고, 운전자가 “속도를 늦추고 있어요”라고 경고하자 물을 흘렸습니다. 물론 기차는 곧바로 멈췄다.

이제 문제를 재현할 수 있게 되었고 원인을 찾아야 했습니다.

XNUMX분 후, 그들은 엔진 브레이크 원격 제어 케이블(열차의 양쪽 끝에 엔진이 하나씩 있음)이 전기 캐비닛 벽에서 분리되어 변기 플러그 솔레노이드를 제어하는 ​​릴레이 위에 놓여 있는 것을 발견했습니다... 릴레이가 작동할 때 전원을 켜면 브레이크 케이블에 간섭이 발생하고 오류에 대한 시스템 보호에는 단순히 비상 제동이 포함됩니다.

FORTRAN을 싫어했던 관문

몇 달 전에 우리는 본토(하와이에 있음)의 네트워크 연결이 매우 느려지는 것을 발견했습니다. 이러한 현상은 10~15분 동안 지속되다가 갑자기 다시 발생할 수 있습니다. 얼마 후, 내 동료가 나에게 본토의 네트워크 연결이 끊겼다고 불평했습니다. 일반적으로 작동하지 않습니다. 그는 본토에 있는 컴퓨터에 복사해야 하는 일부 FORTRAN 코드를 가지고 있었지만 "FTP 업로드가 완료될 때까지 네트워크가 오래 버틸 수 없었기 때문에" 복사할 수 없었습니다.

예, 동료가 FORTRAN의 소스 코드가 포함된 파일을 본토의 컴퓨터로 FTP로 보내려고 할 때 네트워크 오류가 발생한 것으로 나타났습니다. 우리는 파일을 보관하려고 시도했지만 원활하게 복사되었습니다(그러나 대상 컴퓨터에는 압축 해제 도구가 없어 문제가 해결되지 않았습니다). 마지막으로 우리는 FORTRAN 코드를 매우 작은 조각으로 "분할"하여 한 번에 하나씩 보냈습니다. 대부분의 조각은 문제없이 복사되었으나 일부 ​​조각은 통과하지 못하거나 이후에 통과되었습니다. 수많은 시도.

문제가 있는 구절을 조사했을 때 우리는 공통점이 있다는 것을 발견했습니다. 모두 대문자 C로 구성된 줄로 시작하고 끝나는 주석 블록을 포함하고 있었습니다(동료는 FORTRAN에서 주석을 달기를 선호했기 때문에). 우리는 본토의 네트워크 전문가에게 이메일을 보내 도움을 요청했습니다. 물론 그들은 FTP를 통해 전송할 수 없는 우리 파일의 샘플을 보고 싶어 했지만... 우리의 편지는 그들에게 도달하지 못했습니다. 마침내 우리는 간단한 것을 생각해 냈습니다. 설명하다전송할 수 없는 파일의 모습. 효과가 있었습니다 :) [여기에 문제가 있는 FORTRAN 주석 중 하나의 예를 추가해도 될까요? 아마도 그럴 가치가 없을 것입니다!]

결국 우리는 그것을 알아낼 수 있었습니다. 최근 캠퍼스와 본토 네트워크 사이에 새로운 게이트웨이가 설치되었습니다. 대문자 C가 반복적으로 포함된 패킷을 전송하는 데 엄청난 어려움이 있었습니다! 이러한 패킷 중 일부만 모든 게이트웨이 리소스를 차지하여 대부분의 다른 패킷이 통과하는 것을 방해할 수 있습니다. 우리는 게이트웨이 제조업체에 불만을 제기했고... 그들은 다음과 같이 대답했습니다. “아, 그렇습니다. 반복되는 C 버그에 직면했습니다! 우리는 이미 그에 대해 알고 있어요.” 우리는 결국 다른 제조업체로부터 새 게이트웨이를 구입하여 문제를 해결했습니다(전자의 입장에서는 FORTRAN 프로그램을 전송할 수 없는 것이 일부에게는 유리할 수 있습니다!).

어려운 시간들

몇 년 전, 40상 임상시험 비용을 줄이기 위해 Perl에서 ETL 시스템을 만드는 작업을 하면서 약 000개의 날짜를 처리해야 했습니다. 그 중 1명은 시험을 통과하지 못했습니다. 이 날짜는 고객이 제공한 데이터에서 가져온 것이기 때문에 별로 신경쓰지 않았습니다. 이는 종종 놀라운 일이었습니다. 그런데 원본 데이터를 확인해 보니 이 날짜가 2011년 1월 2007일과 30년 XNUMX월 XNUMX일이었습니다. 방금 작성한 프로그램에 버그가 포함된 줄 알았는데, 알고 보니 벌써 XNUMX년이 지났습니다. 오래된. 소프트웨어 생태계에 익숙하지 않은 사람들에게는 이것이 이상하게 들릴 수도 있습니다. 돈을 벌겠다는 다른 회사의 오랜 결정 때문에 제 고객은 한 회사는 실수로, 다른 회사는 고의로 도입한 버그를 고치기 위해 나에게 돈을 지불했습니다. 내가 말하는 내용을 이해하려면 결국 버그가 된 기능을 추가한 회사와 내가 고친 신비한 버그에 기여한 몇 가지 흥미로운 이벤트에 대해 이야기해야 합니다.

옛날에는 Apple 컴퓨터가 자발적으로 날짜를 1년 1904월 1일로 재설정하는 경우가 있었습니다. 그 이유는 간단했습니다. 날짜와 시간을 추적하기 위해 배터리로 작동되는 "시스템 시계"를 사용했기 때문입니다. 배터리가 방전되었을 때 무슨 일이 일어났나요? 컴퓨터는 시대가 시작된 이후 초 단위로 날짜를 추적하기 시작했습니다. 에포크(Epoch)는 참조 원래 날짜를 의미했으며 매킨토시의 경우 1904년 XNUMX월 XNUMX일이었습니다. 그리고 배터리가 방전된 후 현재 날짜가 지정된 날짜로 재설정되었습니다. 그런데 왜 이런 일이 일어났는가?

이전에 Apple은 원래 날짜 이후의 초 수를 저장하기 위해 32비트를 사용했습니다. 1비트는 0 또는 00의 두 값 중 하나를 저장할 수 있습니다. 01비트는 10, 11, 000, 001의 네 가지 값 중 하나를 저장할 수 있습니다. 010비트 - 011개 중 하나의 값: 100, 101, 110, 111, 32 , 232, 4, 294 등 그리고 967는 296개의 값 중 하나, 즉 136초를 저장할 수 있습니다. Apple 날짜의 경우 이는 약 2040년에 해당하므로 구형 Mac에서는 0년 이후의 날짜를 처리할 수 없습니다. 그리고 시스템 배터리가 방전되면 날짜는 에포크가 시작된 이후 XNUMX초로 재설정되며, 컴퓨터를 켤 때마다(또는 새 배터리를 구입할 때까지) 수동으로 날짜를 설정해야 합니다.

그러나 날짜를 에포크 이후의 초 단위로 저장하기로 한 Apple의 결정은 에포크 이전의 날짜를 처리할 수 없다는 것을 의미했으며 이는 앞으로 살펴보겠지만 광범위한 결과를 가져왔습니다. Apple은 버그가 아닌 기능을 도입했습니다. 무엇보다도 이는 Macintosh 운영 체제가 "밀레니엄 버그"(제한 사항을 우회하기 위해 자체 날짜 시스템을 갖춘 많은 Mac 응용 프로그램에서는 말할 수 없는)로부터 면역되었다는 것을 의미합니다.

계속하세요. 우리는 PC 혁명의 시작을 도운 IBM의 "킬러 애플리케이션"인 Lotus 1-2-3을 사용했습니다. 비록 Apple 컴퓨터에는 개인용 컴퓨터를 성공으로 이끈 VisiCalc가 있었지만 말이죠. 공평하게 말하면, 1-2-3이 없었다면 PC는 거의 성공하지 못했을 것이고, 개인용 컴퓨터의 역사도 매우 다르게 발전했을 것이다. Lotus 1-2-3은 1900년을 윤년으로 잘못 처리했습니다. Microsoft가 첫 번째 스프레드시트인 Multiplan을 출시했을 때 시장에서 작은 점유율을 차지했습니다. 그리고 Excel 프로젝트를 시작할 때 Lotus 1-2-3의 행 및 열 명명 체계를 복사할 뿐만 아니라 의도적으로 1900을 윤년으로 처리하여 버그 호환성을 보장하기로 결정했습니다. 이 문제는 오늘날에도 여전히 존재합니다. 즉, 1-2-3에서는 이것이 버그였지만 Excel에서는 모든 1-2-3 사용자가 데이터가 정확하지 않더라도 데이터를 변경하지 않고 Excel로 테이블을 가져올 수 있도록 보장하는 의식적인 결정이었습니다.

그러나 또 다른 문제가 있었습니다. 먼저 마이크로소프트는 1년 1904월 1일 이전 날짜를 인식하지 못하는 매킨토시용 엑셀을 출시했다. 그리고 엑셀에서는 1900년 XNUMX월 XNUMX일을 시대의 시작으로 간주했다. 따라서 개발자들은 프로그램이 시대의 유형을 인식하고 원하는 시대에 맞춰 자체적으로 데이터를 저장하도록 변경했습니다. Microsoft는 이에 대한 설명 기사도 작성했습니다. 그리고 이 결정으로 인해 버그가 발생했습니다.

내 ETL 시스템은 고객으로부터 Windows에서 생성되었지만 Mac에서도 생성될 수 있는 Excel 스프레드시트를 받았습니다. 따라서 테이블의 연대 시작 날짜는 1년 1900월 1일 또는 1904년 XNUMX월 XNUMX일이 될 수 있습니다. 알아내는 방법? Excel 파일 형식은 필요한 정보를 표시하지만 내가 사용한 파서는 이를 표시하지 않았으며(지금은 표시됨) 특정 테이블의 시대를 알고 있다고 가정했습니다. 아마도 Excel 바이너리 형식을 이해하고 파서 작성자에게 패치를 보내는 데 더 많은 시간을 할애할 수도 있었지만 클라이언트를 위해 해야 할 일이 더 많았기 때문에 신속하게 휴리스틱을 작성하여 에포크를 결정했습니다. 그녀는 단순했습니다.

Excel에서 5년 1998월 07일 날짜는 "05-98-5"(쓸모 없는 미국 시스템), "98년 5월 1998일", "5년 98월 8601일", "35981년 1900월 34519일" 또는 "1904년 4월 1904일" 형식으로 표시될 수 있습니다. 다른 형식 또 다른 쓸모없는 형식(아이러니하게도 내 Excel 버전에서 제공하지 않은 형식 중 하나는 ISO XNUMX이었습니다). 그러나 테이블 내에서는 형식화되지 않은 날짜가 epoch-XNUMX의 경우 "XNUMX" 또는 epoch-XNUMX의 경우 "XNUMX"로 저장되었습니다(숫자는 epoch 이후의 일수를 나타냄). 나는 단순히 간단한 파서를 사용하여 형식이 지정된 날짜에서 연도를 추출한 다음 Excel 파서를 사용하여 형식이 지정되지 않은 날짜에서 연도를 추출했습니다. 두 값이 XNUMX년씩 다르다면 epoch-XNUMX가 포함된 시스템을 사용하고 있다는 것을 알았습니다.

왜 형식화된 날짜를 사용하지 않았나요? 왜냐하면 5년 1998월 98일은 해당 월의 날짜가 손실되어 "XNUMX월, XNUMX"로 형식화될 수 있기 때문입니다. 우리는 매우 다양한 방법으로 테이블을 생성한 수많은 회사로부터 테이블을 받았기 때문에 날짜를 파악하는 것은 우리(이 경우에는 나)에게 달렸습니다. 게다가 Excel이 올바르게 작동한다면 우리도 마찬가지입니다!

동시에 나는 39082를 만났습니다. Lotus 1-2-3은 1900을 윤년으로 간주했으며 이는 Excel에서 충실하게 반복되었음을 상기시켜 드리겠습니다. 그리고 이것은 1900년에 하루를 추가했기 때문에 바로 그 날에 대한 많은 날짜 계산 함수가 잘못될 수 있습니다. 즉, 39082는 1년 2011월 31일(Mac) 또는 2006년 2011월 1900일(Windows)일 수 있습니다. 내 "연도 파서"가 형식화된 값에서 2006년을 추출했다면 모든 것이 정상입니다. 그러나 Excel 파서는 어떤 epoch가 사용되고 있는지 모르기 때문에 기본적으로 epoch-5으로 설정되어 XNUMX년을 반환합니다. 내 응용 프로그램에서는 차이가 XNUMX년이라는 것을 확인하고 이를 오류로 간주하여 기록하고 형식화되지 않은 값을 반환했습니다.

이 문제를 해결하기 위해 다음과 같이 작성했습니다(의사 코드).

diff = formatted_year - parsed_year
if 0 == diff
    assume 1900 date system
if 4 == diff
    assume 1904 date system
if 5 == diff and month is December and day is 31
    assume 1904 date system

그러면 40개의 날짜가 모두 올바르게 구문 분석되었습니다.

대규모 인쇄 작업 도중

1980년대 초, 아버지는 고속 테이프 공급을 위한 테이프 드라이브와 공압 시스템을 만드는 지금은 없어진 부서인 Storage Technology에서 근무하셨습니다.

그들은 하나의 중앙 "A" 드라이브를 XNUMX개의 "B" 드라이브에 연결할 수 있고 "A" 드라이브를 제어하는 ​​RAM의 작은 OS가 모든 "B" 드라이브에 읽기 및 쓰기 작업을 위임할 수 있도록 드라이브를 재설계했습니다.

드라이브 "A"가 시작될 때마다 운영 체제를 메모리에 로드하려면 "A"에 연결된 주변 드라이브에 플로피 디스크를 삽입해야 했습니다. 이는 매우 원시적이었습니다. 컴퓨팅 성능은 8비트 마이크로컨트롤러에 의해 제공되었습니다.

이러한 장비의 대상 고객은 많은 주소 라벨이나 은행 명세서를 인쇄해야 하는 대규모 데이터 웨어하우스(은행, 소매 체인 등)를 보유한 회사였습니다.

한 고객에게 문제가 생겼습니다. 인쇄 작업 도중 특정 드라이브 "A" 하나가 작동을 멈추고 전체 작업이 중단될 수 있습니다. 드라이브 작동을 복원하려면 직원이 모든 것을 재부팅해야 했습니다. 그리고 이것이 XNUMX시간 작업 도중에 발생하면 엄청난 양의 값비싼 컴퓨터 시간이 손실되고 전체 작업 일정이 중단됩니다.

기술자는 Storage Technologies에서 파견되었습니다. 그러나 최선의 노력에도 불구하고 테스트 조건에서는 버그를 재현할 수 없었습니다. 이 버그는 대규모 인쇄 작업 도중에 발생하는 것 같았습니다. 문제는 하드웨어가 아니라 RAM, 마이크로컨트롤러, 플로피 드라이브, 테이프 드라이브에서 생각할 수 있는 모든 부품 등 가능한 모든 것을 교체했지만 문제는 계속되었습니다.

그러자 기술자들이 본사에 전화를 걸어 전문가에게 전화를 걸었습니다.

전문가는 의자와 커피 한 잔을 들고 컴퓨터실(당시에는 컴퓨터 전용 공간도 있었습니다)에 앉아 직원들이 대형 인쇄 작업을 기다리는 것을 지켜보았습니다. 전문가는 실패가 일어나기를 기다리고 있었고 실제로 그렇게 되었습니다. 모두가 전문가를 보았지만 그는 왜 이런 일이 발생했는지 전혀 몰랐습니다. 그래서 그는 작업을 다시 대기열에 넣으라고 명령했고 모든 직원과 기술자는 다시 작업에 복귀했습니다.

전문가는 다시 의자에 앉아 실패를 기다리기 시작했습니다. 약 XNUMX시간이 지났고 장애가 발생했습니다. 전문가는 모든 일이 사람들로 가득 찬 방에서 일어났다는 것 외에는 아무 생각도 하지 못했습니다. 그는 임무를 다시 시작하라고 명령하고 다시 자리에 앉아 기다렸습니다.

세 번째 실패에서 전문가는 뭔가를 알아차렸습니다. 직원이 외부 드라이브의 테이프를 변경할 때 오류가 발생했습니다. 더욱이 직원 중 한 명이 바닥에 있는 특정 타일을 통과하자마자 오류가 발생했습니다.

이중 바닥은 6~8인치 높이에 깔린 알루미늄 타일로 만들어졌습니다. 누군가가 실수로 중요한 케이블을 밟는 것을 방지하기 위해 컴퓨터의 수많은 전선이 이중 바닥 아래로 연결되었습니다. 타일은 이물질이 이중 바닥 아래로 들어가는 것을 방지하기 위해 매우 단단히 배치되었습니다.

전문가는 타일 중 하나가 변형되었음을 깨달았습니다. 직원이 모서리를 밟았을 때 타일의 가장자리가 인접한 타일과 마찰되었습니다. 타일을 연결하는 플라스틱 부품도 마찰로 인해 무선 주파수 간섭을 일으키는 정전기 미세 방전이 발생했습니다.

오늘날 RAM은 무선 주파수 간섭으로부터 훨씬 더 잘 보호됩니다. 그러나 그 해에는 그렇지 않았습니다. 전문가는 이러한 간섭으로 인해 메모리가 중단되고 이로 인해 운영 체제 작동이 중단된다는 것을 깨달았습니다. 그는 지원 서비스에 전화를 걸어 새 타일을 주문하고 직접 설치하자 문제가 사라졌습니다.

만조입니다!

이야기는 부두 지역에 있는 포츠머스 사무실의 XNUMX층이나 XNUMX층에 있는 서버실에서 일어났습니다.

어느 날 주 데이터베이스가 있는 Unix 서버가 충돌했습니다. 그들은 그를 재부팅했지만 그는 행복하게 계속해서 계속해서 넘어졌습니다. 우리는 지원 서비스 담당자에게 전화하기로 결정했습니다.

그 지원자... 내 생각엔 그 사람 이름이 마크인 것 같은데 그건 중요하지 않아... 내가 그 사람을 모르는 것 같아. 정말 중요하지 않습니다. 마크랑 같이 지내자, 알았지? 엄청난.

그래서 몇 시간 후에 Mark가 도착하여(리즈에서 포츠머스까지 그리 멀지 않은 곳입니다) 서버를 켜고 모든 것이 문제 없이 작동했습니다. 전형적인 망할 지원, 클라이언트는 그것에 대해 매우 화가납니다. Mark는 로그 파일을 살펴보고 이상한 점을 찾지 못했습니다. 그래서 Mark는 다시 기차를 타고(또는 그가 도착한 교통 수단이 무엇이든, 내가 아는 한 그것은 절름발이 소였을 수도 있습니다... 어쨌든 상관없습니다, 그렇죠?) 낭비를 한 후 리즈로 돌아갑니다. 그 날.

그날 저녁에 서버가 다시 충돌합니다. 이야기는 똑같습니다... 서버가 안오르네요. Mark는 원격으로 도움을 주려고 하지만 클라이언트가 서버를 시작할 수 없습니다.

또 다른 기차, 버스, 레몬 머랭 또는 기타 쓰레기와 Mark가 포츠머스로 돌아왔습니다. 보세요, 서버가 아무 문제 없이 부팅됩니다! 기적. Mark는 운영 체제나 소프트웨어에 모든 것이 제대로 되어 있는지 확인하는 데 몇 시간을 보낸 후 Leeds로 출발합니다.

한낮쯤에 서버가 충돌합니다(진정하세요!). 이번에는 하드웨어 지원 인력을 투입하여 서버를 교체하는 것이 합리적으로 보입니다. 하지만 아니요, 약 10시간 후에도 떨어집니다.

상황은 며칠 동안 반복되었습니다. 서버가 작동하고 약 10시간 후에 충돌이 발생하며 다음 2시간 동안 시작되지 않습니다. 냉각, 메모리 누수 등을 모두 확인했지만 아무것도 발견하지 못했습니다. 그런 다음 충돌이 멈췄습니다.

한주가 평온하게 지나갔습니다... 모두가 행복했습니다. 모든 것이 다시 시작될 때까지 행복하세요. 그림은 동일합니다. 10시간 일하고 2~3시간 쉬고..

그리고 누군가 (이 사람은 IT와 아무 관련이 없다고 말한 것 같습니다) 다음과 같이 말했습니다.

"조수다!"

감탄사와 마주한 멍한 눈빛, 아마도 보안 호출 버튼에 누군가의 손이 머뭇거렸을 것이다.

"조수와 함께 작동하지 않습니다."

이것은 커피를 마시면서 Tide Yearbook을 읽을 가능성이 거의 없는 IT 지원 직원들에게는 완전히 낯선 개념으로 보일 것입니다. 그들은 서버가 일주일 동안 장애 없이 작동했기 때문에 이것이 어떤 식으로든 조류와 관련이 있을 수 없다고 설명했습니다.

"지난주는 물때가 낮았는데, 이번주는 물때가 높아요."

요트 라이센스가 없는 사람들을 위한 간단한 용어입니다. 조수는 달의 주기에 따라 달라집니다. 그리고 지구가 자전하면서 12,5시간마다 태양과 달의 중력으로 인해 해일이 발생합니다. 12,5시간 주기의 시작 부분에는 만조가 있고, 주기 중간에 썰물이 있으며, 마지막에는 다시 만조가 있습니다. 그러나 달의 궤도가 변하면서 썰물과 만조의 차이도 변합니다. 달이 태양과 지구 사이에 있거나 지구의 반대편에 있을 때(보름달이 있거나 달이 없는 경우), 가장 높은 만조와 가장 낮은 썰물인 시지긴(Syzygyn) 조수가 발생합니다. 반달에는 가장 낮은 조수인 직교 조수를 얻습니다. 두 극단의 차이는 크게 감소합니다. 달의 주기는 28일 동안 지속됩니다: syzygian - 구적 - syzygian - 구적.

기술자들은 조력의 본질에 대해 설명을 듣자마자 즉시 경찰에 신고해야 한다고 생각했습니다. 그리고 매우 논리적입니다. 하지만 그 친구가 옳았다는 것이 밝혀졌습니다. XNUMX주 전에 구축함 한 척이 사무실 근처에 정박했습니다. 조수가 일정 높이까지 올라갈 때마다 배의 레이더 포스트는 서버실 바닥 높이까지 올라갔습니다. 그리고 레이더(또는 전자전 장비 또는 기타 군사 장난감)는 컴퓨터에 혼란을 야기했습니다.

로켓 비행 임무

나는 대규모(약 400만 라인) 로켓 발사 제어 및 모니터링 시스템을 새로운 버전의 운영 체제, 컴파일러 및 언어로 포팅하는 임무를 맡았습니다. 보다 정확하게는 Solaris 2.5.1부터 Solaris 7까지, 그리고 Ada 83으로 작성된 Verdix Ada Development System(VADS)부터 Ada 95로 작성된 Rational Apex Ada 시스템까지. VADS는 Rational에서 구입했으며 해당 제품은 Rational은 Apex 컴파일러로의 전환을 쉽게 하기 위해 VADS 관련 패키지의 호환 가능한 버전을 구현하려고 시도했지만 더 이상 사용되지 않습니다.

세 사람이 코드를 깔끔하게 컴파일하는 데 도움을 주었습니다. XNUMX주가 걸렸습니다. 그리고 시스템이 작동하도록 스스로 작업했습니다. 한마디로 제가 접했던 소프트웨어 시스템 중 최악의 아키텍처와 구현이었기 때문에 포팅을 완료하는 데 또 두 달이 걸렸습니다. 그런 다음 시스템은 테스트를 위해 제출되었으며 몇 달이 더 걸렸습니다. 테스트 중에 발견된 버그는 즉시 수정했지만 그 수는 빠르게 감소했습니다(소스 코드가 프로덕션 시스템이므로 기능이 상당히 안정적으로 작동했기 때문에 새 컴파일러에 적응하는 동안 발생한 버그만 제거하면 되었습니다). 결국 모든 것이 제대로 작동했을 때 저는 다른 프로젝트로 옮겨졌습니다.

그리고 추수감사절 전 금요일에 전화벨이 울렸습니다.

로켓 발사는 약 XNUMX주 후에 테스트될 예정이었고, 카운트다운 실험실 테스트 중에 일련의 명령이 차단되었습니다. 실제 상황에서 이로 인해 테스트가 중단되고, 엔진 시동 후 몇 초 이내에 막힘이 발생하면 보조 시스템에서 몇 가지 되돌릴 수 없는 작업이 발생하여 로켓 준비에 오랜 시간과 비용이 소요됩니다. 시작되지도 않았을 텐데, 많은 사람들이 시간과 돈의 손실로 인해 매우 속상해했을 것입니다. 국방부가 돈을 함부로 쓴다는 말을 누구도 하지 못하게 하십시오. 나는 예산을 먼저, 둘째로 두지 않고 일정을 따르지 않는 계약 관리자를 본 적이 없습니다.

이전 몇 달 동안 이 카운트다운 챌린지는 몇 가지 사소한 문제만 제외하고 다양한 변형으로 수백 번 실행되었습니다. 따라서 이런 일이 발생할 가능성은 매우 낮지만 그 결과는 매우 중요합니다. 이 두 가지 요소를 곱하면 뉴스에서 저와 수십 명의 엔지니어 및 관리자에게 망가진 휴일 주간을 예측했다는 것을 이해하게 될 것입니다.

그리고 시스템을 포팅한 사람인 나에게 주목을 받았다.

대부분의 보안이 중요한 시스템과 마찬가지로 많은 매개변수가 기록되었으므로 시스템이 충돌하기 전에 실행된 몇 줄의 코드를 식별하는 것이 매우 쉬웠습니다. 그리고 물론 그들에게는 전혀 특이한 점이 없었습니다. 동일한 실행 중에 동일한 표현식이 문자 그대로 수천 번 성공적으로 실행되었습니다.

우리는 Apex 사람들을 Rational로 불렀습니다. 그들이 컴파일러를 개발했고 그들이 개발한 루틴 중 일부가 의심스러운 코드에서 호출되었기 때문입니다. 그들(그리고 다른 모든 사람들)은 문자 그대로 국가적으로 중요한 문제의 근본 원인을 밝혀야 한다는 점에 깊은 인상을 받았습니다.

저널에는 흥미로운 내용이 없었기 때문에 우리는 지역 실험실에서 문제를 재현해 보기로 결정했습니다. 대략 1000번 실행당 한 번씩 이벤트가 발생했기 때문에 이는 쉬운 작업이 아니었습니다. 의심되는 이유 중 하나는 공급업체가 개발한 뮤텍스 기능(VADS 마이그레이션 패키지의 일부)에 대한 호출이었습니다. Unlock 잠금 해제로 이어지지 않았습니다. 함수를 호출한 처리 스레드는 명목상 매초마다 도착하는 하트비트 메시지를 처리했습니다. 주파수를 10Hz, 즉 10초에 45회까지 올려서 작동을 시작했습니다. 약 한 시간 후에 시스템이 자동으로 잠겼습니다. 로그에서 우리는 기록된 메시지의 순서가 실패한 테스트와 동일한 것을 확인했습니다. 몇 번 더 실행했는데, 시스템은 시작 후 90~XNUMX분 동안 지속적으로 차단되었으며, 로그에는 매번 동일한 경로가 포함되었습니다. 비록 기술적으로는 다른 코드를 실행하고 있었지만(메시지 빈도는 달랐지만) 시스템 동작은 동일했기 때문에 우리는 이 로드 시나리오가 동일한 문제를 일으킨다고 확신했습니다.

이제 우리는 표현식 시퀀스에서 정확히 차단이 발생한 위치를 파악해야 했습니다.

이 시스템 구현은 Ada 작업 시스템을 사용했으며 매우 형편없게 사용되었습니다. 태스크는 Ada에서 동시에 실행 가능한 높은 수준의 구성으로, 실행 스레드와 유사하며 언어 자체에만 내장되어 있습니다. 두 작업이 통신해야 하는 경우 "랑데뷰를 설정"하고 필요한 데이터를 교환한 다음 랑데뷰를 중지하고 독립적인 실행으로 돌아갑니다. 그러나 시스템은 다르게 구현되었습니다. 대상 작업이 랑데부된 후 해당 대상 작업은 다른 작업과 랑데부하고, 그런 다음 세 번째 작업과 랑데부하는 식으로 일부 처리가 완료될 때까지 계속됩니다. 그 후 모든 랑데뷰가 완료되었고 각 작업은 실행으로 돌아가야 했습니다. 즉, 우리는 입력 데이터의 일부를 처리하는 동안 전체 "멀티태스킹" 프로세스를 중단시키는 세계에서 가장 비싼 함수 호출 시스템을 다루고 있었습니다. 그리고 이전에는 처리량이 매우 낮았기 때문에 문제가 발생하지 않았습니다.

랑데뷰가 요청되거나 완료될 것으로 예상되면 "작업 전환"이 발생할 수 있기 때문에 이 작업 메커니즘을 설명했습니다. 즉, 프로세서는 실행 준비가 된 다른 작업의 처리를 시작할 수 있습니다. 한 작업이 다른 작업과 랑데뷰할 준비가 되면 완전히 다른 작업이 실행을 시작할 수 있으며 결국 제어는 첫 번째 랑데부로 돌아갑니다. 그리고 작업이 전환되도록 하는 다른 이벤트가 발생할 수도 있습니다. 이러한 이벤트 중 하나는 뮤텍스 인쇄 또는 실행과 같은 시스템 기능에 대한 호출입니다.

어떤 코드 줄이 문제를 일으키는지 이해하려면 작업 전환을 트리거하지 않고 일련의 명령문을 통해 진행 상황을 기록하여 충돌 발생을 방지하는 방법을 찾아야 했습니다. 그래서 혜택을 못 받았어요 Put_Line()I/O 작업 수행을 방지합니다. 카운터 변수나 이와 유사한 것을 설정할 수 있지만 화면에 표시할 수 없으면 그 값을 어떻게 볼 수 있습니까?

또한 로그를 살펴보면 하트비트 메시지 처리가 중단되어 프로세스의 모든 I/O 작업이 차단되고 다른 처리가 수행되지 않았음에도 불구하고 다른 독립적인 작업이 계속 실행되는 것으로 나타났습니다. 즉, 작업이 완전히 차단된 것이 아니라 (중요한) 작업 체인만 차단되었습니다.

이것이 차단 표현을 평가하는 데 필요한 단서였습니다.

저는 작업, 열거 유형, 해당 유형의 전역 변수를 포함하는 Ada 패키지를 만들었습니다. 열거 가능한 리터럴은 문제가 있는 시퀀스의 특정 표현에 바인딩되었습니다(예: Incrementing_Buffer_Index, Locking_Mutex, Mutex_Unlocked) 그런 다음 해당 열거형을 전역 변수에 할당하는 할당 표현식을 삽입했습니다. 이 모든 객체 코드는 단순히 메모리에 상수를 저장했기 때문에 실행 결과로 작업이 전환될 가능성은 거의 없습니다. 여러 가지 이유로 작업을 다시 전환할 때 반환하는 대신 실행 시 차단이 발생했기 때문에 우리는 주로 작업을 전환할 수 있는 표현식을 의심했습니다.

추적 작업은 단순히 루프에서 실행되었으며 전역 변수의 값이 변경되었는지 주기적으로 확인했습니다. 변경할 때마다 값이 파일에 저장되었습니다. 그런 다음 잠시 기다렸다가 새 수표를 받으세요. 문제 영역에서 태스크를 전환할 때 시스템이 실행 대상으로 선택한 경우에만 태스크가 실행되기 때문에 파일에 변수를 썼습니다. 이 작업에서 어떤 일이 발생하더라도 관련되지 않은 차단된 다른 작업에는 영향을 미치지 않습니다.

시스템이 문제가 있는 코드를 실행하는 지점에 도달하면 다음 표현식으로 이동할 때 전역 변수가 재설정될 것으로 예상되었습니다. 그러면 작업이 전환되는 일이 발생하고 해당 실행 빈도(10Hz)가 모니터링 작업보다 낮기 때문에 모니터가 전역 변수의 값을 캡처하여 쓸 수 있습니다. 일반적인 상황에서는 열거형 하위 집합의 반복 시퀀스, 즉 작업 전환 시 변수의 마지막 값을 얻을 수 있습니다. 정지 시 전역 변수는 더 이상 변경되지 않아야 하며, 마지막으로 기록된 값은 완료되지 않은 표현식을 나타냅니다.

추적 기능을 사용하여 코드를 실행했습니다. 그는 얼었다. 그리고 모니터링은 시계처럼 작동했습니다.

로그에는 뮤텍스가 호출되었음을 나타내는 값으로 인해 중단된 예상 시퀀스가 ​​포함되어 있습니다. Unlock, 이전 수천 번의 호출의 경우와 마찬가지로 작업이 완료되지 않습니다.

Apex 엔지니어들은 이때 열심히 코드를 분석하고 있었고 이론적으로 잠금이 발생할 수 있는 뮤텍스의 위치를 ​​찾았습니다. 그러나 특정 시간에 특정 일련의 사건이 발생해야만 차단이 발생할 수 있기 때문에 확률은 매우 낮습니다. 머피의 법칙 여러분, 그것이 머피의 법칙입니다.

필요한 코드 조각을 보호하기 위해 뮤텍스 함수 호출(OS 뮤텍스 기능 위에 구축됨)을 작은 기본 Ada 뮤텍스 패키지로 대체하여 해당 조각에 대한 뮤텍스 액세스를 제어했습니다.

코드에 삽입하고 테스트를 진행해봤습니다. XNUMX시간 후에도 코드는 여전히 작동했습니다.

내 코드는 Rational에 제출되었으며 그곳에서 코드를 컴파일하고 분해한 후 문제가 있는 뮤텍스 함수에 사용된 것과 동일한 접근 방식을 사용하지 않았는지 확인했습니다.

이것은 내 경력에서 가장 혼잡한 코드 검토였습니다. 🙂 나와 함께 방에는 약 20명의 엔지니어와 관리자가 있었고, 다른 XNUMX명은 전화 회의에 참석했으며 모두 약 XNUMX줄의 코드를 검사했습니다.

코드를 검토하고 새로운 실행 파일을 모아 공식적인 회귀 테스트를 위해 제출했습니다. 몇 주 후, 카운트다운 테스트가 성공했고 로켓이 이륙했습니다.

좋아요, 다 괜찮습니다. 그런데 이 이야기의 요점은 무엇입니까?

정말 역겨운 문제였습니다. 수십만 줄의 코드, 병렬 실행, XNUMX개 이상의 상호 작용 프로세스, 열악한 아키텍처 및 열악한 구현, 임베디드 시스템용 인터페이스 및 수백만 달러 지출. 압박감은 없어요, 그렇죠.

비록 제가 포팅을 하면서 주목을 받았지만 이 문제를 해결하는 사람은 저 뿐만이 아니었습니다. 하지만 그렇게 했다고 해서 수십만 줄의 코드를 모두 이해했거나 심지어 훑어봤다는 의미는 아닙니다. 전국 각지의 엔지니어들이 코드와 로그를 분석했는데, 실패 원인에 대한 가설을 알려주자 반박하는 데 XNUMX분밖에 걸리지 않았습니다. 그리고 이론을 분석하라는 요청을 받았을 때 나는 그것을 다른 사람에게 넘겨주곤 했습니다. 왜냐하면 이 엔지니어들이 잘못된 길로 가고 있다는 것이 나에게는 명백했기 때문입니다. 주제넘게 들리나요? 네, 맞습니다만, 다른 이유로 가설과 요청을 거부했습니다.

문제의 성격을 이해했습니다. 나는 그것이 어디서, 왜 일어나고 있는지 정확히 알지 못했지만 무슨 일이 일어나고 있는지 알고 있었습니다.

수년에 걸쳐 나는 많은 지식과 경험을 축적해왔습니다. 나는 Ada 사용의 선구자 중 한 명이었고 Ada의 장점과 단점을 이해했습니다. 나는 Ada 런타임 라이브러리가 작업을 처리하고 병렬 실행을 처리하는 방법을 알고 있습니다. 그리고 저는 메모리, 레지스터, 어셈블러 수준의 저수준 프로그래밍을 이해합니다. 즉, 나는 내 분야에 깊은 지식을 갖고 있다. 그리고 문제의 원인을 찾기 위해 그것들을 사용했습니다. 나는 단지 버그를 해결한 것이 아니라 매우 민감한 런타임 환경에서 버그를 찾는 방법을 이해했습니다.

이러한 코드 투쟁 이야기는 그러한 투쟁의 특징과 조건에 익숙하지 않은 사람들에게는 그다지 흥미롭지 않습니다. 하지만 이 이야기들은 정말 어려운 문제를 해결하는 데 필요한 것이 무엇인지 이해하는 데 도움이 됩니다.

정말 어려운 문제를 해결하려면 단순한 프로그래머 이상이 되어야 합니다. 코드의 "운명", 코드가 환경과 상호 작용하는 방식, 환경 자체가 작동하는 방식을 이해해야 합니다.

그러면 당신은 망가진 휴일 주간을 갖게 될 것입니다.

계속 될거야.

출처 : habr.com