대상: electron/electron

이슈: electron/electron#51988

풀 리퀘스트 (Pull request): electron/electron#52238

필드 랩 (Field Lab) 기록: Electron #51988

이번 필드 테스트는 크래시 (crash)에 관한 것이었지만, 진짜 경계는 "Linux는 어렵다"가 아니었습니다.

그것은 너무 모호할 것입니다.

공개된 이슈에 따르면, Electron이 Qt 지원을 포함하여 빌드되고 Chromium이 Qt 백엔드 (backend)를 선택했을 때, 특히 Arch Linux / KDE 스타일 환경에서 네이티브 Electron 메시지 박스 (message boxes)가 Linux에서 세그먼테이션 결함 (segfault)을 일으킬 수 있다고 보고되었습니다.

실패하는 경로는 좁았습니다.

Electron의 GTK 메시지 박스 (message-box) 코드는 GTK 플랫폼 객체 (platform object)가 필요했습니다.

하지만 코드 경로는 활성화된 Linux UI 싱글톤 (singleton)을 마치 GTK인 것처럼 취급하고 있었습니다.

이러한 가정은 활성화된 Linux UI 구현체가 실제로 GTK일 때만 안전합니다.

활성화된 구현체가 Qt일 때, 그 가정은 경계를 넘어서게 됩니다.

그리고 이 경우, 그 경계를 넘어서는 것이 세그먼테이션 결함 (segfault)으로 이어질 수 있었습니다.

필드 랩 (Field Lab) 기록

이 사례에 대한 공개 필드 랩 (Field Lab) 기록은 여기에 있습니다:

https://github.com/scarab-systems/scarab-field-lab/tree/main/field-tests/electron-electron-51988

기록에는 공개 이슈, 공개 풀 리퀘스트 (pull request), 진단 결과, 수정 범위 (repair scope), 검증 요약, 공개 리뷰 상태 및 비주장 사항 (non-claims)이 포함되어 있습니다.

이는 공개 링크, 상태, 검증 및 주장 경계만을 포함합니다.

SDS 소스 코드나 비공개 제품 자료는 포함하지 않습니다.

사례 기록은 오직 공개 증거 계층 (evidence layer)일 뿐입니다.

SDS 결과

SDS는 Electron의 네이티브 메시지 박스 (message-box) 경로에서 Linux UI 테마 경계를 찾아냈습니다.

중요한 발견은 Electron의 공개 다이얼로그 API (dialog API)를 변경해야 한다는 것이 아니었습니다.

Chromium의 Qt 백엔드 (backend)를 제거해야 한다는 것도 아니었습니다.

Arch, KDE, VS Code 또는 다운스트림 패키저 (packagers)가 올바른 수정 대상이라는 것도 아니었습니다.

발견된 내용은 더 작았습니다:

Electron의 GTK 메시지 박스 (message-box) 코드는 GTK 플랫폼 동작을 사용하기 전에 GTK 전용 Linux UI 테마를 검색해야 했습니다.

그러한 구분은 중요합니다. 왜냐하면 Linux 데스크톱 통합 (Desktop integration)은 외부에서 보기에는 인접해 보이지만, 실제로는 여러 계층으로 구성되어 있는 경우가 많기 때문입니다:

Electron API.

Chromium UI 백엔드 (backend).

GTK 구현 (implementation).

Qt 구현 (implementation).

데스크톱 환경 (Desktop environment).

배포판 빌드 플래그 (Distribution build flags).

충돌 (Crash)은 애플리케이션 계층에서 발생할 수 있지만, 수정해야 할 경계 (repair boundary)는 그보다 여러 계층 아래에 있을 수 있습니다.

이 경우, 문제는 "메시지 박스가 고장 났다"가 아니었습니다.

문제는 GTK 메시지 박스 (message-box) 경로가 GTK 전용 객체가 필요한 상황에서 활성화된 Linux UI 객체에 의존하고 있었다는 점이었습니다.

실패 형태 (Failure shape)

