トップページ⇒unix
983コメント245KB

FreeBSDを語れ Part38

■ このスレッドは過去ログ倉庫に格納されています
0001名無しさん＠お腹いっぱい。2014/07/14(月) 05:03:19.63
さぁ語れ

The FreeBSD Project
http://www.freebsd.org/ja/

前スレ
FreeBSDを語れ Part37
http://peace.2ch.net/test/read.cgi/unix/1390323139/

関連スレ
初心者もOK! FreeBSD質問スレッド その118
http://peace.2ch.net/test/read.cgi/unix/1397057895/
0127名無しさん＠お腹いっぱい。2014/07/31(木) 19:52:42.01
>>126
それはFreeBSDも同じ。問題はパイプの read() だろ。
0128名無しさん＠お腹いっぱい。2014/07/31(木) 20:09:51.92
最近のLinuxのパイプサイズは 256kB
ちょっと前が 64kB
もっと前が 4kB
0129名無しさん＠お腹いっぱい。2014/07/31(木) 20:16:46.90
>>104
生のktrace.outが欲しいわ。
タイムスタンプとかスレッドIDとか入ってるやつ。
でないと、CALLとRETの対応がつかなくて困る。
0130名無しさん＠お腹いっぱい。2014/07/31(木) 20:25:53.08
システムコールの特性を知る pipe(2)編
http://www.atmarkit.co.jp/ait/articles/1209/07/news125.html

> 例えばFreeBSD 10-CURRENTでは、パイプで使われるページ可能な
> カーネルメモリを使ったパイプのバッファサイズは、4KBから64KB
> の間で可変になっている。

> write(2)でどれだけ一気に書きこんでも、read(2)で読み込まれる
> サイズの上限が64KBに制限されている
0131名無しさん＠お腹いっぱい。2014/07/31(木) 22:11:49.30
いずれにしたってシステムコールの復帰値のチェックくらいしろやってことだろうな。
LibreOfficeですらこんな糞コーディングしちゃってることのがショックだ。
0132名無しさん＠お腹いっぱい。2014/07/31(木) 22:12:41.66
ことのが→ことが
0133名無しさん＠お腹いっぱい。2014/07/31(木) 22:33:18.30
ところで、フリーズする環境って、32bit？64bit？
0134名無しさん＠お腹いっぱい。2014/07/31(木) 22:47:06.92
>>113
ttp://docs.libreoffice.org/filter/html/ieps_8cxx_source.html#l00285
これか。
306行目でパイプ閉じてるから、向こうも書けなくなって落ちるのを期待してるのかもしれん。
落ちてくれない相手だと終了待ちで止まることになるかもしれんが……この可能性は低い、かな。
で、これだと書き込み中に相手プログラムがパイプに応答返してきた場合は、
受け取りしないからパイプバッファが足りなくなってエラーまたはデッドロックだな。

osl_writeFileとかのパイプバッファ溢れの挙動がよく分からんけど、
この周辺にprintfデバッグ仕込んで走らせれば何が起きてるかは分かるね。
あとosl_writeFileのソースが見つからないけど、この中で分割書き込みしてあるかどうかかな…

>>125
write単発4KBで止まってるならその周辺って事で戻ってねぇと思うけど

>>131
OOoからの派生だが、OOoのコード(安定性含む)って評判良かったか？
マシなコードにするって目標が合っても、それが追いつくかどうかは別の話だと思う。
0135名無しさん＠お腹いっぱい。2014/07/31(木) 23:31:24.37
>>134
>write単発4KBで止まってるならその周辺って事で戻ってねぇと思うけど
すまんが何言いたいのかわからん
01361042014/08/01(金) 00:18:08.90
>>129
遅くなりました。ktrace.out アップロードしました。
新しく取り直したものです。3MB あります。

http://fast-uploader.com/file/6962374997550/
01371042014/08/01(金) 00:28:41.66
>>133
私が確認したのは amd64 だけです。
前スレに同じ様にフリーズする人が何人かいたのですが、どちらか聞き損ねました。

