[インデックス 17137] ファイルの概要

このコミットは、Goランタイムのテストに関する改善であり、特にdeferされた関数がnilインターフェースに対して呼び出された際にパニックが発生した場合のトレースバックの品質向上を目的としています。test/fixedbugs/issue6055.goファイルは、この特定のシナリオを再現し、jmpdeferがスタック上に存在する場合に適切なトレースバックが得られることを検証するためのテストケースとして追加されています。

コミット

commit 36f223dace5dcdb7afc381c51e0484ff473e2e88
Author: Keith Randall <khr@golang.org>
Date:   Fri Aug 9 15:27:45 2013 -0700

    runtime: Better test tracebackability of jmpdefer when running a nil defer.
    
    R=bradfitz, dvyukov
    CC=golang-dev
    https://golang.org/cl/12536046

GitHub上でのコミットページへのリンク

https://github.com/golang/go/commit/36f223dace5dcdb7afc381c51e0484ff473e2e88

元コミット内容

runtime: Better test tracebackability of jmpdefer when running a nil defer.

R=bradfitz, dvyukov
CC=golang-dev
https://golang.org/cl/12536046

変更の背景

Go言語のdeferステートメントは、関数の終了時に特定の処理を実行するために非常に便利です。しかし、deferされた関数がnilインターフェースやnil関数に対して呼び出された場合、実行時にパニックが発生します。このパニックが発生した際に、スタックトレースがデバッグに役立つ情報を提供することが重要です。

特に、Goランタイム内部のjmpdeferというアセンブリ関数がdefer呼び出しの実行に関与している場合、そのjmpdeferがスタックトレースに適切に表示されることが、問題の診断において重要となります。このコミットの背景には、nilインターフェースに対するdefer呼び出しがパニックを起こした際に、jmpdeferがスタック上に存在している状況で、より正確で有用なトレースバックが得られるようにテストを改善するという目的があります。これにより、将来的に同様の問題が発生した場合のデバッグが容易になります。

前提知識の解説

Goの`defer`の仕組み

deferステートメントは、Goにおいて関数の実行が終了する直前（returnステートメントの直前、またはパニック発生時）に、指定された関数呼び出しをスケジュールします。複数のdeferステートメントがある場合、それらはLIFO（Last-In, First-Out）の順序で実行されます。

重要な点として、deferステートメントが評価される際、遅延される関数の引数（メソッド呼び出しの場合はレシーバも含む）は、deferが宣言された時点で即座に評価され、保存されます。実際の関数実行は、囲む関数が戻るまで遅延されます。

`nil`インターフェース/関数に対する`defer`呼び出しの挙動

Goでは、nilインターフェースに対してメソッドを呼び出したり、nil関数を呼び出したりすると、ランタイムパニックが発生します。deferされた呼び出しの場合も同様で、deferが宣言された時点で引数が評価されても、実際の関数実行時にレシーバや関数がnilであると、その時点でパニックが発生します。

例:

type Closer interface {
    Close()
}

func nilInterfaceDeferCall() {
    var x Closer // x は nil
    defer x.Close() // ここで x は nil と評価されるが、Close() の実行は遅延される
    // ...
}
// nilInterfaceDeferCall() が終了する際に x.Close() が実行され、nilレシーバのためパニック

`jmpdefer`の役割

jmpdeferは、Goランタイム内部で使用されるアセンブリ関数（runtime.jmpdefer）であり、deferされた関数の実行フローを制御する上で重要な役割を担っています。Go 1.13以前のdeferの実装では、defer呼び出しはruntime._defer構造体としてヒープに割り当てられ、deferチェーンに格納されていました。関数が戻る際にruntime.deferreturnがこのチェーンを辿り、jmpdeferを呼び出して実際に遅延された関数を実行していました。

jmpdeferは、遅延された関数のアドレスとスタックポインタを受け取り、スタックを操作してその関数に制御を移します。これにより、遅延された関数が、あたかもdeferreturnが呼び出された場所から直接呼び出されたかのように実行されるように見せかけます。

Go 1.13以降では、deferの最適化（スタック割り当てやオープンコーディング）が進み、すべてのdeferがjmpdeferを介して実行されるわけではありませんが、特定の複雑なケースや、最適化の条件を満たさない場合には、依然としてjmpdeferが使用されます。

`runtime.GC()`の役割とトレースバックにおける意味

runtime.GC()は、Goのガベージコレクタを明示的にトリガーする関数です。通常、ガベージコレクションはランタイムによって自動的に管理されますが、runtime.GC()を呼び出すことで、任意のタイミングでガベージコレクションを実行させることができます。

このコミットの文脈では、runtime.GC()を呼び出すこと自体が重要なのではなく、runtime.GC()が呼び出されることで、その呼び出しがスタックトレースに現れるという点が重要です。テストの目的は、jmpdeferがスタック上に存在している状態でパニックを発生させ、そのトレースバックを検証することです。runtime.GC()をdefer内で呼び出すことで、jmpdeferがアクティブな状態で別のdeferがパニックを起こすという、より複雑なシナリオをシミュレートし、トレースバックの網羅性を高めています。

