2026年10月29日木曜日

gdb の使い方メモ

gdb の使い方メモ

概要

軽く触ってみたので gdb を使い方をメモしておきます

環境

  • macOS 26.6.2
  • gdb

ツールのインストール

  • apt -y update
  • apt -y install python3 gdb net-tools vim iproute2 lsof

プロセス確認

  • ss -ltnp 'sport = :80'
State        Recv-Q       Send-Q             Local Address:Port               Peer Address:Port       Process                               
LISTEN       0            511                      0.0.0.0:80                      0.0.0.0:*           users:(("apache2",pid=1,fd=3))       
  • lsof -nP -iTCP:80 -sTCP:LISTEN
COMMAND PID USER FD   TYPE DEVICE SIZE/OFF NODE NAME
apache2   1 root 3u  IPv4   5336      0t0  TCP *:80 (LISTEN)
  • ps aux
USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root           1  0.0  0.7 194460 30372 ?        ts   03:11   0:00 apache2 -DFOREGROUND
www-data      19  0.0  0.4 194540 17172 ?        S    03:11   0:00 apache2 -DFOREGROUND
www-data      20  0.0  0.4 194540 16400 ?        S    03:11   0:00 apache2 -DFOREGROUND
www-data      21  0.0  0.4 194548 16472 ?        S    03:11   0:00 apache2 -DFOREGROUND
www-data      22  0.0  0.4 194532 16648 ?        S    03:11   0:00 apache2 -DFOREGROUND
www-data      23  0.0  0.4 194532 16648 ?        S    03:11   0:00 apache2 -DFOREGROUND
root          62  0.0  0.0   4176  3536 pts/0    Ss   03:46   0:00 /bin/bash
www-data     648  0.0  0.2 194492 11388 ?        S    04:23   0:00 apache2 -DFOREGROUND
root        1095  0.1  1.7 684188 68600 pts/0    Sl+  04:49   0:00 gdb -q -p 1
root        1106  0.0  0.0   4176  3492 pts/1    Ss   04:57   0:00 /bin/bash
root        1117 66.6  0.0   6016  3284 pts/1    R+   05:02   0:00 ps aux

gdb 起動

  • gdb -q -p 19

gdb 観察

php_session_reset_id は今回のアップロード処理ではコールされてなかったことを示すログです

(gdb) info functions php_session_reset_id
All functions matching regular expression "php_session_reset_id":

Non-debugging symbols:
0x0000ffffb5a19310  php_session_reset_id@plt
0x0000ffffb5c92104  php_session_reset_id

(gdb) break php_session_reset_id
Breakpoint 1 at 0xffffb5c92108

(gdb) info breakpoints
Num     Type           Disp Enb Address            What
1       breakpoint     keep y   0x0000ffffb5c92108 <php_session_reset_id+4>

(gdb) continue
Continuing.
[Inferior 1 (process 1120) exited normally]

次に php_handler を観測します
php_handler はアップロード処理で libphp.so を使ってコールされたのでブレークポイントで停止します

(gdb) break php_handler
Breakpoint 1 at 0xffffb5f004c8
(gdb) continue
Continuing.

Breakpoint 1, 0x0000ffffb5f004c8 in php_handler () from /usr/lib/apache2/modules/libphp.so
(gdb) bt
#0  0x0000ffffb5f004c8 in php_handler () from /usr/lib/apache2/modules/libphp.so
#1  0x0000aaaaea10d474 in ap_run_handler ()
#2  0x0000aaaaea10dbf4 [PAC] in ap_invoke_handler ()
#3  0x0000aaaaea12777c [PAC] in ap_process_async_request ()
#4  0x0000aaaaea127938 [PAC] in ap_process_request ()
#5  0x0000aaaaea12380c [PAC] in ?? ()
#6  0x0000aaaaea117834 [PAC] in ap_run_process_connection ()
#7  0x0000ffffb6bf43c0 [PAC] in ?? () from /usr/lib/apache2/modules/mod_mpm_prefork.so
#8  0x0000ffffb6bf476c [PAC] in ?? () from /usr/lib/apache2/modules/mod_mpm_prefork.so
#9  0x0000ffffb6bf4e6c [PAC] in ?? () from /usr/lib/apache2/modules/mod_mpm_prefork.so
#10 0x0000aaaaea0eb498 [PAC] in ap_run_mpm ()
#11 0x0000aaaaea0e20bc [PAC] in main ()~