フリーズを起こすのは簡単です。
10R か 9.3R に LibreOffice 4.2.5-2 を入れて、
4KB を越える EPS ファイルを impress で挿入するだけです。
ダイヤログで「開く」を押した瞬間にフリーズします。
preview が on になっていると、選択しただけでフリーズします。
01381042014/08/01(金) 00:36:27.07
>>124
常用している PC には 9.1R + LO 3.5.6.2 を残してあります。
9.3R や 10.0R を入れて試しているのは予備機の１つです。
LO4 が安心して使えないのは同意です。
でも、9.3R にも 10R にも LO4 しかないのです。
01391042014/08/01(金) 00:38:50.22
>>118
まだ何もやってませんでした。

>>117
これからやってみます。
0140名無しさん＠お腹いっぱい。2014/08/01(金) 05:52:13.29
>>134
今どきcommit前にレビューのないプロジェクトって……
0141名無しさん＠お腹いっぱい。2014/08/01(金) 06:27:09.35
パイプサイズ増やしとけばとりあえず問題回避できるだろ
0142名無しさん＠お腹いっぱい。2014/08/01(金) 10:53:05.62
>>141
それで256Kになったんですね
わかります。w
01431042014/08/01(金) 11:42:06.13
うわー。そうか、 linux ではバグがないんじゃなくて、バグが現れなかっただけなのか。
私がもう少し大きな EPS でテストして貰ってたら、同じ様にフリーズしてたのか。。。
win でどうか、大きな EPS を作って試して見ます。
0144名無しさん＠お腹いっぱい。2014/08/01(金) 11:48:24.21
>>136
とりあえず現時点まとめ。

1120 100087 soffice.bin 1406819284.268085 CALL write(0x31,0x815414000,0x4797)
1120 100281 soffice.bin 1406819292.199891 PSIG SIGTERM caught handler=0x80083
0b90 mask=0x0 code=0x10001
1120 100087 soffice.bin 1406819292.200801 GIO fd 49 wrote 4096 bytes
1120 100087 soffice.bin 1406819292.200812 RET write 18327/0x4797

という流れなんで、スレッド10087がwrite()を呼んだあと、
SIGTERMが来るまでそれが終わっていないことがわかる。
SIGTERMで受け取り側が刺激されて完了するか死ぬことで、write()が完了している。
とりあえずwrite()を完了させるために、gsに細工してみてくれないか？

/usr/local/bin/gs は gsc へのリンクになっていると思うけど、
これを

#!/bin/sh
cat >/tmp/gs$$
gsc "$@" </tmp/gs$$
rm -f /tmp/gs$$

というシェルスクリプトに変更して試してみてくれ。
0145名無しさん＠お腹いっぱい。2014/08/01(金) 12:12:40.57
こういうのって、読み書き両側をノンブロッキングモードにして、
selectなりしながらread/writeするのがありがちなのかな。
スレッド作っちまえって話もあるか。
01461042014/08/01(金) 12:17:18.50
>>144
変えてみました。結果、フリーズなくなりました！
それどころか、正常に画像が表示されました。不思議です。

source を見ると、RenderAsBMPThroughGS() と RenderAsBMPThroughConvert()
のどちらかを実行するようになっているので、Convert の方が実行されたのでしょうか？
とにかく、大きな前進です。
0147名無しさん＠お腹いっぱい。2014/08/01(金) 12:21:45.14
でも、gsが、入力全部来る前に出力しはじめて、
gsからのバッファがあふれて入力を止めてしまうってことがあるだろうか。
内部でレンダリングが完了しないと、BMPの出力なんて始められないと思うんだけど。
まあでも、そういう可能性も考慮してLO作れって話ではある。
0148名無しさん＠お腹いっぱい。2014/08/01(金) 12:53:12.30
>>146
> source を見ると、RenderAsBMPThroughGS() と RenderAsBMPThroughConvert()
> のどちらかを実行するようになっているので、Convert の方が実行されたのでしょうか？

