들어가며
디버깅을 보다 생산적으로 만들 수 있는 breakpoint improvement를 알아보자!
breakpoint
: 만약 당신이 프로그램에서 버그가 발생하면 예상대로 실행되지 않고, 디버거를 통해서 확인하려고 한다.1.
프로세스 상태를 검사해서 상황을 자세히 파악하기
2.
프로세스 실행을 통해서 논리를 확인하기
두 상황 다 버그가 발생하기 직전에 일시 중지해야 한다.
breakpoint를 사용하게 된다.
3가지 일반적인 breakpoint를 알아보자.
Source file breakpoints
•
single file
•
Line breakpoint
•
검사하려는 코드 줄에서 일시 중지하는 데 적합
가장 빠른 사용 방법
일시 중지할 줄 바로 옆에 있는 gutter를 클릭하는 것
: 다른 expressing으로 stepping하고 있어요. 컴파일러는 adjustedDensity를 먼저 실행해야 한다고 결정했습니다. : step out으로 잠시 나갔다가 다시 기능으로 돌아갈 수 있지만, 이런 걸 여러 번 반복한다면 힘들거예요.
line breakpoint가 충분히 세분화되지 않은 경우가 있기 때문에 발생
why?
LLDB가 정지할 위치를 하나 이상 생성했기 때문이다.
: 내가 원하는 건 convertedToVolume이 실행되기 직전에 일시 중지하는 것
Xcode 13에서는 Column breakpoint를 도입하고 있습니다.
이렇게 하면 특정 expression에서 일시 중지해야 할 때 생기는 line breakpoint의 단점을 방지한다.
expression를 클릭해서 pop over를 연 다음에 Set Column Breakpoint를 선택합니다.
•
비활성화, 활성화 가능
•
breakpoint를 수정해야하는 경우, 두 번 클릭
Control 또는 마우스 오른쪽 버튼을 클릭하면 이전 작업이 포함된 상황별 메뉴가 나타납니다.
: 저는 breakpoint navigator를 표시하겠습니다.
Xcode 11.4에서는 Column PC를 도입해서 expression 아래에 녹색 밑줄을 그려 일시 중지된 column를 표시합니다. 따라서 디버거가 다음에 실행할 식을 알 수 있습니다.
Column breakpoint는 특히 Swift Closure나 Objective-C의 Block에 유용합니다.
: Swift Closure는 가끔 multiple closure를 가집니다. 
•
컴파일러는 디버그 조건에서 파일을 컴파일할 때 source line과 column을 컴파일된 주소로 매핑하는 line table를 만듭니다.
•
이 line에 있는 각 클로저에 대해 컴파일러는 디버거가 일시 중지하는 데 사용할 line table 항목을 생성합니다.
만약 $0를 검사하고 싶다고 가정하면,
breakpoint를 line 269로 설정할 수 있지만, 일시 중지한 후에 마지막 closure에 도달하려면 생성된 line table 항목으로 인해서 수많은 step in과 step out를 수행해야 합니다.
: Xcode 13을 사용하면 마지막 $0에 column breakpoint를 간단히 설정할 수 있으며 일시 중지하면 원하는 위치에 정확히 도달하고 $0를 마음껏 검사할 수 있습니다.Symbolic breakpoints
•
breakpoints on function names → pause the process when functions are executed.
•
원본 파일 breakpoint를 사용할 수 없거나 불편할 때 매우 유용
◦
source file에 access할 수 없어서 디버그 정보로 컴파일할 수 없을 때
◦
공통 기능을 구현하는 많은 하위 클래스가 있으며 각 하위 클래스마다 파일 breakpoint를 설정하는 건 매우 번거로운 일
1.
breakpoint navigator 하단에 있는 추가 버튼을 눌러서 추가합니다.
2.
Symbolic breakpoint를 누르면 즉시 breakpoint navigator에 나타납니다.
3.
예를 들어서 우리가 toggle 함수를 일시 중지하는 데 관심이 있다고 가정을 하고 넣어봅니다.
: 흔한 단어인 함수 이름은 조심할 필요가 있어요.Why?
LLDB가 시스템 라이브러리를 포함하여 프로세스에서 로드되는 모든 라이브러리의 이름과 일치하기 때문입니다!
breakpoint의 위치가 여러 개가 될 수 있으며, 때로는 수천 개가 될 수 있어요.!
: 고맙게도 특정 모듈로 검색을 제한할 수 있습니다.
모듈은 main binary를 포함하여 실행 중에 로드할 수 있는 binary or image입니다.
예시에서는 앱의 바이너리 이름은 “Fruta”를 넣었습니다.
세 곳의 위치를 빠르게 찾았습니다.
[ 좋아요 버튼을 누르자, toggle 함수가 실행되는 모습 ]
좋아요 버튼을 누르자, toggle 함수가 실행되는 모습 ]
symbolic breakpoint의 경우, typographic error를 범하기 상당히 쉽다.
우리는 프로그램을 실행하는 동안 breakpoint에 부딪히지 않고 머리를 긁적이게 됩니다. ⁇
⁇convertToMass라고 불리는 것을 만들어봐요.
Xcode 13의 새로운 기능으로 LLDB에 의해 breakpoint가 어떤 위치에서도 해결되지 않으면 점선 아이콘으로 표시됩니다.
unresolved breakpoint 아이콘 위로 마우스를 가져가면 도움이 되는 툴팁을 제공합니다.
1.
이름은 정확하게 철자를 써야 하고 기호는 라이브러리에 존재해야 합니다.
2.
breakpoint에 대한 라이브러리 로드 → LLDB가 자동으로 breakpoint을 해결
: 이번에는 제가 철자를 잘못 쓴 거 같네요.;;
네비게이터를 사용하여 convert 를 찾아볼 수 있겠죠.
but, 분석하려면 시간이 좀 걸리겠네요;
LLDB를 통해서 다른 방법을 사용합시다!
image lookup -rn convert Fruta
module : image, regex : lookup -r, name: n, convert를 Fruta에 입력해서 검색하는걸로 제한합니다.
이름 철자가 확실히 틀렸네요.
Unresolved breakpoint는 source file breakpoint에서도 볼 수 있습니다.
Unresolved된 이유는
1.
breakpoint에 대한 line를 컴파일해야 합니다.
•
예시에서는 컴파일러 조건이 다른 부분에 있기 때문에 컴파일되지 않았다.
2.
컴파일러는 모듈에 대한 디버그 정보를 생성해야 합니다.
•
그렇지 않은 경우 빌드 설정을 확인해야 합니다.
Runtime issue breakpoints
•
background thread에서 UI 상태를 변경하는 등의 런타임에 발생하는 문제
•
crash만큼 심각하지는 않으며, 기본적으로 Xcode는 프로세스를 일시 중지하지 않음
◦
다른 버그에 초점을 맞출 때 너무 큰 문제가 발생할 수 있기 때문
◦
대신 런타임 문제가 발생하면 Xcode는 backtrace를 기록하고 이슈 탐색기에 표시합니다.
runtime breakpoint를 사용하면 디버거에서 일시 중지하고 프로세스를 탐색할 수 있습니다.
: runtime breakpoint에는 여러 가지 유형이 있습니다. 팝업을 사용해서 특정 유형을 쉽게 선택할 수 있어요!
: 일부는 편집기에서 해당 기능을 활성화해야 합니다. 이동 버튼을 누르면 갈 수 있어요!
