とある .NET アプリが Mono ではクラッシュしてしまうのでいろいろ調べてみる。その .NET アプリはソースがないので、そのアプリ自体のバグのせいでクラッシュしているとしても、Mono 側に手を入れてインチキすることにした。
まずウィンドウ自体が開かずにクラッシュ。
Unhandled Exception: System.Exception: Value '-91' must be greater than or equal to 0. in <0x000a0> System.Windows.Forms.ScrollBar:set_LargeChange (Int32 value)
とりあえず mono-1.1.13.1/mcs/class/Managed.Windows.Forms/System.Windows.Forms/ScrollBar.cs の LargeChange で、value が 0 未満なら例外を投げるのではなく value を既定値の 10 にセットすることにした(.NET Framework クラス ライブラリ ScrollBar.LargeChange プロパティ)。これを潰してもまだウィンドウ自体が開かずにクラッシュ。
Unhandled Exception: System.Exception: Value '-9' must be greater than or equal to 0. in <0x0009e> System.Windows.Forms.ScrollBar:set_SmallChange (Int32 value)
同様に value に既定値の 1 をセット(.NET Framework クラス ライブラリ ScrollBar.SmallChange プロパティ)。
ひとまずウィンドウは開くようになったけど、今度はファイルダイアログを開こうとするとクラッシュ。
Unhandled Exception: System.ArgumentNullException: Argument cannot be null. Parameter name: path in <0x0006b> System.IO.FileSystemInfo:CheckPath (System.String path) in <0x00025> System.IO.DirectoryInfo:.ctor (System.String path) in (wrapper remoting-invoke-with-check) System.IO.DirectoryInfo:.ctor (string) in <0x00035> System.Windows.Forms.DirComboBox:CheckChildOf () in <0x001ae> System.Windows.Forms.DirComboBox:CreateComboList () in <0x00020> System.Windows.Forms.DirComboBox:set_CurrentPath (System.String value) in (wrapper remoting-invoke-with-check) System.Windows.Forms.DirComboBox:set_CurrentPath (string) in <0x0002e> System.Windows.Forms.FileDialog+FileDialogPanel:ChangeDirectory (System.Object sender, System.String path_or_special_case) in (wrapper remoting-invoke-with-check) FileDialogPanel:ChangeDirectory (object,string) in <0x00021> System.Windows.Forms.FileDialog:set_InitialDirectory (System.String value) in (wrapper remoting-invoke-with-check) System.Windows.Forms.FileDialog:set_InitialDirectory (string)
mono-1.1.13.1/mcs/class/Managed.Windows.Forms/System.Windows.Forms/FileDialog.cs の InitialDirectory で、value が null ならば value に "." (カレントディレクトリ) をセットするようにした。
ファイルダイアログは開けるようになったけど、開いた直後にクラッシュすることがある。ウィンドウにフォーカスを当てていると駄目なようだ。
Unhandled Exception: System.NullReferenceException: Object reference not set to an instance of an object in <0x00009> System.Windows.Forms.Document+Marker:op_LessThan (Marker lhs, Marker rhs) in <0x001af> System.Windows.Forms.Document:SetSelectionToCaret (Boolean start) in <0x000a7> System.Windows.Forms.TextBoxBase:TextBoxBase_MouseUp (System.Object sender, System.Windows.Forms.MouseEventArgs e)
mono-1.1.13.1/mcs/class/Managed.Windows.Forms/System.Windows.Forms/TextBoxBase.cs の TextBoxBase_MouseUp から mono-1.1.13.1/mcs/class/Managed.Windows.Forms/System.Windows.Forms/TextControl.cs の SetSelectionToCaret は false つきで呼ばれている。selection_anchor.line が null ならば selection_anchor.line に caret.line をセットするようにした。
ファイルダイアログからファイルを保存しようとすると、ファイル名をつけられない。例えばファイルタイプ「.txt」の状態でファイル名に「hoge」または「hoge.txt」とつけて保存しようとしても、「.txt」というファイルに保存されてしまう。ファイル一覧から選んで上書きするには問題ないが、エントリに入力したファイル名は取得されていないようだ。なんかよくわからないので、保存する前に手動で touch してそれに上書きするようにした。
上記 workaround patch の vd_mono-1.1.13.1_dirty-workaround.patch を当てて作成。
×問題対策インチキパッチ vd_rxvt-unicode_latin1-supplement-partly_double-width_encoding-jp.patch を当てて作成。
作成。昨日の ja.po は間に合わなかったので、それだけ差し替えておいた。
UTF-8 な screen 上での w3m や mutt の表示がおかしかったので探してみると、screen のバグらしい情報＋パッチを発見。screen-4.0.2-patch-cjkwidth-cvs-2006052001 がそのまま当たったので試してみると、表示が改善された。
ということでこれも quilt を使って作成。
vim の文字コード認識は ずんWiki - vim: 文字コードの自動認識でやろうと思ったけど全然うまくいかなかった。いろいろ ~/.vimrc を変更していて原因を発見。vim で最終行に勝手に改行をつけないようにするための set binary がまずかったようだ。これを外したところ、見事に UTF-8 だろうと eucJP だろうと Shift-JIS だろうと問題なくなった。
なんか Mono 起動しないなーと思ってリモートで調べようとしたら VNC 内だと起動した。おや？と思ってよく見ると、
% mono XXXXXXXX.exe Could not get XIM
とか出てた。もしかしてと通常の X で
% XMODIFIERS='@im=none' mono XXXXXXXX.exe
とやってみるとすんなり起動した。
[Mono-dev] XIM and mono-winforms-2.0 のスレッドで言及されてることかな。修正は [Mono-patches] r111351 - branches/mono-2-0/mcs/class/Managed.Windows.Forms/System.Windows.Forms かと思ったけど、mono 2.0.1 にこのコードは入ってる。別の問題？
python-wxgtk2.6 2.6.3.2.2-4+b1 がインストールできない。
Setting up python-wxgtk2.6 (2.6.3.2.2-4+b1) ... file does not exist: /usr/lib/python2.6/dist-packages/wxversion.py pycentral: pycentral pkginstall: error byte-compiling files (260) pycentral pkginstall: error byte-compiling files (260) dpkg: error processing python-wxgtk2.6 (--configure): subprocess installed post-installation script returned error exit status 1 Errors were encountered while processing: python-wxgtk2.6
python-wxversion (wxwidgets2.8) 2.8.10.1-2 が python2.6 のファイルを持ってないせい？ ってもしかして python-wxgtk2.6 はもう古くて python-wxgtk2.8 のほう？ てことで python-wxgtk2.6 を消して python-wxgtk2.8 を代わりに入れてみたら、そちらは問題なくインストールできた。
とりあえず python-wxversion 2.8.10.1-2 の問題として #566960 に投げた。
DELAYED/2 NMU してたのが ACCEPT された。
#562834: 閉じ忘れなので閉じた。
#431806: もう直ってそうなので閉じた。
ptex-bin 3.1.11+0.04b-0.2: #529135 #641555 を取り込んで、さらに hurd-i386 での FTBFS (OPEN_MAX undeclared) を対処して DELAYED/5 NMU。
ptex-bin の FTBFS が解決したので次は canna が hurd-i386 でビルドできるか確認。ところが無理だった。
root@debian:~/canna/canna-3.7p3/dic/ideo/grammar# ../../../cmd/crxdic/crxdic -g -s -o fuzokugo.cbd -D cnj.bits -n fuzokugo fuzokugo.swd crxdic: cannot open grammar file cnj.bits. root@debian:~/canna/canna-3.7p3/dic/ideo/grammar#
生成された辞書とかのファイルが壊れてるのかと思ったけど md5sum は amd64 で作ったのと変わらず。となると、どこかで処理がおかしくなってる可能性が高い。けど追い掛けられないのでお手上げ。
Debian GNU/Hurd - Debian Wiki や GNU Hurd/ hurd/ running/ qemu にて、pre-installed QEMU image を使う方法が紹介されているのでそれを使う。
しかし、I/O パフォーマンスがめちゃめちゃ悪い。aptitude update とか aptitude build-dep ptex-bin やら aptitude build-dep canna やら aptitude build-dep uim すると数時間単位で時間がかかる。一方、debuild でパッケージを作るのは比較的早くに終わるんだけど、準備に時間がかかって仕方がなくて、待ってる間にモチベーションがかなり削がれる。
#758710 に patch がきてた。arm64 は release architecure になったから(Release Team Sprint Results)、修正したら unblock の対象になるのかな？
| 前 | 1970年 1月 |
次 | ||||
| 日 | 月 | 火 | 水 | 木 | 金 | 土 |
| 1 | 2 | 3 | ||||
| 4 | 5 | 6 | 7 | 8 | 9 | 10 |
| 11 | 12 | 13 | 14 | 15 | 16 | 17 |
| 18 | 19 | 20 | 21 | 22 | 23 | 24 |
| 25 | 26 | 27 | 28 | 29 | 30 | 31 |
[amd64 | audacious | comp | debian | gkrelluim | kip | misc | movie | research | rime | unicon | vdr | work | えふえふ]
書いてる人: dai
パッチ等(無保証)