なんでそうなんだよ
01491042014/08/01(金) 12:59:01.24
>>148
間違えました。
gs -> 144 script -> gsc にしたので、ThroughGS() の方でした。
0150名無しさん＠お腹いっぱい。2014/08/01(金) 13:03:16.65
>>147
PostScriptインタプリタは普通に作れば、入力が全部来てから処理を始めるなんていう
間抜けな構成にはならない。
届いたところまで評価して出力する構成になるのが普通。
0151名無しさん＠お腹いっぱい。2014/08/01(金) 13:20:10.05
>>150
そうなの？
最後まで各ピクセル値が確定しないように思うんだけど。
最後の最後に、あ、この線も追加で引いてなんてコード書けるでしょ。
0152名無しさん＠お腹いっぱい。2014/08/01(金) 15:53:31.50
実はまだフリーズの再現できてないんだよね。
VirtualBoxに10.0入れてやってみたら、図が表示されないけど、フリーズしない。
9.2を9.3に上げてLOもGSも入れ直してみたら、フリーズしない。
どっちも64ビット。
0153名無しさん＠お腹いっぱい。2014/08/01(金) 15:55:52.00
>>144
ぐっじょぶ！

>>150
詰まったパイプが出力段か入力段が分からんとなんとも言えん気もするが…
処理は開始できるけど、出力の頭辺りが確定しないと出力を始められないよ。
>>151
PSだとshowpageとかでページ確定してしまえばそのページは出力できるけど、EPSではどうなるやら
0154名無しさん＠お腹いっぱい。2014/08/01(金) 16:39:30.46
俺の環境では、たとえば、こんな lotest.sh スクリプトを作って、

#!/bin/sh
(cat; echo done >&amp;2) | gs -q -dBATCH -dNOPAUSE -dPARANOIDSAFER -dEPSCrop -dTextAlphaBits=4 -dGraphicsAlphaBits=4 -r300x300 -sDEVICE=bmp256 -sOutputFile=- - | (sleep 10; cat)

./lotest.sh < sinxplot.eps > sinxplot.bmp

って実行したら、すぐに done って表示される。10秒待って BMP が生成される。
つまりパイプへの出力バッファが埋まったから入力が中断されてるってわけではない。

でも、もしかすると、フリーズする環境ではこれはどうなるんだろう。
>>104 試してみて。gs は>>144の修正する前の gsc へのリンクね。
0155名無しさん＠お腹いっぱい。2014/08/01(金) 16:40:39.41
ちなみに & は半角の ＆
0156名無しさん＠お腹いっぱい。2014/08/01(金) 16:41:49.20
あれ、&amp; は半角の ＆
0157名無しさん＠お腹いっぱい。2014/08/01(金) 16:46:18.21
ja-ibus-anthy-1.2.7_4がダウングレード扱いｗ
01581042014/08/01(金) 16:56:01.15
>>154
もとの gs に戻して、LO がフリーズする様に戻してから、やってみました。

./lotest.sh: 2: Syntax error: Bad fd number

と表示され、１０秒後に終わって、bmp 1.5MB ができました。
できた bmp を表示してみると、サイズが大きくなっている以外は正常でした。
0159名無しさん＠お腹いっぱい。2014/08/01(金) 16:57:46.14
>>158
>>156
01601042014/08/01(金) 16:58:45.27
ちなみに、私の所は 9.3R amd64 で gs は pkg で入った以下です。

ghostscript9-9.06_7
Name : ghostscript9
Version : 9.06_7
01611042014/08/01(金) 17:05:07.90
>>159
失礼しました。
半角& に変えてから実行すると、直ぐに done で 10秒後に bmp ができました。
0162名無しさん＠お腹いっぱい。2014/08/01(金) 18:05:13.38
再現しないってことはgsの動作モードが違うのか、
シェルを介する何処かでパイプの挙動が違うのかな。
catが組み込みで動いたりパイプに対する対処がされてたり…
0163名無しさん＠お腹いっぱい。2014/08/01(金) 19:17:20.64
あとできるのはgscをktrace下で呼び出すくらいか。