流れの詳細は以下の通りです

  • #0 php_handler() PHP モジュールのリクエスト処理。今回のブレークポイント
  • #1 ap_run_handler() Apache のハンドラーフックを実行
  • #2 ap_invoke_handler() リクエストに対応するハンドラーを呼び出す
  • #3 ap_process_async_request() Apache のリクエスト処理本体
  • #4 ap_process_request() HTTP リクエスト処理の入口の一つ
  • #5 ?? シンボル名を GDB が特定できていない
  • #6 ap_run_process_connection() 接続処理のフックを実行
  • #7〜#9 mod_mpm_prefork.so 内の関数 prefork MPM による接続・子プロセスの処理
  • #10 ap_run_mpm() Apache の MPM 実行処理
  • #11 main() Apache のエントリーポイント

さらに関数が現在どの位置にいるか確認します
php_handler の関数の開始位置は 0xffffb5f004c4 であることがわかります
さらに $pc (プログラムカウンタ) を参照します
すると 0xffffb5f004c8 を指しており先程の 0xffffb5f004c4 から4バイト進んでいます
これは adrp (ARM64) の1命令が通常4バイトなので関数の先頭にある1命令分を進んだ位置であることを表しています

(gdb) info address php_handler
Symbol "php_handler" is at 0xffffb5f004c4 in a file compiled without debugging.
(gdb) x/i $pc
=> 0xffffb5f004c8 <php_handler+4>:      adrp    x1, 0xffffb6ace000 <ini_entries+208>
(gdb) p/x $pc
$1 = 0xffffb5f004c8

関数内で使用されている変数を確認するには args を参照します
php_handler 内では変数は使われていませんでした

(gdb) info args
No symbol table info available.
(gdb) gdb locals
Undefined command: "gdb".  Try "help".
(gdb) info locals
No symbol table info available.
(gdb) info frame
Stack level 0, frame at 0xffffca360170:
 pc = 0xffffb5f004c8 in php_handler; saved pc = 0xaaaaea10d474
 called by frame at 0xffffca3601a0
 Arglist at 0xffffca360150, args: 
 Locals at 0xffffca360150, Previous frame's sp is 0xffffca360170
 Saved registers:
  x29 at 0xffffca360150, x30 at 0xffffca360158

終了する場合は quit です

その他

gdb には他にもたくさんのコマンドがあります

  • info proc exe
  • info sharedlibrary

最後に

AI 先生に教えてもらえば覚える必要はないですが理解するとなるとやはり自分の手で実行したほうが良いと実感します

2026年10月27日火曜日

M2 pro mac mini + ollama + strix メモ

M2 pro mac mini + ollama + strix メモ

概要

結論としてはまともに動きません
公式にもありますがやはり 70b レベルのモデルが必要です

Compatibility Note: Strix relies on advanced agentic capabilities (tool use, multi-step planning, self-correction). Most local models, especially those under 70B parameters, struggle with these complex tasks.
For critical assessments, we strongly recommend using state-of-the-art cloud models like Claude 4.5 Sonnet or GPT-5. Use local models only when privacy is the absolute priority.

自分で検証した結果を記載します
どのモデルもコンテキストサイズは8192でnum_predictは-1に設定しています

環境

  • macOS 26.6.2
  • ollama 0.40.8

qwen3-vl:8b

time=2026-10-26T16:17:55.276+09:00 level=WARN source=qwen3vl.go:97 msg="qwen tool call parsing failed" error="invalid character 'X' looking for beginning of value"

でエラー

qwen3.5:9b-mlx

panic: mlx: [METAL] Command buffer execution failed: Insufficient Memory (00000008:kIOGPUCommandBufferCallbackErrorOutOfMemory). at mlx/c/transforms.cpp:73

でエラー

qwen3.5:4b-mlx