실패 형태는 잘못된 플랫폼 가정 (platform assumption)이었습니다.

공개된 이슈는 Qt 기반 Linux 빌드에서 Electron의 message-box API를 호출할 때 발생하는 충돌을 설명했습니다.

재현 범위 (reproduction surface)는 간단했습니다:

네이티브 메시지 박스를 표시하는 것.

하지만 충돌은 JavaScript API 형태에서 발생한 것이 아니었습니다.

보고된 경로는 Electron의 GTK message-box 구현 내부를 가리켰으며, 그곳의 GetGtkUiPlatform은 활성화된 Linux UI 싱글톤 (singleton)을 GTK로 캐스팅 (cast) 할 수 있다고 가정하고 있었습니다.

그 가정은 취약합니다.

Chromium이 Qt 백엔드를 사용하고 있을 때, 활성화된 Linux UI 구현은 GTK가 아닐 수 있습니다.

따라서 코드는 GTK 플랫폼 동작을 수행하기 위해 잘못된 객체에 요청을 보내게 될 수 있습니다.

이것은 소스 코드 형태로는 극적으로 보이지 않는 종류의 버그입니다.

방대한 아키텍처 실패도 아닙니다.

누락된 기능도 아닙니다.

플랫폼 경계에서 발생한 단 한 번의 잘못된 식별 (mistaken identity)일 뿐입니다.

하지만 네이티브 C++ 코드에서의 잘못된 식별 버그는 정중하게 실패하지 않습니다.

"잘못된 객체"에서 "유효하지 않은 포인터 (invalid pointer)"를 거쳐 "세그폴트 (segfault)"로 급격히 이어질 수 있습니다.

경계 (Boundary)

이 필드 테스트에서의 경계는 다음과 같습니다:

GTK message-box 동작은 활성화된 Linux UI 싱글톤이 GTK라고 가정함으로써 얻는 것이 아니라, GTK 전용 Linux UI 테마로부터 GTK 플랫폼 지원을 얻어야 합니다.

이것은 사소하기 때문에 사소하게 들립니다.

하지만 동시에 매우 정밀한 지점입니다.

활성화된 Linux UI 구현은 다음 질문에 답합니다:

현재 어떤 UI 백엔드가 활성화되어 있는가?

GTK message-box 코드는 다른 질문에 답해야 합니다:

이 GTK message-box 경로에 필요한 GTK platform 객체는 어디에 있는가?

이것들은 서로 다른 질문입니다.

GTK 기반의 Linux 실행 환경에서는 그 차이가 보이지 않을 수 있습니다.

Qt 기반의 실행 환경에서는 그 차이가 버그가 됩니다.

이것이 바로 이번 수정 사항이 Electron의 Linux 대화 상자(dialog) 시스템을 재설계하려고 시도하지 않은 이유입니다.

Electron의 공개된 message-box 동작을 변경하려고 시도하지 않았습니다.

모든 업스트림(upstream) Electron 바이너리가 영향을 받았다고 주장하지도 않았습니다.

단지 조회 경계(lookup boundary)를 바로잡았습니다.

변경 사항

이번 수정은 Electron의 Linux GTK message-box 구현 내의 좁은 범위의 C++ 변경 사항입니다.

풀 리퀘스트(pull request)는 여기 있습니다:

https://github.com/electron/electron/pull/52238

변경 된 공개 파일은 다음과 같습니다:

shell/browser/ui/message_box_gtk.cc

패치는 GTK platform 조회를 변경하여, 코드가 GTK platform을 가져오기 전에 다음과 같이 GTK 전용 Linux UI 테마를 요청하도록 합니다:

ui::GetLinuxUiTheme(ui::SystemTheme::kGtk)

또한 사용하기 전에 GTK UI 객체와 GTK platform 포인터를 모두 확인합니다.

이것이 수정 사항의 전체 형태입니다.

공개 API 변경 없음.

JavaScript API 변경 없음.

문서 변경 없음.