技術的詳細

このコミットは、nilインターフェースに対するdefer呼び出しがパニックを起こす際に、Goランタイムのjmpdefer関数がスタックトレースに適切に現れることを保証するためのテストケースの改善です。

既存のnilInterfaceDeferCall関数は、var x Closer; defer x.Close()というコードを含んでおり、これは関数終了時にnilレシーバに対するメソッド呼び出しによってパニックを引き起こします。このパニックのスタックトレースが、デバッグ時に重要な情報を提供する必要があります。

このコミットでは、nilInterfaceDeferCall関数に新しいdeferブロックが追加されています。

defer func() {
    // make sure a traceback happens with jmpdefer on the stack
    runtime.GC()
}()

この新しいdeferは、元のdefer x.Close()よりも後に宣言されているため、LIFOの原則により、nil x.Close()のパニックよりも前に実行されます。この新しいdefer内でruntime.GC()が呼び出されます。

なぜruntime.GC()を呼び出すのか？ runtime.GC()の呼び出し自体が、Goランタイムの内部処理をトリガーし、その過程でjmpdeferがスタック上に現れる可能性があります。このコミットの目的は、jmpdeferがスタック上に存在している状態で、nilインターフェースに対するdefer呼び出し（x.Close()）がパニックを起こすという、特定の複雑な状況をテストすることです。

もしjmpdeferがスタック上にない状態でパニックが発生した場合、トレースバックは異なるものになるかもしれません。このテストは、jmpdeferが関与するdeferの実行パスでパニックが発生した場合でも、トレースバックが期待通りに、かつデバッグに役立つ形で生成されることを確認するためのものです。

つまり、この変更は、特定のランタイムの内部状態（jmpdeferがスタック上にある状態）を意図的に作り出し、その状態でのパニックのトレースバックが正しく機能するかを検証するための、より堅牢なテストシナリオを導入しています。

コアとなるコードの変更箇所

変更はtest/fixedbugs/issue6055.goファイルに対して行われています。

--- a/test/fixedbugs/issue6055.go
+++ b/test/fixedbugs/issue6055.go
@@ -6,11 +6,17 @@
 
  package main
 
 +import "runtime"
 +
  type Closer interface {
  	Close()
  }
 
  func nilInterfaceDeferCall() {
 +\tdefer func() {
 +\t\t// make sure a traceback happens with jmpdefer on the stack
 +\t\truntime.GC()
 +\t}()
  	var x Closer
  	defer x.Close()
  }

具体的には、以下の変更が加えられています。

import "runtime" が追加されました。

nilInterfaceDeferCall 関数内に新しいdeferブロックが追加されました。

defer func() {
    // make sure a traceback happens with jmpdefer on the stack
    runtime.GC()
}()

コアとなるコードの解説

追加されたdeferブロックは、nilInterfaceDeferCall関数内で既存のdefer x.Close()の前に実行されるように配置されています（GoのdeferはLIFOなので、後から宣言されたものが先に実行されます）。

func nilInterfaceDeferCall() {
    // このdeferが先に実行される
    defer func() {
        // make sure a traceback happens with jmpdefer on the stack
        runtime.GC() // ここでGCをトリガーし、jmpdeferがスタック上に現れる可能性を高める
    }()
    var x Closer
    // このdeferが後に実行され、nilレシーバでパニック
    defer x.Close()
}

この新しいdefer内でruntime.GC()を呼び出すことで、ガベージコレクションが実行されます。ガベージコレクションの実行は、Goランタイムの内部処理を伴い、その過程でjmpdeferのような低レベルのランタイム関数がスタック上に現れる可能性があります。

このテストの意図は、jmpdeferがスタック上に存在している状態で、その後に実行されるdefer x.Close()がnilレシーバによってパニックを引き起こすシナリオを再現することです。これにより、パニック発生時のスタックトレースにjmpdeferが適切に含まれ、デバッグ時にdeferの実行メカニズムに関するより詳細な情報が得られることを検証しています。

要するに、このコード変更は、特定のランタイムの内部状態（jmpdeferがスタック上にある状態）を意図的に作り出し、その状態でのパニックのトレースバックが正しく機能するかを検証するための、より堅牢なテストシナリオを導入しています。

参考にした情報源リンク

Go defer mechanism:
Go nil defer call behavior:
- https://go.dev/blog/defer-panic-and-recover
- https://peng.fyi/post/go-defer-nil-interface/
- https://github.com/golang/go/issues/47799 (Go 1.21 panic(nil) behavior change)
Go runtime.GC() traceback:
jmpdefer in Go:
- https://cnblogs.com/qcrao-gopher/p/14900000.html (Chinese, but explains jmpdefer in context of defer implementation)
- https://medium.com/@siddharth_goel/understanding-defer-in-go-a-deep-dive-into-its-mechanisms-and-optimizations-212121212121 (Mentions jmpdefer in the context of older defer implementation)

comemo