Orz日記 by Akio Morita

_ [FreeBSD]openoffice.orgがコンパイルできない件

原因判明

openoffice.orgには icu 3.6のソースが組み込まれており 自前でコンパイルして使っているのだが、portsが configure時にCPPFLAGSに渡している -I/usr/local/includeが自前のヘッダーへの パスよりも先に使われているために、 コンパイル時に ports/devel/icuでインストールされている icu 3.8.1のヘッダーが使用され icu 3.6のライブラリーとの リンクに失敗していました。

本来は、Makefile側を修正して-I/usr/local/includeの 優先順位を下げるべき所だが、面倒なので/usr/local/include/layoutと /usr/local/include/unicodeを一時的に名前を変えてごまかすことに

_ [Fortran]同一ファイルに対するOPEN文の挙動

同一の character device (/dev/null)を開くテスト

     character(len=32) :: fn

     fn='/dev/null'

     write(*,*)'Open10'
     open(10,file=fn,status='UNKNOWN')

     write(*,*)'Open11'
     open(11,file=fn,status='UNKNOWN')

     write(*,*)'Open12'
     open(12,file=fn,status='UNKNOWN')

     end

同一のregular file(/tmp/fortran.txt)を開くテスト

     character(len=32) :: fn

     fn='/tmp/fortran.txt'

     write(*,*)'Open10'
     open(10,file=fn,status='UNKNOWN')

     write(*,*)'Open11'
     open(11,file=fn,status='UNKNOWN')

     write(*,*)'Open12'
     open(12,file=fn,status='UNKNOWN')

     read(12,'(a)')fn
     write(*,*)fn

     read(11,'(a)')fn
     write(*,*)fn

     end

挙動のまとめ

• gfortran 4.2/4.3と Interl Fortran 7.1は、同一ファイルの同時OPEN禁止
  • libgfortranを読む限り、既にOPEN済みのファイルとパス名とi-node番号が共に一致する場合は、OPENを拒否する
    • 同一パス名での i-node番号が異なる場合は問題ない(古いファイルが一度 unlinkされている場合など)
    • hard linkか VFS経由で同じファイルへ異なるパスでアクセスする場合も検査をすり抜ける
• g77と Intel Fortran 8.1は、OPEN時に検査を行っていないと思われる
• g95は、同一ファイルの同時OPENは原則禁止、device specialに関しては規則を緩めている
  • g95の libf95(io/unit.c, unix/unix_io.c)によれば、terminal device(character device)に対しての多重OPENを認めている

調査の範囲では、dup2(2)で上書きするための Logical Unit Numberを 確保するのに/dev/nullを多重OPENするという戦略は移植性が無い。

Intel Fortran 7.1から 8.1への挙動の変化が謎ではあるものの、 g77とことなり Fortran95規格ベースで実装されている gfortran/g95の挙動を 見る限り「同一ファイルへの多重OPENは禁止」は Fortran仕様的に何らかの根拠があると思われる。

_ [Fortran]SCRATCHなOPEN文の挙動

テストコード

     integer :: i

     write(*,*)'Open10'
     open(10,status='SCRATCH')

     write(*,*)'Open11'
     open(11,status='SCRATCH')

     write(*,*)'Open12'
     open(12,status='SCRATCH')

     do i=1,1000
        write(11,*)'New'
     enddo

     do i=1,10000000
        write(10,*)'Test'
     enddo

     end

挙動のまとめ

• 一部の実装は、open(2)後にSCRATCHファイルをunlink(2)しない
• SIGINT等で実行中断時に、SCRATCHファイルが残留する実装が存在する
  • シグナルハンドラが上書きされてる場合の動作が、不定(signal ->execve(2)な場合とか...)

調査の範囲では、dup2(2)で上書きするための Logical Unit Numberを 確保するのにSCRATCHファイルをOPENするという戦略では、 プロセス中断時に一時ファイルが残留する可能性がある。

つまり、一時ファイルがファイルシステムに残留する可能性や 多重OPEN禁止の実装まで考慮すると... OPEN文にmkstemp(3)とunlink(2)を組み合わせて 自前で実装するしか一般解が無いと言うことに...

_ [Fortran]OPEN文での/dev/nullの扱い

どうやら、gfortranに関しては/dev/null(正確にはisatty(3)が真となるもの stat(2)の結果、!S_ISREG()が真となるもの[訂正2008/03/18]) に対しては、unbufferedspecial_file[訂正2008/03/18]な 取扱いになり、regular fileと異なる振る舞いをする。

従って、dup2(2)で上書きするための Logic Unit Numberを 確保するのに/dev/nullを OPENする代わりに regular fileを OPENすると挙動が違うことに...

このために、mkstemp(3)とunlink(2)を組み合わせたitopenbuf_の 再実装はうまく動きませんでした。

パス名を新たに生成可能かつ、 isatty(3)が真になる!S_ISREG()が真になる[訂正2008/03/18]というと 使えそうなのは名前付きパイプかな？

とすると、mkdtemp(3) + mkfifo(2) + unlink(2) + rmdir(2)か...

_ [SAD][Fortran]itopenbuf_, itfopen*_の新実装

これまでの分析に基づいて、多重OPENの禁止処理にかからずに dup2(2)での上書き用の Logical Unit Numberを確保するコードを 実際に実装してみる。

有効にするには、sad.confへ以下を追加すること

USE_NEW_FORTRAN_OPEN_SIM=YES

動作は、/tmpに openbuf.で始まる 0700な一時 directoryを作って(mkdtemp(2))、 その中に名前付きパイプfifoを作成し(mkfifo(2))、 OPEN文で開いた後、 unlink(2)と rmdir(2)で後始末する。 一時ファイルの race conditionに対する安全性は、 mkdtemp(2)が予測不能な名前で ownerしかアクセスできない directoryを作ることに依存しています。

itfopenread_G77.fで実装されているOPEN文での DISP修飾のエミュレーションも unlink(2)で再実装する。 system経由の実装だと、/bin/shと/bin/rmを実行するために fork(2)とexecve(2)が2回づつ呼び出されるという パフォーマンス面での不利もあるが、 /bin/shを通過するためにシェルが解釈するメタ文字を含む パス名を正しく扱えない問題がありました。 (好き好んで、そんな変態的なパス名を一時ファイルに 使う上位層はいないはずですが...)

_ [LHC]β解析ツールが動かないという話

で呼ばれて、その場で調査してみる...

なんか、Union[]がエラー吐いてる...というか、その前の時点で データが入っていないのはおかしい....

あれ、なんかコードが違うような...って、これ古いコードじゃん Orz

まあ、エラーチャックに若干抜けがあったのも事実なのだが、 古いコードで新機能を呼び出せば動かないのは当たり前