フリーズする環境とバグ探し能力の両方を持った人、協力よろ。
0164名無しさん＠お腹いっぱい。2014/08/01(金) 22:00:10.59
>>154
なるほど。
たしかにLOでepsを開くとそのオプションでgs(gsc)が呼び出されてるわけですね。
私のところはフリーズする環境ですが、シェルスクリプトとして起動すると性状にbmpが作成されて、LOからだとgscのプロセスが残ったままになります。
このgscをkillすると読み込んだepsがLOで表示されるんですよね。
01651042014/08/01(金) 23:14:28.26
>>164 さん、FreeBSD のバージョンや 32bit 64bit は何でしょうか？
どうも、フリーズする環境としない環境があるみたいなので。
01661042014/08/01(金) 23:27:22.78
関係あるか分かりませんが、使っている shell は tcsh です。
01671642014/08/02(土) 11:18:55.68
>>165さん、
私のところはamd64の10-stable p5です。
LibreOfficeは、この話が出てきてからcvsでとってきたportsで入れました。
プラットフォームはESXi 5.5です。
01681042014/08/02(土) 11:31:00.15
>>167
了解です。私の 9.3R amd64 pkg とは amd64 だけ共通ですね。
shell は何でしょうか？ 私は tcsh です。
0169名無しさん＠お腹いっぱい。2014/08/02(土) 11:34:26.73
すげえ、Linuxのpipeって、64kB超えても一気に read(2) できるわ。確認した。
01701642014/08/02(土) 11:37:41.82
>>168
ログインシェルはtcshにしています
0171名無しさん＠お腹いっぱい。2014/08/02(土) 12:03:15.56
職場の新しいプロジェクトでC#を使うことになったんだけど、
いざ FreeBSD の pkg を見てみると mono や monodevelop 等の環境が充実していることに驚いた。
0172名無しさん＠お腹いっぱい。2014/08/02(土) 16:23:26.66
BSD#プロジェクトってほとんど一人でやってるんだぜ・・・頭下がるわ
0173名無しさん＠お腹いっぱい。2014/08/02(土) 16:35:29.21
俺はいつもほとんど一人でしごいてるんだぜ・・・頭がハゲるわ
01741042014/08/02(土) 17:04:28.53
>>170
二人とも tcsh ですね... これが関係しているのですかね？
>>162 さんが shell に触れているので気になりました。
0175名無しさん＠お腹いっぱい。2014/08/02(土) 17:34:26.31
#!/bin/sh って書いたスクリプト実行させるのにログインシェルとか関係ないからｗ
0176名無しさん＠お腹いっぱい。2014/08/02(土) 18:10:26.08
>>128
へえ、最近はそんなにでかいんだ
01771622014/08/02(土) 18:20:02.16
シェルスクリプト介す場合はシェルを何にしてるかも影響しそうだけど、
シェルスクリプト介さずプロセス作った時のトラブルに影響するのかな？
>>175
#!/bin/shが実際どんなシェルにリンクしてるかは一応環境依存だけど、
そもそもエラー再現するときがgsc直で呼んでる時だからやっぱ関係ない系
0178名無しさん＠お腹いっぱい。2014/08/03(日) 09:01:53.51
ざっとソースを読んでみた感じでは、
sal/osl/unx/process.cxx
の中の
osl_executeProcess_WithRedirectedIO　の処理を修正すれば良いんでしょうかね。
ちょっと追っかけてみます。
0179名無しさん＠お腹いっぱい。2014/08/04(月) 02:46:56.10
>>178 お疲れさまです。

http://code.woboq.org/libreoffice/libreoffice/sal/osl/unx/process.cxx.html#461

最終的には osl_psz_executeProcess の中の osl_waitCondition とかに行くのですかね...
複雑過ぎです...
0180名無しさん＠お腹いっぱい。2014/08/04(月) 21:24:21.44
LOがらみ：
再現性について進展。
pstoeditがインストールされていると、
RenderAsEMF()が成功するのでRenderAsBMP()を呼ばず、フリーズしない。
pstoeditがインストールされていないと、フリーズする。
0181名無しさん＠お腹いっぱい。2014/08/05(火) 11:49:53.00
マスターのportがあって、そのスレーブのport個々でPORTREVISIONをバンプした後で
マスターのPORTVERSIONが上がったとき、そのバンプを元に戻すのは
やっぱ忘れやすいよなｗ
0182名無しさん＠お腹いっぱい。2014/08/05(火) 12:14:30.80
>>180
お疲れさまです。
なるほど。FreeBSDでもフリーズする人しない人が居る理由が判りました。
判ってよかったです。
0183名無しさん＠お腹いっぱい。2014/08/05(火) 16:36:43.00
>>180
RenderAsEMF も osl_executeProcess_WithRedirectedIO を使っているんですね。
このときは FreeBSD でも問題ないのは、gsc の問題を意味するのでしょうか？

