スキップしてメイン コンテンツに移動

0xF 0xB 0x31 0xFF

app-admin/eselect-1.3.5 問題の続き。

一応復習しておこう。 PORTAGE_ELOG_COMMAND で呼び出された gentwoo が eselect を呼び出したところで死ぬ。 環境変数を gentwoo に引き渡しておけば死なない。

Gentoo Bugs #475284 に報告してみて得た情報なども加味しながらもう少し情報を補足しよう。 環境変数が空っぽだと死ぬので env -i /path/to/eselect とすればいつでも再現できる、と主張したのだが、 これで現象が再現できるのは(少なくとも今のところは)私の Gentoo Prefix on OS X でだけである。 そもそも、eselect は bash スクリプトで、死んでいるのは具体的にどこなのか、と聞かれて core を吐かせることにする。 ulimit -c unlimited としておく(と core ファイルは /cores に core.PID という名前で残される)。

死んでいるのは bash の中だ。

bash 自体が死ぬような現象には遭遇した経験が無かったので、どうにもデバッグの糸口が摑めなかった。 とりあえず eselect の中に echo コマンドをいくつか挟んでみた。 どうも死ぬ場所は一定していないらしい(埋め込んだ echo が実行される前に死んだり、実行してから死んだりまちまち)。 とすると、むしろメモリーのゴミを踏んでしまっているか?

メモリーエラーには valgrind。 ここでも環境変数を渡さないように env -i /path/to/valgrind /path/to/bash /path/to/eselect。 すると次のような出力を得る 

vex x86->IR: unhandled instruction bytes: 0xF 0xB 0x31 0xFF
==64989== valgrind: Unrecognised instruction at address 0x2a5ce9.
==64989==    at 0x2A5CE9: _dispatch_mgr_invoke (in /usr/lib/libSystem.B.dylib)
==64989==    by 0x2A4F58: _dispatch_queue_invoke (in /usr/lib/libSystem.B.dylib)
==64989==    by 0x2A4CFD: _dispatch_worker_thread2 (in /usr/lib/libSystem.B.dylib)
==64989==    by 0x2A4780: _pthread_wqthread (in /usr/lib/libSystem.B.dylib)
==64989==    by 0x2A45C5: start_wqthread (in /usr/lib/libSystem.B.dylib)
==64989== Your program just tried to execute an instruction that Valgrind
==64989== did not recognise.  There are two possible reasons for this.
==64989== 1. Your program has a bug and erroneously jumped to a non-code
==64989==    location.  If you are running Memcheck and you just saw a
==64989==    warning about a bad jump, it's probably your program's fault.
==64989== 2. The instruction is legitimate but Valgrind doesn't handle it,
==64989==    i.e. it's Valgrind's fault.  If you think this is the case or
==64989==    you are not sure, please let us know and we'll try to fix it.
==64989== Either way, Valgrind will now raise a SIGILL signal which will
==64989== probably kill your program.
==64989==
==64989== Process terminating with default action of signal 4 (SIGILL)
==64989==  Illegal opcode at address 0x2A5CE9
==64989==    at 0x2A5CE9: _dispatch_mgr_invoke (in /usr/lib/libSystem.B.dylib)
==64989==    by 0x2A4F58: _dispatch_queue_invoke (in /usr/lib/libSystem.B.dylib)
==64989==    by 0x2A4CFD: _dispatch_worker_thread2 (in /usr/lib/libSystem.B.dylib)
==64989==    by 0x2A4780: _pthread_wqthread (in /usr/lib/libSystem.B.dylib)
==64989==    by 0x2A45C5: start_wqthread (in /usr/lib/libSystem.B.dylib)
==64989==

何度か実行してみたが、毎回同じ結果のようだ。 0xF 0xB 0x31 0xFF って何? しかも libSystem.B.dylib (OS X おける libc みたいなもの)の中って。

今回は何も解決しない。

ラベル:

このブログの人気の投稿

「函数」音訳説について探してみる

