1.

며칠 동안 포인터 문제가 생긴 줄 알고 열심히 원인을 찾았으나 보이지 않아서 종이로 출력해서 한줄 한줄 뜯어보고 있었습니다. 그런데 제가 나무위키 문법을 HTML로 변환하는 함수 부분의 리턴 값의 자료형을 short을 썼더군요. 그런데 나무위키 최장 길이 문서는 short범위를 아득히 초월했고, short 가 오버플로우를 일으켰습니다.

2.

short 문제를 해결하고 나서 mdxbuilder에서 오류가 나길래 출력된 파일을 뜯어보았습니다. 그런데 태평양 같이 넓은 NULL 문자로 가득찬 영역이 있었어요. 해결할려고 소스를 보니까 손을 못대겠어요. 사실 멀티쓰레딩을 OpenMP로 구현해놓고 별 문제 없는줄 알았는데 첫 쓰레드를 제외한 출력 버퍼가 비어 있었어요.(고로 문서의 대부분이 공백...) 해결하려고 해도 도통 OpenMP의 메커니즘을 모르겠고 파일을 배포할 떄 라이브러리를 같이 넣어야 한다는 것이 귀찮아서 Pthread로 갈아탔습니다. 이제 그냥 단일파일로 실행할 수 있겠죠

3.

Pthread로 다시 작성하고 나서도 포인터 오류가 나길래 코드를 찬찬히 살펴보았으나 기존 코드와 근본적으로 동일해서 몇번을 살펴봤습니다. 그런데 사실 다른 문제도 아니고 쓰레드 번호 문제였습니다. 쓰레드 번호가 종료된다고 해서 0부터 할당하는 구조가 아니더군요. 0,1,2,3,4,5,6,7,8,... 로 증가하네요. 그래서 Cdoc[CORE]로 선언하고 Cdoc[0],Cdoc[1],~~,Cdoc[CORE-1] 에 저장된 동적 할당 메모리 포인터를 사용하는 부분에서 Cdoc[15]같은 존재하지도 않는 변수를 불러오고 있었어요. 그래서 해결을 위해 쓰레드 번호를 Cdoc[(CORE로 나눈 나머지)] 로 구현해 놓았습니다. CORE 값이 4이니 Cdoc[0],Cdoc[1],Cdoc[2],Cdoc[3] 밖에 없으므로 쓰레드 번호를 4로 나누면 0,1,2,3 밖에 나오지 않겠죠. 그래도 나중에 쓰레드 번호가 연속이 아닌 것을 대비해야 할지도 몰라요.

4.

아직도 mdxbuilder에서 Invalid keyword at position: (숫자) of the source file 가 뜨면서 변환해주지 않네요. 분명 Python 으로 만들 떄는 원인을 알고 있었던 것 같은데 기억이 나지 않네요. 그래도 저 숫자 자리에 보면 뭐가 문제인지 알 수 있겠죠. 그래서 Hexedit을 써서 그 위치를 찾아보니 웬 평범한 문서가 나와서 당황했습니다. 그런데 갑자기 "설마 나무위키 문서 내용 중에 < 나 > 가 들어가서 간섭하는 것이 아닐까?"하는 직감이 들어서 테스트해 보았으나 이것도 에러가 나네요. 다시 Hexedit으로 확인해 보니 문서 이름 앞에 이상한 문자가 들어가서 문제가 생긴 것이었어요. 이제 프로그램 자체에서 에러를 처리하도록 조치를 취해야겠어요.

5.

변환 결과창을 보니 문서를 대거 스킵해 버린 듯 해요. 어디서 문제인지는 모르겠어요. 그런데 더 큰 문제가 있었어요.

몇몇 문서가 최대 쓰레드 수만큼 분신술을 쓴 듯 해요. 이런. 심지어 개행도 안 되어 있어요.

 

무서운 말 : Trust the programmer.