>>164 にもあるようにフリーズ中は gsc が残っていて、これを kill するとフリーズは解けるのですが、
画像が正しく表示はされる事はないです。例えば、外枠だけ表示されて中が真っ黒となります。
gsc の処理が途中で止まっている様に見えます。
0184名無しさん＠お腹いっぱい。2014/08/05(火) 18:16:19.76
>>183
>このときは FreeBSD でも問題ないのは、gsc の問題を意味するのでしょうか？

いいえ。pstoeditの出力は標準出力ではなく指定したファイルに行うようになっているので該当しません。
どうせ読むならもっと正確にコードを読んで判断してください。
0185名無しさん＠お腹いっぱい。2014/08/05(火) 19:03:53.23
で、>>143はどうなった？
pstoedit入れずにLinuxで巨大EPSのテストもな。1MBはいるな。
01861432014/08/05(火) 19:50:25.25
>>184
分かりました。

>>185
linux は手元にないです。Window はテストしました。
440KB の EPS で正常に動作しました。
0187名無しさん＠お腹いっぱい。2014/08/05(火) 22:24:50.35
LibreOfficeのバグであることは明白なんだから、いいかげんバグ報告すりゃいいのに。
ここでやるのはもうだいぶスレ違い。
0188名無しさん＠お腹いっぱい。2014/08/05(火) 22:31:23.20
わかっている範囲FreeBSDでしか発生していないバグをそのまま報告しても「わからん」
言われて終わる可能性は高いからなあ。スレ違いとまでは言えないと思うが。

SolarisとかでLibreOffice動くんだろうか。わざわざ試す気にはなれないけど。
0189名無しさん＠お腹いっぱい。2014/08/06(水) 02:12:13.47
pkgngって欠陥品では・・・
0190名無しさん＠お腹いっぱい。2014/08/06(水) 05:59:35.22
>>188
ではFreeBSDのパイプの実装を直すべきって言うかね？
0191名無しさん＠お腹いっぱい。2014/08/06(水) 08:05:06.58
本当に実装がまずいならそうするべきだし、あるいはportsにFreeBSD専用のパッチを
入れるか。
どっちにしろ「FreeBSDの話題」だよね?
01921042014/08/06(水) 11:17:26.57
>>189
＞pkgngって欠陥品では・・・

pkgng はまぁ良いとしても、デフォルトで latest なのがマズイと思う。
latest はローリングリリースで数が減ったりするから、タイミングによって欲しいモノがない。
デフォルトはタグの付いたリポにしとくべきだ。
最低でも、そう変更する方法の説明があるべきだけど、それもない。
0193名無しさん＠お腹いっぱい。2014/08/06(水) 13:22:33.96
>>191
>本当に実装がまずいならそうするべきだし、あるいはportsにFreeBSD専用のパッチを
>入れるか。
ばーか。お前は今までの話を理解してないんだな。
0194名無しさん＠お腹いっぱい。2014/08/06(水) 13:31:10.23
>>191
もう一度問題の原因を読んで考えなおせ
0195名無しさん＠お腹いっぱい。2014/08/06(水) 14:58:18.55
なるほど。FreeBSDのパイプの実装がまずいわけですね。
01961912014/08/06(水) 15:45:43.49
>>193,>>194
すまない、確かに自分がわかっていなかったようだ。
「gsに対するパイプへのreadをちゃんとせずにwriteするからお互いにwriteしようと
してデッドロックする」ということであっているだろうか。

これに対する修正なら確かにFreeBSD固有ではないな。ツッコミ感謝。
0197名無しさん＠お腹いっぱい。2014/08/06(水) 15:50:41.55
read/writeのデッドロックじゃなくて、
パイプからの1回のreadで全サイズ読めないとエラー扱いにしてしまうソフトの問題かと。
0198名無しさん＠お腹いっぱい。2014/08/06(水) 16:39:03.33
LOがらみ：
サイズに関する進展。

まず、壁は4KBじゃなく、8KB。しかも8192byteちょうどならフリーズ。8191byteならOK。
あと、これは予想されたことだが、showpage\n がファイル末尾ならどんなサイズでもOK。1文字でも余計に続くとフリーズ。