Twitter に書こうかと思ったが、ちょっと長くなるのでこっちに書くことにする。 「函数」が音訳というデマと、本当の語源 というブログ記事について ツイートされてるの を見た。 詳しい内容はリンクを辿って読んでみて欲しい。 その記事中の「函数」音訳説という部分で、引用されているものが意外と新しい1980年代以降のものなので、さすがにもっと古いだろう、と探してみた。 1. 武部良明「漢字の用法」(1976) このほか武部良明『漢字の用法』（角川書店1976）にも同様の記述があるという（未確認）。 とあって、たまたま同書(三版)を持っているので調べてみた。 「関数」ではなく「関・函」の項にあった。 「函」は「いれる」意味。 したがって、「函数」という漢字の組み合わせからは、「対応して定まる数」という意味は出てこない。 「函数」については function という原語の音 fun を、「函」の音カン（現代中国語 han）で写したものとされている。 これに対し現代表記の「関数」は、全体の意味を「かかりあう数」と考え、「函」の部分を、同音で「かかりあう」意味の「関」に書き換えたものである。 2. 遠山啓「関数を考える」(1972) 近所の図書館で見つけた。 会話体の文章の中で、先生役が言っている。 はっきりはわからないが, 中国語の発音では function と似ていて, しかも意味も近いらしいのだ. 3. 遠山啓「数学は変貌する」(1971) 2012年にちくま学芸文庫から出た「現代数学入門」所収。 「関数を考える」が中学生ぐらいを対象にしたシリーズの一冊なので、そこでいきなり初披露ということは無いだろうと見当をつけて遡って探した。 機能とは簡単にいうと働きです。 ライプニッツが初めてファンクションという言葉を使った. ライプニッツはドイツ人ですが, ドイツ語は当時はいなかの言葉みたいで, フランスが文化の中心であったから, フランス語で書いてありますので, フォンクション (fonction) です. もとは日本では「函数」, あとになって「関数」と改めたのです. なぜこんな函の数という妙な言葉を使ったか, これは中国からきた字です. 中国人は各国語を音まで似せて訳すことがうまい. フォンクションは中国語で函数を中国読みしますと非常に似ているのだそ...
Read more »

2025年の読書

読書メーターの記録 によるとマンガも入れて101冊。 久しぶりに年100冊に乗った。 前年からの勢いのままに菌類関係の本をいくつか読んだが深澤遊の「キノコとカビの生態学」「枯木ワンダーランド」は面白かった。 後半はファーブル昆虫記を読破した。岩波文庫の古い訳で読んだのが良かったのか良くなかったのか。 数学関係は、前半表現論の本を読んで表現とは加群のことであるという言葉で何だかすっきりした。 年の終わり近くはラングランズ予想というか楕円曲線と保型形式とガロワ表現とみたいな内容の本をいくつか。「ラングランズ予想」というそのものズバリなタイトルの本も出たのでその内読みたい。 マンガは、「ヴィンランド・サガ」も「アルテ」も「推しが武道館に行ってくれたら死ぬ」も完結して、読み続けるタイトルが少なくなってきた。
Read more »

Schur Number

Youtube の Numberphile チャンネルで最近出た Schur Number の動画を見た、 そこでのシューア数の定義は OEIS の "version 1" の方 Smallest number such that for any n-coloring of the integers 1, ..., a(n) no color is sum-free, that is, some color contains a triple x + y = z. だったが、 "version 2" の Largest number such that there is an n-coloring of the integers 1, ..., a(n) such that each color is sum-free, that is, no color contains a triple x + y = z. の方が解り易いからこちらで話を進める。version 2 の方が 1 小さい値になるというだけの違いがある。 動画の内容は \(a(n) = 160\) になる証明が2ペタバイトのデータ量で凄い、みたいなこと。 結局、全ての n-coloring を確認するしかないとか何とか。 ここではそういう難しい部分の話はせずに、1, 4, 13, 44, 160 という増え方が大体 3 倍を超えるぐらいというのを納得する議論をしてみたい。 よりはっきり言うと、1, 4, 13 と増える \(a_{n+1} = 3a_n + 1\) という数列が下限になることを示す。 一つ注意を述べると、n-coloring を考えるというより \(\{1,\ldots,k\}\) の和抜き（sum-free）集合による被覆を考えれば良い。被覆ができれば彩色を作れる（自由度を失うだけ）ので。 そういうわけで \(\{1\}\) の被覆を考え始めるわけだが、そちらも \(\{1\}\) で良い。 次に \(\{1, 2\}\) の被覆を考えるが \(1+1=2\) なので \(\{1,2\}\) は和抜きではない。よって \(\{1, 2\}\) の和抜き集合による被覆は \(...
Read more »