[GIN] 2026/10/26 - 18:44:01 | 500 |          5m0s |   192.168.1.100 | POST     "/api/chat"

でエラー

最後に

もう少し頑張りたい気もしますが厳しい状況です
最後の 500 エラーは推論時間が長過ぎるエラーなので何かしらのパラメータで調整できないか調査しています

2026年10月26日月曜日

strix + local ollama + qwen3-vl:8b

strix + local ollama + qwen3-vl:8b

概要

とりあえず動くけどマシンスペックかなりいります

環境

  • ollama 0.40.6
  • strix 1.7.0
  • Ubuntu 24.04

pull

  • ollama pull qwen3-vl:8b

ollama のコンテキストサイズは 65536 です

実行

  • export STRIX_LLM="ollama/qwen3-vl:8b"
  • export LLM_API_BASE="http://localhost:11434"
  • strix --target .

使い方メモ

  • Root エージェントがまず立ち上がりプロジェクトやサイトのチェックをします
    • 基本は docker コンテナからチェックするのでコンテナからアクセスできるようにしましょう
    • たとえばソースコードチェックであればソースコードをコンテナにマウントしてあげる必要があります
    • localhost であれば host.docker.internal でアクセスするので host.docker.internal でアクセスされても動作するようにアプリを修正しましょう
  • 実際に攻撃や調査を行うのは子エージェントです
    • 各種攻撃ごとに Root エージェントが子エージェントを立ち上げる
    • 子エージェントの終了すると Root エージェントがその結果をまとめて報告してくれる
    • 攻撃が終了して別の種類の攻撃をしたい場合は Root エージェントに命令しないとダメ
    • 子エージェントはその攻撃専門エージェントなので別の攻撃をしたい場合は別の子エージェントを起動する必要がある
  • 対話的に進めるのが基本
    • Root エージェントも子エージェントもテスト中に普通に何回もユーザに質問を投げかけてきます
    • 「次はどんなテストをしますか」「API のルーティングを教えてください」「認証エラーになるので情報をください」など
    • 当初は全自動で自律的にどんどんテストしてくれると思ったがそんなことはなく結構しっかり会話して命令を与えてあげないとちゃんとテストしてくれない
    • 例えば子エージェントが SQL インジェクションのテストをしている場合には「どのパラメータに対して攻撃しますか」「どの API に対して攻撃しますか」など聞いてきます
    • 子エージェント側が会話を待っていると Root エージェント側もずっと待ち状態になるので子エージェントにしっかり命令してあげる必要がある
    • 結構頻繁に聞いてくるので注意して子エージェントを監視しないとテストが止まっている
  • ソースコードや OpenAPI のリファレンスなど与えたほうがいい
    • –target でホストを指定している場合はある程度予測して調査してくれるがそれだと4xx系のエラーばかりですぐにあきらめてしまう
    • エンドポイント+ソースコードやリファレンスも渡すと自動でソースコードを読み込んで攻撃対象を洗い出してくれる
    • 更にコードから脆弱性のある部分を先に洗い出しその後攻撃もしてくれるので攻撃前に事前に重点的に攻撃してくれる部分がわかる
    • ただその場合はしっかりコンテナからコードやリファレンスが参照できるようにすること
  • トークンの消費はそこまで多くはない
    • 多くはない印象だがループ処理に入りそこでエラーが発生し再度挑戦みたいな感じで無限ループに入ると大変なことになる
    • 命令次第ではあるが基本は単発単発でリクエストするのでアプリの負荷が急に上がったりもしない
  • 日本語にも対応している
docker exec -it affectionate_dewdney /bin/bash

docker exec affectionate_dewdney mkdir -p /workspace/project
docker cp \
  /home/devops/path/to/project/. \
  affectionate_dewdney:/workspace/project

最後に

一応これで動きます
8b レベルだとそこまで精度が出ないのでスペックに余裕がある場合はもっとパラメータの多いモデルを使いましょう
strix 的にはローカル LLM では qwen がオススメのようです

参考サイト

2026年10月25日日曜日

ollama で num_predict を設定する方法

ollama で num_predict を設定する方法