で、だ。これが不可解なんだが、write(2) で一発でパイプに書くんじゃなく、
1バイトずつ、1024バイトずつ、4096バイトずつ、小分けに書くとフリーズしない。
もちろんこの間 read(2) していない。

なぜだ？誰か名推理してくれ。あるいは次に調べること提案してくれ。
どうも FreeBSD 固有の pipe の実装にぶちあたってきた気がしてならない。

あと蛇足だが衝撃の事実。gs は標準入力を1バイトずつ read(2) してる。
0199名無しさん＠お腹いっぱい。2014/08/06(水) 17:24:26.66
読まずに書いてしまったが、>>193と>>194はこの現象をどう思う？
>>197はどこからそう判断してるの？
0200名無しさん＠お腹いっぱい。2014/08/06(水) 18:28:48.13
いい感じに盛り上がってるね。
0201名無しさん＠お腹いっぱい。2014/08/06(水) 20:46:12.80
追加情報：
EPSにはshowpageがあるのと、showpageがないか無効化されてるのがあり、
後者はgsが入力の最後までちゃんと読むので、write(2) が完了し、
サイズによらずフリーズしない。

linux (Fedora 20) で LibreOffice 4.1.3.2 を使ってフリーズさせることに成功。
ただ条件がかなり狭い。
sinx.epsみたいなのに何MBも冗長な行を追加してもフリーズしない。
write(2) は何MBも一気にパイプに書いたが、なぜ可能か不明。
画像をpnmtopsしただけの1MB超EPSに数十KB冗長な行を追加するとフリーズした。
0202名無しさん＠お腹いっぱい。2014/08/06(水) 21:54:11.92
>>198
・showpageが途中に来る(gsc入力終了前に出力が始まる)
・8KB以上の入力
・4KB以下を一括でwrite
の三条件で発生して、
・止まるときは4KB以上のwriteがブロックしたまま停止する
ってことか。showpageの情報と分割writeの情報で一気に予測が進むね。
4KB以上のwriteではwriteから抜ける条件が全データreadされること、なのかもね。
4KB超えたらパイプバッファが足りないからreadを待って続きをwriteってのありそう。
4KB以下なら大丈夫なのは、showpageの後ろが4KB以下だからバッファへwriteして抜けれるとか。
なら多分BMPサイズが4KB以下のもセーフかも。

FreeBSDのソース読んでみようかな。
0203名無しさん＠お腹いっぱい。2014/08/07(木) 02:47:40.62
https://svnweb.freebsd.org/base/release/9.3.0/sys/kern/sys_pipe.c?revision=268523&;view=markup
うげぇ・・・K&Rスタイルの引数指定かよ・・・
・・・よし、なんとなく把握した。202時点で想像した形と案外近かった、かな。

FreeBSDのパイプにはdirect I/Oってモード(pipe_build_write_buffer)があって、
これはカーネルにマップしたwrite側プロセスのメモリをパイプバッファとして使う。
一度にマップする量はpipe_buffer.size以下で、マップする前にバッファが空になるのを待つ。
マップするから当然、マップしたデータを全部readしてもらうまでwriteはブロックしたまま。
writeの時に残りのread待ちデータがバッファサイズ以下でもブロックするのは不味いねぇ…。

ってわけで対策考えてまとめてみた。間違ってたらごめんなさい。
・LOで出来る対策(根本治療)→横着しないでreadとwriteを並列に動かす(大事)。
・GSで出来る対策(根本治療)→showpageしても、readとwriteを並列に動かす(大事)。
・BSD User側対策(根本治療)→gscをシェルスクリプトとかで差し替え(>>144)。
・LOで出来る対策(対処療法)→writeを刻んだりシェルスクリプトを経由させたり(>>144>>198)。