Electron의 릴리스 바이너리가 기본적으로 영향을 받는다는 주장 없음.

해당 PR이 업스트림에 수락되었다는 주장 없음.

단지 검토를 위해 제출된 좁은 범위의 네이티브 플랫폼(native-platform) 수정 사항일 뿐입니다.

이것이 광범위한 Linux 수정이 아니었던 이유

진단 작업에서 빠지기 쉬운 함정 중 하나는 환경을 설명의 도구로 삼아버리는 것입니다.

Linux.

KDE.

Arch.

Qt.

Chromium.

Electron.

네이티브 대화 상자(Native dialogs).

이 단어들 중 어느 하나라도 안개를 만드는 기계가 될 수 있습니다.

이번 필드 테스트의 목적은 그 안개에 멈추지 않는 것이었습니다.

공개 보고서에는 이미 강력한 단서가 포함되어 있었습니다: GTK 백엔드를 강제하면 문제가 해결되었지만, Qt 기반 경로는 세그멘테이션 결함(segfault)이 발생할 수 있다는 점입니다.

그것이 진단 질문을 설정했습니다:

비-GTK(non-GTK) 활성 UI 객체를 통해 GTK 전용 동작에 도달하는 지점은 어디인가?

그 질문이 명확해지자, 수정 경계는 더 좁아졌습니다.

이 문제는 SDS가 새로운 대화 상자 (dialog) 시스템을 발명할 필요를 요구하지 않았습니다.

하위 패키징 이론 (downstream packaging theory)을 요구하지도 않았습니다.

이미 코드베이스에 존재하던 UI 테마 경계 (UI theme boundary)를 존중할 것을 요구했을 뿐입니다.

그것이 바로 Scarab이 테스트하고 있는 진단 패턴입니다:

충돌 (crash)이 극적이라고 해서 패치 (patch)의 범위를 넓히지 마십시오.

가정이 거짓이 되는 정확한 계층 (layer)을 찾으십시오.

그곳을 패치하십시오.

진단 결과가 중요했던 이유

이 필드 테스트의 더 큰 핵심은 C++ 파일 하나가 변경되었다는 것이 아닙니다.

더 큰 핵심은 네이티브 충돌 복구 (native crash repair)가 잘못된 가정을 정확하게 명명하는 것에 달려 있다는 점입니다.

잘못된 복구는 증상만을 쫓았을 수도 있습니다.

잘못된 위치에 Qt 전용 조건문 (conditionals)을 추가했을 수도 있습니다.

데스크톱 환경 (desktop environment)을 결함으로 취급했을 수도 있습니다.

버그가 내부 조회 경로 (internal lookup path) 안에 있었음에도 불구하고 공개적인 동작 (public behavior)을 변경했을 수도 있습니다.

더 나은 복구 방식은 더 조용했습니다:

GTK 플랫폼을 사용하기 전에 GTK UI 테마를 요청하는 것입니다.

이것이 바로 경계가 발견된 후에는 당연해 보이는 종류의 변경 사항입니다.

경계가 발견되기 전에는, 동일한 문제가 마치 리눅스 데스크톱의 늪처럼 보일 수 있습니다.

이 지점에서 진단 도구 (diagnostic tooling)가 유용해집니다.

도구가 마법처럼 가장 큰 패치를 작성해주기 때문이 아닙니다.

패치가 정직할 수 있을 만큼 충분히 작아질 때까지 주장을 좁혀나가는 데 도움을 주기 때문입니다.

검증 (Validation)

복구 사항은 Electron 저장소(repository)를 대상으로 검증되었으며, 관련 공개 체크 사항은 Field Lab에 기록되었습니다.

풀 리퀘스트 (pull request)에 기록된 검증 내용:

yarn lint:cpp --only -- shell/browser/ui/message_box_gtk.cc
third_party/ninja/ninja -C out/LinuxTesting obj/electron/electron_lib/message_box_gtk.o