概要

num_predict を設定しないと出力が途中で途切れてしまうので設定しましょう
おもに2つあります

環境

  • macOS 26.6.2
  • ollama 0.40.8

方法1: API をコールする

curl -s http://localhost:11434/api/generate \
  -H 'Content-Type: application/json' \
  -d "$(jq -n \
    --arg model 'gemma4' \
    --arg prompt 'このファイルの内容を要約してください' \
    --arg content "$(cat scripts/test.py)" \
    '{
      model: $model,
      prompt: ($prompt + "\n\n以下がファイルの内容です。\n\n" + $content),
      think: true,
      stream: false,
      options: {
        num_predict: -1
      }
    }')" \
  | jq -r '.response' > output.txt

方法2: カスタムモデルの作成

  • ollama run gemma4

インタラクティブモードに入る

  • /set parameter num_predict -1
  • /save my/gemma4

インタラクティブモードを抜けて保存したモデル名で実行する

  • ollama run my/gemma4

方法2 は Modelfile を使っても OK です

最後に

コンテキストサイズは環境変数で設定可能ですが出力サイズは環境変数で設定できないので注意です

2026年10月24日土曜日

Mac 上の ollama でコンテキストサイズを変更する方法

Mac 上の ollama でコンテキストサイズを変更する方法

概要

.env を変更しましょう
前回も紹介していますが方法が変わっていました

環境

  • macOS 26.6.2
  • ollama 0.40.5

env ファイル作成

OLLAMA_CONTEXT_LENGTH を追加します

  • mkdir -p ~/.homebrew/services
  • vim ~/.homebrew/services/ollama.env
OLLAMA_CONTEXT_LENGTH=10240

再起動

  • brew services restart ollama

これで ~/Library/LaunchAgents/sh.brew.ollama.plist が動的に生成されます

動作確認

適当に ollama run で起動し何か話かけて ollama ps で Context Size を確認しましょう

最後に

コンテキストサイズを大きくしたほうがエージェントが柔軟に動けます
ただしメモリが必要になります

2026年10月23日金曜日

Codex CLI を ssh したサーバ上の tmux 上で実行している場合に会話の履歴を過去にたどる方法

Codex CLI を ssh したサーバ上の tmux 上で実行している場合に会話の履歴を過去にたどる方法

概要

esc キーで Browsing transcript になるのであとは上下キーでレスポンスの履歴を確認できます

環境

  • Ubuntu 24.04
  • codex cli 0.163.0

最後に

tmux 上でコピーモードしても codex cli を実行する以前のシェルの履歴しか辿れないのでちゃんと codex cli の機能を使いましょう

2026年10月22日木曜日

Codex CLI + ollama + gemma4 設定メモ

Codex CLI + ollama + gemma4 設定メモ

概要

大事なのはコンテキストでした

環境

  • Ubuntu 24.04
  • 8vCPU 32GBメモリ
  • gemma4:26b

ollama インストール

  • curl -fsSL https://ollama.com/install.sh | sh

codex インストール

  • curl -fsSL https://chatgpt.com/codex/install.sh | sh

モデルダウンロード

  • ollama pull gemma4:26b

ollama 設定

  • sudo systemctl edit ollama.service
### Editing /etc/systemd/system/ollama.service.d/override.conf
### Anything between here and the comment below will become the contents of the drop-in file

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=66536"


### Edits below this comment will be discarded


### /etc/systemd/system/ollama.service
# [Unit]
# Description=Ollama Service
# After=network-online.target
#
# [Service]
# ExecStart=/usr/local/bin/ollama serve
# User=ollama
# Group=ollama
# Restart=always
# RestartSec=3
# Environment="PATH="
#
# [Install]
# WantedBy=default.target
  • sudo systemctl daemon-reload
  • sudo systemctl restart ollama

サンドボックス設定

codex 起動

  • ollama launch codex

で gemma4:26b を選択

動作確認

あとは命令するだけです
コンテキストを長くしないと codex cli が命令を実行してくれません

最後に

メモリが十分にないとコンテキストを64kにできないのでメモリを潤沢にしましょう