↓100%対策じゃないけど、フールプルーフになる。
・BSD User側対策(対処療法)→PIPE_MINDIRECTを上げたりPIPE_NODIRECT有効でカーネル再構築。
・BSD Kernel改良(対処療法)→direct I/Oモードを使う場合も、バッファを活用する。
　・バッファサイズを超えたwriteを抜ける時はバッファが満タンになるように、
　　pipe_build_write_bufferではpipe_buffer.size以下を全部マップせず、
　　writeの最後でuio->uio_residがPIPE_MINDIRECTかpipe_buffer.sizeになるよう制限する。
　・uio.uio_residがwpipe->pipe_buffer.size以下ならpipe_direct_writeのmsleepは
　　無限待ちせずタイムアウトからのpipe_clone_write_bufferで抜ける。
　　所詮フールプルーフだからできるだけdirect I/Oで稼ぐ為タイムアウト。

■DEFINE設定値
PIPE_SIZE：pipe_buffer.sizeの最大値。デフォ16384。
PIPE_MINDIRECT：direct I/O自動選択の条件、PIPE_SIZEより小さい。デフォ8192。
PIPE_NODIRECT：pipe_direct_writeを使わせないフラグ。
0204名無しさん＠お腹いっぱい。2014/08/07(木) 02:48:15.69
sys_pipe.cの頭とかヘッダにも色々書いてあるけど、英語苦手なんでコード中心に当てずっぽう

sys_pipe.c(970)■pipe_write(パイプへの通常書き込み)
PIPE_NODIRECTが未指定で、io要求のバッファがユーザ空間であり、
io要求のバッファサイズがPIPE_MINDIRECT以上であり、
パイプ自身の現在のバッファサイズがPIPE_MINDIRECT以上であり、
パイプのFNONBLOCKビットが0である場合pipe_direct_writeを使うよ。

■sys_pipe.c(871)■pipe_direct_write(パイプへの直接書き込みまたは特定の通常書き込み)
/* This implements the pipe buffer write mechanism. Note that only
&#160;* a direct write OR a normal pipe write can be pending at any given time.
&#160;* If there are any characters in the pipe buffer, the direct write will
&#160;* be deferred until the receiving process grabs all of the bytes from
&#160;* the pipe buffer. Then the direct mapping write is set-up. */
■訳：パイプへのdirect I/Oまたは通常の書き込みがブロックされる可能性に注意。
パイプバッファに文字が残っていると、読み側が全部読むまでブロックするよ。
pipe_direct_writeはそれが終わったらこの書き込みの処理をするよ。
■追記：あと、これ使って書いたデータが全部readされるまでブロックするよ。
(シグナルとか？)エラーが出たらpipe_clone_write_bufferで通常バッファ戻すよ。
pipe_direct_writeの大半ははdirect I/Oの完了待機部分で、コイツが呼んでる
pipe_build_write_bufferがどっちかといえばpipe_direct_writeの本体ぽい感じ。

sys_pipe.c(770)■pipe_build_write_buffer(直接書き込みのバッファ作成)
/* Map the sending processes' buffer into kernel space and wire it.
&#160;* This is similar to a physical write operation. */
■訳：カーネル空間に送信バッファをマップします。物理書き込みと同等です。
■追記：名前は普通パイプバッファを作る関数だけど、実際はdirect I/Oのマップ作業
write要求量がpipe_buffer.size以上ならpipe_buffer.size分だけマップする。
0205名無しさん＠お腹いっぱい。2014/08/07(木) 04:02:36.68
す、凄い。原因究明して、かつ、複数の対策まで。恐れ入ります。
0206名無しさん＠お腹いっぱい。2014/08/07(木) 05:23:37.04
調査乙です。バグというより互換性問題なのか。