객체 재빌드 (object rebuild)를 위해, Ninja가 변경된 C++ 파일을 다시 빌드할 수 있도록 이전의 message_box_gtk.o 및 message_box_gtk.dwo 출력물을 먼저 제거했습니다.

이 필드 보고서가 작성된 2026년 7월 2일 당시, 공개 풀 리퀘스트는 열려 있었으며 업스트림 (upstream) 리뷰를 받을 준비가 되어 있었습니다.

공개 상태는 다음과 같습니다:

PR open

non-draft

mergeable

review required

PR template passed

signed commits passed

release note check passed

Socket checks passed

semver / backport / faraday 작업이 기록 대기 중 (pending at recording)

이 필드 보고서는 업스트림 (upstream) 수락을 주장하지 않습니다.

이는 공개적인 진단 기록, 국소적인 C++ 수정 (repair), 로컬 검증 (local validation), 그리고 제출된 업스트림 PR (Pull Request)을 주장합니다.

메인테이너 (Maintainers)가 해당 변경 사항이 업스트림에 속하는지 여부를 결정합니다.

필드 테스트 결과 (Field test result)

결과:

진단 증거 및 네이티브 플랫폼 (native-platform) 수정 사항이 제출되었습니다.

필드 테스트를 통해 다음이 생성되었습니다:

issue-to-boundary 공개 기록

국소적인 C++ 패치 (patch)

영향을 받은 파일에 대한 검증 (validation)

공개적인 업스트림 PR

Scarab Field Lab의 공개 상태 기록

패치는 의도적으로 작게 구성되었습니다.

그것이 핵심입니다.

실패 원인이 UI 테마 소스 경계 (UI-theme source-boundary) 버그일 때, 최선의 수정은 UI 스택 전체를 재설계하는 것이 아닙니다.

최선의 수정은 적절한 레이어 (layer)에 적절한 객체 (object)를 요청하는 것입니다.

공개 주장 (Public claim)

이 필드 테스트는 다음과 같은 국소적인 공개 주장을 뒷받침합니다:

SDS는 Electron의 GTK 메시지 박스 (message-box) 경로에서 Linux UI 테마 경계를 식별했습니다. 해당 경로에서는 활성화된 Linux UI 싱글톤 (singleton)을 통해 GTK 플랫폼 동작에 도달하고 있었으며, GTK 플랫폼을 가져오기 전에 GTK 전용 Linux UI 테마를 요청하도록 하는 사람이 제출한 C++ 수정 사항이 준비되었습니다.

다음 사항은 주장하지 않습니다:

Electron이 패치를 수락했다는 점

PR이 머지 (merge) 되었다는 점

모든 Electron Linux 빌드가 영향을 받는다는 점

업스트림 Electron 릴리스 바이너리 (release binaries)가 기본적으로 영향을 받는다는 점

Chromium의 Qt 백엔드 (backend)가 결함이 있다는 점

Arch Linux 또는 KDE가 버그를 유발했다는 점

Electron의 공개 다이얼로그 API (dialog API)가 변경되었다는 점

Scarab이 스스로 프로젝트를 수정한다는 점

SDS 소스 또는 제품 세부 정보가 공개되어 있다는 점

메인테이너가 Scarab 또는 Field Lab을 보증했다는 점

Field Lab은 이러한 주장들을 분리하여 유지하기 위해 존재합니다.

공개 (Disclosure)

이 필드 보고서는 공개된 필드 테스트 노트, 공개된 이슈 (issue) 및 PR 기록, 그리고 공개된 Field Lab 기록을 바탕으로 AI 보조 편집을 통해 작성되었습니다. 진단 주장, 수정 경계 (repair boundary), 그리고 최종 문구는 사람이 검토하였습니다.

Scarab Diagnostic Suite는 독점 소프트웨어입니다. Field Lab은 공개 사례 기록, 이슈 링크, 검증 요약, 그리고 주장 경계 (claim boundaries)만을 게시합니다.

SDS는 증거를 찾습니다. 사람들은 주장을 합니다. 유지 관리자 (Maintainers)가 결정합니다.