しかしこの理由だとするとFreeBSDでしか起きない現象なのかな。本当はLOを直すのが
よさそうだけど、FreeBSD固有の問題だとLO本家が直してくれるかどうか怪しいかも。
0207202-2042014/08/07(木) 05:33:49.01
>>206
・gsがshowpageした後writeが終わるまでreadしない
・LOがwriteし終わるまでreadしない
のが原因だからLinuxでも再現するはず。
FreeBSDだとdirect I/Oになるとバッファサイズによらずreadが終わるまでwriteが
終わらない(実質バッファサイズが0のような挙動になる)から発症率が高いけれど、
出力画像とshowpageの後ろのゴミが両方パイプバッファサイズ以上ならOS問わず固まると思う。
0208202-2042014/08/07(木) 05:41:05.83
>>205-206
凄いのはパイプの挙動やshowpageやepsファイルサイズが再現性に影響する事を見つけた人だと思う。
デバッグには再現性に関わる部分に詳しいバグ報告が大事ってのをよく表すんだなぁと198みて思った。
0209名無しさん＠お腹いっぱい。2014/08/07(木) 06:28:00.10
きちんとバグ報告までしない限り、実質的に何もしてないのと同じなので別に凄くない
0210名無しさん＠お腹いっぱい。2014/08/07(木) 08:07:25.31
なるほどねぇ。
刻むとフリーズしない理由も見事に説明できてる。
linuxでもフリーズする事例はできてるんだから、
LO側の対策も受け入れてもらえるでしょ。
0211名無しさん＠お腹いっぱい。2014/08/07(木) 08:21:49.33
追記
ブロッキングなwrite(2)がブロックしやすいパイプ実装をしてしまっただけの
FreeBSDには何の落ち度もないね。
どう見ても、双方向なパイプを逐次処理で実装したLOが悪い。
GSにshowpage後に入力をclose(2)させるのは、epsだけならそうだけど、
ふつうのpsと区別できるとは思えないので困難と思われる。
0212名無しさん＠お腹いっぱい。2014/08/07(木) 08:42:30.10
一番凄い>>209がバグ報告してくれる。
0213名無しさん＠お腹いっぱい。2014/08/07(木) 09:42:05.70
>>212
www
0214名無しさん＠お腹いっぱい。2014/08/07(木) 09:48:19.24
>>212
2chはこういう他力本願のクズが多いね本当に
0215名無しさん＠お腹いっぱい。2014/08/07(木) 09:52:28.08
作業に絡めなかった>>209がなんか言ってる
0216名無しさん＠お腹いっぱい。2014/08/07(木) 10:39:53.70
>>215
絡みたくてもcもc++も読めなくて悔しかったのかもな
0217名無しさん＠お腹いっぱい。2014/08/07(木) 10:48:17.16
実際LibreOfficeが直らなきゃ解析した意味がないということで、>>209の書くことも一理ある
0218名無しさん＠お腹いっぱい。2014/08/07(木) 11:16:59.25
バグの場所わかったからってすぐバグレポート書けるわけないのを知らないの？
0219名無しさん＠お腹いっぱい。2014/08/07(木) 11:30:54.34
>>209ほどの人ならすぐ書けるだろ。
0220名無しさん＠お腹いっぱい。2014/08/07(木) 12:32:42.92
調べたのを褒めてもらいたかったのにけなされて切れてる人がいる風味
0221名無しさん＠お腹いっぱい。2014/08/07(木) 13:01:12.27
で、調べた人叩いて何か意味があるの？けなさないと気がすまない症候群？
0222202-2042014/08/07(木) 22:50:32.72
>>209
わざわざそういう言い方する必要はないと思うけど、まぁそうだね。報告も超大事。
英語苦手なんでしばらく様子見するけど、FreeBSDのpipeの挙動は
進展が無い様だったらそのうち報告をBugzillaにでも投げてみるよ。
LOの方はユーザじゃない(Xすら入れてない)ので特に触る気はない。
GSの方はどうすっかなぁ…GS側はある程度仕方ない面も有りそう、
というかLOが酷すぎるから知ったことじゃない、で終わる気もするし。

>>220
誰が誰に貶されて切れてるって？
0223名無しさん＠お腹いっぱい。2014/08/07(木) 23:10:11.45
あんなひどいコーディングしてるのにFreeBSDにバグ報告されたら迷惑です。
0224名無しさん＠お腹いっぱい。2014/08/07(木) 23:32:10.06
1ヶ月たっても誰も何のアクションもしなかったとしたら何だかなあと思うけど、
今の時点で言うこっちゃない。
0225名無しさん＠お腹いっぱい。2014/08/08(金) 06:11:38.87
２ちゃんなんかでやっちゃったせいで報告すべきところへ報告できなくなる奴とかいるよなｗ
0226名無しさん＠お腹いっぱい。2014/08/08(金) 15:33:10.87
https://github.com/freebsd/pkg/issues/912

pkgコマンドで-fオプションが効かなくなった
■ このスレッドは過去ログ倉庫に格納されています