FreeBSDを語れ Part38

**名無しさん＠お腹いっぱい。** · 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/

**名無しさん＠お腹いっぱい。** · 2014/07/14(月) 06:53:34.60

FreeBSDはUNIXじゃないんですかぁ？

**名無しさん＠お腹いっぱい。** · 2014/07/15(火) 01:51:56.73

FreeBSD ports pkg だと texlive と teTeX を共存できないんだよな。。。

**名無しさん＠お腹いっぱい。** · 2014/07/15(火) 04:54:45.12

そういう個人的感想はいいです。

**名無しさん＠お腹いっぱい。** · 2014/07/15(火) 05:50:05.49

うちで飼ってるポチが夏バテなんだが

**名無しさん＠お腹いっぱい。** · 2014/07/15(火) 06:17:57.87

そういう動物日記はいいです。

**名無しさん＠お腹いっぱい。** · 2014/07/15(火) 07:52:55.31

もうこっちの方は、テンプレにも載らないんだね。
http://www.jp.freebsd.org/

それから、テンプレ的に、こっちはいらんのか？
http://gihyo.jp/admin/clip/01/fdt

**名無しさん＠お腹いっぱい。** · 2014/07/15(火) 08:05:47.23

そういう間接情報はいいです。

**名無しさん＠お腹いっぱい。** · 2014/07/15(火) 22:39:45.37

>>3
texlive だけでいいんじゃない？

**名無しさん＠お腹いっぱい。** · 2014/07/15(火) 23:30:10.89

>>9
texliveはデフォルトになってないから、バイナリで入れるとtetexになってしまうんだよね
デフォルトにしようぜっていうPRも最近出てるけどね

**名無しさん＠お腹いっぱい。** · 2014/07/16(水) 02:22:28.23

texliveってこれまでのEUC資産も問題なく使えるんでしょうか？
デフォルトになるならさっさと移行してしまってもいいんですが
UTF-8がどうも強調されてて、かつtetexと排他的な部分が多いので
試してみるハードルが高いというか

**名無しさん＠お腹いっぱい。** · 2014/07/16(水) 02:23:07.38

>>9
texlive だと gnuplot が入らなくなってしまうのよ。
gnuplot　の ports and pkg が tetex を要求して、 tetex は texlive があると入らないから。

**名無しさん＠お腹いっぱい。** · 2014/07/16(水) 02:25:46.92

>>10
どう言う意味？ pkg で texlive 入れたよ。
で、入れてしまってから gnuplot が入らなくて後悔。

**名無しさん＠お腹いっぱい。** · 2014/07/16(水) 07:10:42.27

>>13
だからその後悔があるってこと
tex依存のpkgはどれもtetex入れようとするから、
そいつらは全部portsから入れてlockしなきゃいけない

**名無しさん＠お腹いっぱい。** · 2014/07/16(水) 10:24:17.04

むしろtexliveを使わなければ良いのでは？
latexを使うだけなら、tetexでも問題ないと思うけど。

**名無しさん＠お腹いっぱい。** · 2014/07/16(水) 10:26:00.58

そういう個人的方針はいいです。

**名無しさん＠お腹いっぱい。** · 2014/07/16(水) 12:03:50.62

>>16
latexを使うだけ

**名無しさん＠お腹いっぱい。** · 2014/07/16(水) 19:35:02.51

しばらく texlive は遠慮した方が良さそうだね。

**名無しさん＠お腹いっぱい。** · 2014/07/16(水) 20:22:06.61

>>18
現状で困ってないならあえて移行する必要ないよ
おれはeptexベースのlatexでしか動かない奴があるから
しかたなく移行した

**名無しさん＠お腹いっぱい。** · 2014/07/16(水) 20:55:46.87

portshakerで混ぜる奴はまた別の話なの？

**名無しさん＠お腹いっぱい。** · 2014/07/16(水) 23:38:41.08

そこで、jail ですよ。

**名無しさん＠お腹いっぱい。** · 2014/07/16(水) 23:45:43.94

wineコンパイルする為にjailで32bit環境作ったなあ。

**名無しさん＠お腹いっぱい。** · 2014/07/17(木) 01:01:56.33

Windows動かすなら VirtualBoxの方がいいべ。

**名無しさん＠お腹いっぱい。** · 2014/07/17(木) 01:46:15.65

>>20
別物

**名無しさん＠お腹いっぱい。** · 2014/07/17(木) 12:29:38.93

FreeBSD では texlive はまだ早いって事ね。了解です。

**名無しさん＠お腹いっぱい。** · 2014/07/17(木) 13:43:40.32

texlive はpkgで入れないで普通に入れればいいのでは?

**名無しさん＠お腹いっぱい。** · 2014/07/17(木) 14:43:29.90

FreeBSD 9.2-RELEASE-p7から、FreeBSD 9.3-RELEASEへアップデート中。
freebsd-update使ってるんですがパッチ数39077... まだ終わらない。結構かかりますね・・・

**名無しさん＠お腹いっぱい。** · 2014/07/17(木) 15:19:10.64

>>26
＞texlive はpkgで入れないで普通に入れればいいのでは?

それではダメです。

**名無しさん＠お腹いっぱい。** · 2014/07/17(木) 15:36:26.14

>>28
なぜ?

**名無しさん＠お腹いっぱい。** · 2014/07/17(木) 17:45:06.03

入らないのは texlive ではないからです。
>>14 を参考。

**名無しさん＠お腹いっぱい。** · 2014/07/17(木) 20:50:58.75

ちなみにtexliveが入っていても、gnuplotをportsから"TEX"オプションオフで入れる
ことは可能。
gnuplotから直接TeX用の出力できなくなるはずだけど、それでもよければ。
かつ、手間が気にならないなら。

**名無しさん＠お腹いっぱい。** · 2014/07/17(木) 21:07:59.19

前スレ944です。
9.3Rをクリーンに入れて LibreOffice 4.2.5_2 の pkg を試して見ました。
やはり、あの画像つきプレゼン・ファイルでフリーズしました。

一方、Windows に入れた 4.2.5_2 ではフリーズもせず、画像も正常に表示されました。
もちろん、ghostscript を入れて path を通した windows ですが。
OSX でも正常との事だったので、今のところフリーズするのは FreeBSD だけの様です。

**名無しさん＠お腹いっぱい。** · 2014/07/17(木) 21:35:14.18

>>31
portsから入れるんならそのままtexliveと共存できる

**名無しさん＠お腹いっぱい。** · 2014/07/17(木) 23:26:44.53

>>33
ありゃ、オフにする必要なかったか。そのうちやってみる。

**名無しさん＠お腹いっぱい。** · 2014/07/18(金) 00:04:43.21

>>34
そういえば、make.confに、TEX_DEFAULT=texlive な

**名無しさん＠お腹いっぱい。** · 2014/07/18(金) 11:17:15.49

gnuplot って、出力したものを直接TeXで使うというシチュエーションがあまり無いような感じがするんだが。

たとえば、実際論文とか書くときって、フォントの大きさとか、線の太さとか調整して見やすくするもんじゃない？
だから、epsに出力できれば十分だと思うけど。

**名無しさん＠お腹いっぱい。** · 2014/07/18(金) 11:25:43.98

>gnuplot って、出力したものを直接TeXで使うというシチュエーションがあまり無いような感じがするんだが。

まったく同意だけど、

>たとえば、実際論文とか書くときって、フォントの大きさとか、線の太さとか調整して見やすくするもんじゃない？
>だから、epsに出力できれば十分だと思うけど。

それが、eps より tex source の方がやり易いと言うことでは。

それより、gnuplot の中で (la)tex command が使えたら超便利なのに。
そのための tex 依存なら納得できる。

**名無しさん＠お腹いっぱい。** · 2014/07/18(金) 17:07:17.10

>>36
そういえば俺修士論文でgnuplot使わなかったな。

**名無しさん＠お腹いっぱい。** · 2014/07/19(土) 04:09:08.14

gnuplot+ が復活しないものかのう・・・ふがふが・・・

**名無しさん＠お腹いっぱい。** · 2014/07/20(日) 06:26:59.00

FreeBSD10.0R
Cx5x86ではブートできない。
9.3RならOKなのでclangが悪さしてるのかなあ

**名無しさん＠お腹いっぱい。** · 2014/07/20(日) 11:16:49.04

clangがな

**名無しさん＠お腹いっぱい。** · 2014/07/21(月) 18:09:04.73

フォントリワインド祭ｗ

**名無しさん＠お腹いっぱい。** · 2014/07/22(火) 03:21:52.40

Linux エミュレーションはどれを使うのがベストなんでしょうーかね？

**名無しさん＠お腹いっぱい。** · 2014/07/22(火) 20:00:18.18

一択だろ。

**名無しさん＠お腹いっぱい。** · 2014/07/22(火) 20:21:46.79

わかりました。qemuにします。

**名無しさん＠お腹いっぱい。** · 2014/07/22(火) 22:48:40.26

>>45
そこはもっとマイナーに攻めろよ
bochsとか

**名無しさん＠お腹いっぱい。** · 2014/07/23(水) 10:58:44.32

わかりました。Virtual-PCにします。

**名無しさん＠お腹いっぱい。** · 2014/07/23(水) 11:13:44.95

Hyper-V一択だろ。

. · 2014/07/23(水) 11:18:16.16

おまいらBHyVeを忘れていないか？

**名無しさん＠お腹いっぱい。** · 2014/07/23(水) 13:15:23.62

bhybeでlinux動くようになったんか

**名無しさん＠お腹いっぱい。** · 2014/07/23(水) 13:32:41.17

動かない理由があれば聞いてみたいところだけど？

**名無しさん＠お腹いっぱい。** · 2014/07/23(水) 14:09:16.59

いや、別に理由は無いよ。知らないだけw
Windowsとかも動くようになったん？

**名無しさん＠お腹いっぱい。** · 2014/07/23(水) 14:27:10.99

>>52
前は動かなかったの?

**名無しさん＠お腹いっぱい。** · 2014/07/23(水) 15:22:19.33

前スレ944です。
LibreOffice がフリーズする件ですが、Linux ユーザに訊いてみたところ、正常に開けるとの事でした。
今のところ、フリーズするのは FreeBSD の LibreOffice だけの様です。
となると、移植でのバグですかね。どこへ報告して良いのか迷います。
また、フリーズは原因究明が困難なので、自分で直すのはちょっと諦め気味です。

**名無しさん＠お腹いっぱい。** · 2014/07/23(水) 16:04:50.77

わかりました。Linuxに戻します。

**名無しさん＠お腹いっぱい。** · 2014/07/23(水) 20:05:31.38

bsdユーザーかつoooの関係者である某氏に聞けばいいと思うよ(^^)

**名無しさん＠お腹いっぱい。** · 2014/07/23(水) 20:07:55.38

伏せ字で言われましても

**名無しさん＠お腹いっぱい。** · 2014/07/23(水) 20:31:27.25

>>54
http://maguro.2ch.net/test/read.cgi/linux/1074622851/519
これが正しく開ける状態かな。

debian jessieのはヘルプで見ると http://i.imgur.com/ZLdIAHC.png
のように v4.2.5.2 と表示されるけどパッケージ情報を見ると
Version: 1:4.2.5-1+b1 となっているのでdebianメンテナが
何かパッチを当てたのでしょう。
落ちるのは分からないけど、サイングラフが表示されないのは
何かライブラリが足りない可能性もありえないかな。

バグ報告先は
https://wiki.documentfoundation.org/QA/BugReport/ja
かも。ちなみに
LibreOffice PART16
http://anago.2ch.net/test/read.cgi/software/1388069898/
というスレもありますね。

**名無しさん＠お腹いっぱい。** · 2014/07/23(水) 22:32:42.53

TeX Live がデフォルトになったようだ

**名無しさん＠お腹いっぱい。** · 2014/07/23(水) 22:50:45.50

わしもBochsで「うひょーーー遅えｗｗｗｗ」する一択だと思う

54 · 2014/07/24(木) 07:24:21.77

>>58
ええ、それが正しく開けた状態です。
なるほど。もしパッチで修正されたのなら希望が持てます。
フリーズせずに表示されない場合は gs が入ってない場合と思います。

原因を絞るために、まず、各プラットホームでの状況を調べてみました。
これまでの所、フリーズするのは FreeBSD のみです。
そうなると、FreeBSD は正式にサポートされてないので、本家に報告するのは躊躇われるのです。

自分で原因を突き止めて直したいと思うのですが、フリーズは場所の特定が難しく挫折しました。
クラッシュならコアを調べる等あるのですが、フリーズはどうして良いものか....
gdb の attach も場所の特定には至らない様ですし...

**名無しさん＠お腹いっぱい。** · 2014/07/24(木) 07:49:55.38

よく分からんけどドキュメントを部分ごとに分割して、
どの部分の表示でフリーズするとか絞り込んだり
できないかな

**名無しさん＠お腹いっぱい。** · 2014/07/24(木) 07:54:46.14

ああ、>>62の分割ってのは、編集できる環境で編集して。
Debian Jessieで正しく表示されるなら、LMDE(Linux Mint Debian Edition)や
Mint17やUbuntu14.04などのLiveDVDに入ってるLibreで編集できるかも知れん。

54 · 2014/07/24(木) 08:43:18.72

>>63
そう言う意味では切り分けはできています。
EPS file が貼られたファイルでフリーズが起こります。
FreeBSD の gs に問題があるのですかね？
でも、問題起こす EPS file も gv では問題なく表示されます。うーむ。

**名無しさん＠お腹いっぱい。** · 2014/07/24(木) 10:03:56.54

>>61
コアがあればいいだけならシグナル送ってコアを吐かせればいい。
attachするのと変わらないと思うけど。

gdbでまともに見るには全部 -g つけるとか。WITH_DEBUGとか効くかな？

**名無しさん＠お腹いっぱい。** · 2014/07/24(木) 10:16:14.43

ktrace/kdumpで何をwait4しようとしてるのか見てみるのが良さそう。

**名無しさん＠お腹いっぱい。** · 2014/07/24(木) 10:43:21.53

>>66
スレッドまわりかなと思ってたが、waitと特定できてるの？
まあktraceしておくのは有効だよね。

**名無しさん＠お腹いっぱい。** · 2014/07/24(木) 11:07:09.15

pkg1.3の新機能でSATソルバ搭載とか書いてるけど、何にSATがいるの？

**名無しさん＠お腹いっぱい。** · 2014/07/24(木) 14:24:05.17

この時期脇汗が多い奴ってwait4を使ってるよなｗ

**名無しさん＠お腹いっぱい。** · 2014/07/24(木) 15:10:41.98

>>67
http://peace.2ch.net/test/read.cgi/unix/1390323139/974
彼はlibcが悪いの？とかトンチンカンな事言ってたが、
コレ見る分にはwait4で止まってたということらしい。

**名無しさん＠お腹いっぱい。** · 2014/07/24(木) 15:13:41.00

正常動作中のソフトだって平常時にダンプするとwait4で止まってるのが観測できるぞ。

**名無しさん＠お腹いっぱい。** · 2014/07/24(木) 15:22:55.13

この人がこのスレッドが主犯だと判断した理由が分からんとなんともだけど、
コールスタック見ると長く待つ為のwait4が入る場所ではなさ気だから怪しくはある。

**名無しさん＠お腹いっぱい。** · 2014/07/24(木) 15:51:31.32

誤報SIGCHLDが飛んでwait4()で待ちぼうけというのが一般的にはある。

**名無しさん＠お腹いっぱい。** · 2014/07/24(木) 22:22:09.32

>>73
誤報っつーか、それアプリケーション側のバグでしょｗ
SIGCHLDが飛ぶ機会が終了以外にもあるとか、シグナルの非同期性を理解してないコーディングになってたりとか。

**名無しさん＠お腹いっぱい。** · 2014/07/25(金) 00:07:52.53

>>59
デフォルトになったというか、tetexがバンバン消されていっているようなんですが、
これってちょっと変化が急激すぎやしませんかね？
今後、日本語tex環境を入れようとしたら、これっていうメタポートはあるんだろうか

**名無しさん＠お腹いっぱい。** · 2014/07/25(金) 00:24:03.36

>>75
俺はもっとやれ派

**名無しさん＠お腹いっぱい。** · 2014/07/25(金) 00:55:02.51

なんでここってゲーム＝紙芝居なの？
マリオ動かしたり飛行機操作する方が楽しいのに

**名無しさん＠お腹いっぱい。** · 2014/07/25(金) 00:56:32.22

見なかったことにしてください

**名無しさん＠お腹いっぱい。** · 2014/07/25(金) 08:06:30.74

>>75
個人的には
print/texlive-full
を使っているが
いらない機能までインストールしすぎ
という悪寒もある

54 · 2014/07/25(金) 13:28:10.25

>>66
ktrace しながらフリーズさせてキルして見ました。

http://fast-uploader.com/file/6961817882204/

何か分かるでしょうか？

**名無しさん＠お腹いっぱい。** · 2014/07/25(金) 15:50:53.19

portmasgerの……というか、pkgを更新したらこうなったのだけど、
REPLACE_ORIGINが効かなくなってない?

**名無しさん＠お腹いっぱい。** · 2014/07/27(日) 16:31:29.81

米国議会関係者がWikipediaでFreeBSDの記事を編集していることが判明

1 名前:番組の途中ですがアフィサイトへの転載は禁止です :2014/07/27(日) 14:50:44.27 ID:Pune7i/30 BE:469226128-2BP(1000)
Wikipedia Foundation : 妨害工作の多発で米国議会による編集行為を一時的禁止
Posted 12 hours ago, by Scott Newman

Wikipedia Foundationは、米国議会のIPアドレスによる編集妨害工作が多発したことを理由に、
一時的に米国議会のIPアドレスを用いた匿名での項目の編集を禁止する措置を講じたことがBBCなどの報道により明らかとなった。

今回の措置は10日間の一時的措置となる。また、編集が禁止となるのは米国議会のIPアドレスを用いた匿名による編集に限られており、
米国議会のIPアドレスを用いた場合であっても登録されたユーザーIDを用いて編集を行う場合には、規制の対象とはならない。

米国議会のIPアドレスによる編集妨害工作が多発する状況となったのは、米国議会のIPアドレスから編集が行われた場合、
その内容を自動的にTweetする@congresseditsによって公然化したものとなる。

米国議会のIPアドレスからは、ドナルド・ラムズフェルド元国防長官は「爬虫類のエイリアン（alien lizard）」、
ケネディー大統領の暗殺は「カストロ政権の意向により実施された」、ウクライナの政治家のナタリヤ・ヴィトレンコは「ロシア政府の傀儡」といった書き込みが続くなど、
Wikipedia Foundation では以前から米国議会関係者に対して、編集妨害工作を行わないように警告を発してきた。

中略

一方、米国議会関係者からは「2、3名の関係者がそうした行為を行ったからといって、9000名の議会スタッフ全員の編集を禁止する措置を講じるのはいかがなものか？
私が知っている範囲で周りの人がやっている編集は、記事の文法上のミスや、野鳥に関わること、また、KDE2やFreeBSDに関わる事柄などです」
とするUser talkがあるなど、コミュニティーによる容易な規制発動に対して批判を加えている。

ソース全文
http://www.businessnewsline.com/biztech/201407270142340000.html
自動的にTweetする@congressedits
https://twitter.com/congressedits

**名無しさん＠お腹いっぱい。** · 2014/07/27(日) 20:06:01.28

>>75
obsolete過ぎて危ないのに、直ぐには消せないからということで
むしろここまですごく時間を掛けてやっと辿りついたっていう印象なんだけどなあ。

**名無しさん＠お腹いっぱい。** · 2014/07/28(月) 14:56:13.95

ネット未接続の環境でFreeBSDを8.2->10.0に入れなおして三週間、
ようやく満足に動く環境が出来た。
・sysinstallドコー、mount_ntfsドコー
・pkg bootstrapてどうよ
から始まってC++とRubyの開発環境が揃うまで長かった……

メモリイメージ焼いたDVDからパッケージを適当に入れて、
特に興味のある物はソースからインストールという昔ながらの方法でやったが、
そろそろ限界かな。

clangとgccの互換性は高いが混ざると落ちることもあるみたい。
色々勉強になったからよしとしよう

**名無しさん＠お腹いっぱい。** · 2014/07/28(月) 19:34:51.43

10.0 では DVD から package を入れる事は出来ないと思ったけど。

**名無しさん＠お腹いっぱい。** · 2014/07/28(月) 19:47:07.42

pkg 1.2.7でオリジナルリポジトリをtbzで作製してうまく動作していたのですが
pkg 1.3.2では pkg repo でtbzを認識してくれません

対処方法はありますでしょうか？

**名無しさん＠お腹いっぱい。** · 2014/07/28(月) 23:27:13.43

age

**名無しさん＠お腹いっぱい。** · 2014/07/29(火) 01:08:14.70

どんだけチューニングしてる浦島太郎ですかw
portsが使えるからまだ大丈夫だよ

**名無しさん＠お腹いっぱい。** · 2014/07/29(火) 13:30:19.38

今北産業

pkg 何かアレなことになってるん?

**名無しさん＠お腹いっぱい。** · 2014/07/29(火) 19:43:17.01

pcdm を FreeBSD で使っている人は居ませんか？

80 · 2014/07/29(火) 20:59:39.90

>>80 の続きです。ktrace を見ていておかしい箇所が分かりました。

フリーズする直前に実行している下の部分の、"write 4096 byte" の 4096 がおかしいです。
EPSファイルを読み込んでフリーズが起きるのですが、フリーズしない場合を ktrace で見ると、
そこの数字が正しいファイルサイズになっています。一方、フリーズする場合は、
実際のファイルサイズより小さい 4096 になっていて、中身の途中までしか write されていないのが見て分かります。
これが原因で wait が起きているように思えます。ファイルサイズを間違える原因はまだ分かってません。
ファイルサイズの問題でしょうか？例えば、フリーズしないのが tgif で作った 3K のファイルで、
するのが gnuplot で作った 11K のファイルです。もう少し調べてみます。
-------------------------------------------------
1140 soffice.bin GIO fd 51 wrote 4096 bytes
"%!PS-Adobe-2.0 EPSF-2.0
-----------------------
cut
-----------------------
/Circle { stroke [] 0 setdash 2 copy
hpt 0 360 arc stroke Pnt } def
/CircleF { stroke [] 0 setdash hpt 0 360 arc fill } def
/C0 { BL [] 0 setdash 2 copy moveto vpt 90 450 arc } bind def
/C1 { BL [] 0 setdash 2 copy moveto
2 copy vpt 0 90 arc closepath fill
vpt 0 360 arc closepath } bind def
/C2 { BL [] 0 setdash 2 copy moveto
2 "
-----------------------------------------------------------------

**名無しさん＠お腹いっぱい。** · 2014/07/29(火) 21:49:38.87

>>91
4KBピッタリって辺りからして、4KBずつ書き込むんじゃね？
次の4KBを書き込む為の条件が満たせないと固まるとか。

**名無しさん＠お腹いっぱい。** · 2014/07/29(火) 21:57:09.64

>>92
なるほど。確かにそうですね。
次を書き込む為の条件を調査してみます。
と言っても、全然あてはないのですが...

**名無しさん＠お腹いっぱい。** · 2014/07/29(火) 21:58:16.93

ページサイズ単位のI/Oというと、stdio経由でのI/Oをしてるんかね。

**名無しさん＠お腹いっぱい。** · 2014/07/29(火) 23:52:07.44

入力が4KB溜まるまで待ってるってことはない？

**名無しさん＠お腹いっぱい。** · 2014/07/30(水) 05:32:01.13

wait4といいwriteといい、そこが原因ではないよ

**名無しさん＠お腹いっぱい。** · 2014/07/30(水) 06:34:45.00

>>96
特定したならパッチを投げてあげてくれ。

**名無しさん＠お腹いっぱい。** · 2014/07/30(水) 09:38:00.19

まっさらな状態からpkgでデスクトップ構築する手順って
どっかに買いてないですかね？
Ubuntuと同じデスクトップでいいので

. · 2014/07/30(水) 10:04:14.79

素のFreeBSDでgnome3を導入したこと無いや。
普段はmateかlxdeだし。

**名無しさん＠お腹いっぱい。** · 2014/07/30(水) 11:17:09.13

>>99
ログインマネージャーは使ってますか?

. · 2014/07/30(水) 12:16:21.61

>>100
gdm使ってます。
無設定ですぐ使えるので。

**名無しさん＠お腹いっぱい。** · 2014/07/30(水) 13:00:03.13

>>101
gdm 入れると gnome2 がほぼ全部入ってしまうけど気にしない、と言うスタンスでしたっけ。

. · 2014/07/30(水) 13:07:33.12

>>102
そうですね。
HAL周りもなにも弄らなくていいし。

80 · 2014/07/30(水) 13:18:52.10

>>91 の続きです。

作ったソフトに関係なく、 4KB を越える EPS を貼ると、必ずフリーズする事がわかりました。
4KB 未満の EPS ならフリーズしません。また、4KB を越えても jpeg と png はフリーズしませんでした。

>>96
原因は送った先にあると言うことでしょうか？
FreeBSD の ghostscript9 が win や linux のと違う振る舞いをする、とかですか？

**名無しさん＠お腹いっぱい。** · 2014/07/30(水) 13:19:11.62

>>98
http://www.freebsd.org/doc/ja/books/handbook/x11-wm.html
とか

**名無しさん＠お腹いっぱい。** · 2014/07/30(水) 13:22:50.59

>>104
サイズを4KBの倍数になるようパディングしたら正常に動作したりして

84 · 2014/07/30(水) 14:25:05.34

>>85
力技を使えばできるよ。
まず、インストール用に配布されてるISOイメージの中で一番でっかいのをDVD-RAMに焼く。
こいつには(ちょっと古いしい色々足りないけど)Xとかある程度のpkgが含まれていて、
bsdconfigにもちゃんとCD/DVDからインストールするメニューがある。

もっともネット未接続だとpkg bootstrapがWebを観にいって失敗するんだが...
実はDVD上にも（ちょっと古いけど）pkgをtxz化したファイルが存在するので、
/etc/pkg/FreeBSD.confを書き換えてローカルファイルを読み込むように設定した上で、
名前も変更してファイル置いとけば、
pkg bootstrapも成功してDVD内の全pkgをインストールできるようになるよ。

正直オススメはしないが。

**名無しさん＠お腹いっぱい。** · 2014/07/30(水) 19:31:52.29

>>104
以下想像：
パイプかなんかで送っててパイプのバッファサイズが4KBしかない。
そこにwrite一発でファイル全体を送ってしまって、
書けた量を確認せず、waitでそのパイプ先の終了を待っている。
パイプ先は次の4KBが来るのを待っている。

**104** · 2014/07/30(水) 20:56:02.85

>>108
その場合、直すべきは一発でファイル全体を送っているところでしょうか？
LibreOffice の source にバグがある？

**名無しさん＠お腹いっぱい。** · 2014/07/30(水) 20:57:06.72

>>104
関連しそうなとこは
filter/source/graphicfilter/ieps/ieps.cxx の RenderAsBMPThroughGS() で、
gsのコマンドライン作って、RenderAsBMPThroughHelper() を呼んで、
中で runProcessWithPathSearch() でプロセス作って、
osl_writeFile() で pBuf 内のデータを nBytesRead バイトだけ書き込んでる。
sal/osl/unx/file.cxx 内の osl_writeFile() は書けたバイト数を管理してるように読める。

なので、デバッガかデバッグプリントつっこんで、
nBytesRead が正しいファイルサイズになってるかどうか調べてみたらいいんじゃないかな。
で、これが 4096 とかになってたら、その原因を探っていけばいい。
EPSを読むところがおかしいという可能性がある。

俺は今自由に動かせる 10-R がないので、これ以上は無理。

**名無しさん＠お腹いっぱい。** · 2014/07/30(水) 21:19:56.87

話続けるなら名前欄は固定してくれよ。

**104** · 2014/07/31(木) 02:13:19.12

>>111
わかりました。その辺り調べてみます。
ようやく原因が絞れて希望が出てきました。

>俺は今自由に動かせる 10-R がないので、これ以上は無理。

ちなみに、私の今のテスト環境は 9.3R です。
LibreOffice 4.2.5.2 がフリーズするのは 10.0R も 9.3R も同じでした。

**名無しさん＠お腹いっぱい。** · 2014/07/31(木) 10:11:29.46

>>111
面白そうなんで自分も見てみた。
RenderAsBMPThroughHelper()って、これダメじゃないか？
osl_writeFile()に渡してる引数&nCountでwrite()で書けたバイト数を貰ってくるが、
パイプから読むのは
if (nCount == nBytesRead)
の場合だけじゃん。
nCount != nBytesReadのときは子プロセスの出力読まずに終了待ちしようとするみたいだし。

**104** · 2014/07/31(木) 11:31:27.04

>>113
>面白そうなんで自分も見てみた。

ありがとうございます。自分はC言語が得意ではないので助かります。

>RenderAsBMPThroughHelper()って、これダメじゃないか？
>osl_writeFile()に渡してる引数&nCountでwrite()で書けたバイト数を貰ってくるが、
>パイプから読むのは
>if (nCount == nBytesRead)
>の場合だけじゃん。
>nCount != nBytesReadのときは子プロセスの出力読まずに終了待ちしようとするみたいだし。

この問題で、4KB未満のEPSファイルではフリーズせず、
4KBを越えるとフリーズするのが説明できるでしょうか？

また、修正案はあるでしょうか？
いただければ、反映させて LibreOffice を make して試してみます。

**名無しさん＠お腹いっぱい。** · 2014/07/31(木) 11:32:55.41

>>98
Ubuntuと同じって言っても...
GTK+3系のにしたいのなら、PC-BSDにでもしたら？

FreeBSDをPC-BSDにする方法は以下のURL
http://wiki.pcbsd.org/index.php/Turn_FreeBSD_into_PC-BSD%C2%AE

**名無しさん＠お腹いっぱい。** · 2014/07/31(木) 12:02:21.00

PC-BSD は zfs になってしまうからダメでしょう。オススメできない。

**名無しさん＠お腹いっぱい。** · 2014/07/31(木) 12:19:55.30

>>114
> 修正案はあるでしょうか？
丸投げしすぎ。

どの言語であれ、ブレークポイント掛けてデバッガでトレースしていくか、
printfなりなんなりをつっこんで、ちまちまデバッグしていくのが、発見者の努め。
言語による差異なんてほとんどない。

**名無しさん＠お腹いっぱい。** · 2014/07/31(木) 12:21:34.53

> その辺り調べてみます。
って、自分では何やったんだよ。

**名無しさん＠お腹いっぱい。** · 2014/07/31(木) 12:52:06.14

>>116
違う。俺が書いたURLを見てみな。
FreeBSDをインストールしたあとに、PC-BSDやTrueOSにするには、どうしたら良いのかが書いてある。
別にzfsにする必要はない。

**名無しさん＠お腹いっぱい。** · 2014/07/31(木) 13:21:55.34

>>115
Ubuntuは無理なのでGnome shellになると思いますが
まっさらな状態からなので、PC-BSDにしたいのならPC-BSD入れます
FreeBSD2.1から使ってる頭から見るとPC-BSDはかなり違うので
出来ればFreeBSDにUnityみたいなインターフェイスを入れたいと思ったのですが…
もしかして、これを入れればいいのかな
/usr/ports/x11/gnome-shell
これだけだと、ビジュアルシェルだけしか入らないような

**名無しさん＠お腹いっぱい。** · 2014/07/31(木) 13:49:51.00

>>120
自分も1.1時代から遊んでいますよ。
PC-BSDも10系になってからports,pkgを積極的に使うようになっています。
ですから、さほど違和感があるってほどじゃないと思いますよ。

Unityは無理ですが、Gnome3やCinnamonならPC-BSDのports treeを持ってきてbuildしたり、先に示したリンク中にあるpkgのreposなどを追加してpkg installで入れるという方法もあります。
pcdmはqt4関連を入れてから、gitでソースを持ってきてbuildしてあげればOKです。
まっさらなら、FreeBSDのportsとPC-BSDのportsとバージョンがバッティングしないはずなので、それでやってみるのはどうでしょう？

**名無しさん＠お腹いっぱい。** · 2014/07/31(木) 14:01:06.11

>>121
PC-BSDでports, pkgが使えるのですか
それならまずPC-BSDをやってみようかな

**名無しさん＠お腹いっぱい。** · 2014/07/31(木) 15:10:19.62

>>122
お節介ついでなのですが、PC-BSDのISOを落としてきてインストールすると、
/usr/local/pkg/repos/pcbsd.conf
のURLのバージョン部分が10-STABLEになっているんじゃないかと思います。
なんかフォルダ名を変えたみたいで、url=の部分を以下のように書き換えると
ｐｋgが正常に動作するようになると思います。

url: "http://pkg.cdn.pcbsd.org/10.0-STABLEJULY2014/amd64";

あとPCDMはgitじゃなくてsvnでしたね...

**名無しさん＠お腹いっぱい。** · 2014/07/31(木) 18:06:09.96

>>114
> また、修正案はあるでしょうか？
> いただければ、反映させて LibreOffice を make して試してみます。

と言うけど、Libre環境は仕事で必要なんじゃなかったっけ？
自分で修正してフリーズは回避できても、そういう場合
得てして潜在的に他にもおかしな処理があるかも知れない。

それが目に見えて分かるフリーズとかではなく、情報(計算数値など)
が微妙に間違って表示されるようなものだったとしたら、
仕事になんか安心して使えない。

**名無しさん＠お腹いっぱい。** · 2014/07/31(木) 19:19:49.74

うーむ、このプログラムをktraceしても、
20055 a.out GIO fd 1 wrote 4096 bytes
...
20055 a.out RET write 1048576/0x100000
ってなる。write() の書けたバイト数は、RET の行を見ないといけないな。
wrote 4096 bytes は、その分だけ表示してるってだけの意味に考えた方がいい。

というわけで、振り出しに戻る。

#include <string.h>
#include <stdio.h>
#include <stdlib.h>
int main(void)
{
int nBytesWritten;
char *p = malloc(1024*1024);
memset(p, 'x', 1024*1024);
nBytesWritten = write(1, p, 1024*1024);
fprintf(stderr, "%d bytes\n", nBytesWritten);
return 0;
}

**名無しさん＠お腹いっぱい。** · 2014/07/31(木) 19:44:24.69

Linuxだと、パイプに巨大なwrite()を実行しても1回のwrite()で全部書けてしまうみたいだわ。
パイプサイズ自体は4096byteのはずだけど、syscall内部でうまく計らってるのか？？

**名無しさん＠お腹いっぱい。** · 2014/07/31(木) 19:52:42.01

>>126
それはFreeBSDも同じ。問題はパイプの read() だろ。

**名無しさん＠お腹いっぱい。** · 2014/07/31(木) 20:09:51.92

最近のLinuxのパイプサイズは 256kB
ちょっと前が 64kB
もっと前が 4kB

**名無しさん＠お腹いっぱい。** · 2014/07/31(木) 20:16:46.90

>>104
生のktrace.outが欲しいわ。
タイムスタンプとかスレッドIDとか入ってるやつ。
でないと、CALLとRETの対応がつかなくて困る。

**名無しさん＠お腹いっぱい。** · 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に制限されている

**名無しさん＠お腹いっぱい。** · 2014/07/31(木) 22:11:49.30

いずれにしたってシステムコールの復帰値のチェックくらいしろやってことだろうな。
LibreOfficeですらこんな糞コーディングしちゃってることのがショックだ。

**名無しさん＠お腹いっぱい。** · 2014/07/31(木) 22:12:41.66

ことのが→ことが

**名無しさん＠お腹いっぱい。** · 2014/07/31(木) 22:33:18.30

ところで、フリーズする環境って、32bit？64bit？

**名無しさん＠お腹いっぱい。** · 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のコード(安定性含む)って評判良かったか？
マシなコードにするって目標が合っても、それが追いつくかどうかは別の話だと思う。

**名無しさん＠お腹いっぱい。** · 2014/07/31(木) 23:31:24.37

>>134
>write単発4KBで止まってるならその周辺って事で戻ってねぇと思うけど
すまんが何言いたいのかわからん

**104** · 2014/08/01(金) 00:18:08.90

>>129
遅くなりました。ktrace.out アップロードしました。
新しく取り直したものです。3MB あります。

http://fast-uploader.com/file/6962374997550/

**104** · 2014/08/01(金) 00:28:41.66

>>133
私が確認したのは amd64 だけです。
前スレに同じ様にフリーズする人が何人かいたのですが、どちらか聞き損ねました。

フリーズを起こすのは簡単です。
10R か 9.3R に LibreOffice 4.2.5-2 を入れて、
4KB を越える EPS ファイルを impress で挿入するだけです。
ダイヤログで「開く」を押した瞬間にフリーズします。
preview が on になっていると、選択しただけでフリーズします。

**104** · 2014/08/01(金) 00:36:27.07

>>124
常用している PC には 9.1R + LO 3.5.6.2 を残してあります。
9.3R や 10.0R を入れて試しているのは予備機の１つです。
LO4 が安心して使えないのは同意です。
でも、9.3R にも 10R にも LO4 しかないのです。

**104** · 2014/08/01(金) 00:38:50.22

>>118
まだ何もやってませんでした。

>>117
これからやってみます。

**名無しさん＠お腹いっぱい。** · 2014/08/01(金) 05:52:13.29

>>134
今どきcommit前にレビューのないプロジェクトって……

**名無しさん＠お腹いっぱい。** · 2014/08/01(金) 06:27:09.35

パイプサイズ増やしとけばとりあえず問題回避できるだろ

**名無しさん＠お腹いっぱい。** · 2014/08/01(金) 10:53:05.62

>>141
それで256Kになったんですね
わかります。w

**104** · 2014/08/01(金) 11:42:06.13

うわー。そうか、 linux ではバグがないんじゃなくて、バグが現れなかっただけなのか。
私がもう少し大きな EPS でテストして貰ってたら、同じ様にフリーズしてたのか。。。
win でどうか、大きな EPS を作って試して見ます。

**名無しさん＠お腹いっぱい。** · 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$$

というシェルスクリプトに変更して試してみてくれ。

**名無しさん＠お腹いっぱい。** · 2014/08/01(金) 12:12:40.57

こういうのって、読み書き両側をノンブロッキングモードにして、
selectなりしながらread/writeするのがありがちなのかな。
スレッド作っちまえって話もあるか。

**104** · 2014/08/01(金) 12:17:18.50

>>144
変えてみました。結果、フリーズなくなりました！
それどころか、正常に画像が表示されました。不思議です。

source を見ると、RenderAsBMPThroughGS() と RenderAsBMPThroughConvert()
のどちらかを実行するようになっているので、Convert の方が実行されたのでしょうか？
とにかく、大きな前進です。

**名無しさん＠お腹いっぱい。** · 2014/08/01(金) 12:21:45.14

でも、gsが、入力全部来る前に出力しはじめて、
gsからのバッファがあふれて入力を止めてしまうってことがあるだろうか。
内部でレンダリングが完了しないと、BMPの出力なんて始められないと思うんだけど。
まあでも、そういう可能性も考慮してLO作れって話ではある。

**名無しさん＠お腹いっぱい。** · 2014/08/01(金) 12:53:12.30

>>146
> source を見ると、RenderAsBMPThroughGS() と RenderAsBMPThroughConvert()
> のどちらかを実行するようになっているので、Convert の方が実行されたのでしょうか？

なんでそうなんだよ

**104** · 2014/08/01(金) 12:59:01.24

>>148
間違えました。
gs -> 144 script -> gsc にしたので、ThroughGS() の方でした。

**名無しさん＠お腹いっぱい。** · 2014/08/01(金) 13:03:16.65

>>147
PostScriptインタプリタは普通に作れば、入力が全部来てから処理を始めるなんていう
間抜けな構成にはならない。
届いたところまで評価して出力する構成になるのが普通。

**名無しさん＠お腹いっぱい。** · 2014/08/01(金) 13:20:10.05

>>150
そうなの？
最後まで各ピクセル値が確定しないように思うんだけど。
最後の最後に、あ、この線も追加で引いてなんてコード書けるでしょ。

**名無しさん＠お腹いっぱい。** · 2014/08/01(金) 15:53:31.50

実はまだフリーズの再現できてないんだよね。
VirtualBoxに10.0入れてやってみたら、図が表示されないけど、フリーズしない。
9.2を9.3に上げてLOもGSも入れ直してみたら、フリーズしない。
どっちも64ビット。

**名無しさん＠お腹いっぱい。** · 2014/08/01(金) 15:55:52.00

>>144
ぐっじょぶ！

>>150
詰まったパイプが出力段か入力段が分からんとなんとも言えん気もするが…
処理は開始できるけど、出力の頭辺りが確定しないと出力を始められないよ。
>>151
PSだとshowpageとかでページ確定してしまえばそのページは出力できるけど、EPSではどうなるやら

**名無しさん＠お腹いっぱい。** · 2014/08/01(金) 16:39:30.46

俺の環境では、たとえば、こんな lotest.sh スクリプトを作って、

#!/bin/sh
(cat; echo done >&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 へのリンクね。

**名無しさん＠お腹いっぱい。** · 2014/08/01(金) 16:40:39.41

ちなみに & は半角の＆

**名無しさん＠お腹いっぱい。** · 2014/08/01(金) 16:41:49.20

あれ、& は半角の＆

**名無しさん＠お腹いっぱい。** · 2014/08/01(金) 16:46:18.21

ja-ibus-anthy-1.2.7_4がダウングレード扱いｗ

**104** · 2014/08/01(金) 16:56:01.15

>>154
もとの gs に戻して、LO がフリーズする様に戻してから、やってみました。

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

と表示され、１０秒後に終わって、bmp 1.5MB ができました。
できた bmp を表示してみると、サイズが大きくなっている以外は正常でした。

**名無しさん＠お腹いっぱい。** · 2014/08/01(金) 16:57:46.14

>>158
>>156

**104** · 2014/08/01(金) 16:58:45.27

ちなみに、私の所は 9.3R amd64 で gs は pkg で入った以下です。

ghostscript9-9.06_7
Name : ghostscript9
Version : 9.06_7

**104** · 2014/08/01(金) 17:05:07.90

>>159
失礼しました。
半角& に変えてから実行すると、直ぐに done で 10秒後に bmp ができました。

**名無しさん＠お腹いっぱい。** · 2014/08/01(金) 18:05:13.38

再現しないってことはgsの動作モードが違うのか、
シェルを介する何処かでパイプの挙動が違うのかな。
catが組み込みで動いたりパイプに対する対処がされてたり…

**名無しさん＠お腹いっぱい。** · 2014/08/01(金) 19:17:20.64

あとできるのはgscをktrace下で呼び出すくらいか。

フリーズする環境とバグ探し能力の両方を持った人、協力よろ。

**名無しさん＠お腹いっぱい。** · 2014/08/01(金) 22:00:10.59

>>154
なるほど。
たしかにLOでepsを開くとそのオプションでgs(gsc)が呼び出されてるわけですね。
私のところはフリーズする環境ですが、シェルスクリプトとして起動すると性状にbmpが作成されて、LOからだとgscのプロセスが残ったままになります。
このgscをkillすると読み込んだepsがLOで表示されるんですよね。

**104** · 2014/08/01(金) 23:14:28.26

>>164 さん、FreeBSD のバージョンや 32bit 64bit は何でしょうか？
どうも、フリーズする環境としない環境があるみたいなので。

**104** · 2014/08/01(金) 23:27:22.78

関係あるか分かりませんが、使っている shell は tcsh です。

**164** · 2014/08/02(土) 11:18:55.68

>>165さん、
私のところはamd64の10-stable p5です。
LibreOfficeは、この話が出てきてからcvsでとってきたportsで入れました。
プラットフォームはESXi 5.5です。

**104** · 2014/08/02(土) 11:31:00.15

>>167
了解です。私の 9.3R amd64 pkg とは amd64 だけ共通ですね。
shell は何でしょうか？私は tcsh です。

**名無しさん＠お腹いっぱい。** · 2014/08/02(土) 11:34:26.73

すげえ、Linuxのpipeって、64kB超えても一気に read(2) できるわ。確認した。

**164** · 2014/08/02(土) 11:37:41.82

>>168
ログインシェルはtcshにしています

**名無しさん＠お腹いっぱい。** · 2014/08/02(土) 12:03:15.56

職場の新しいプロジェクトでC#を使うことになったんだけど、
いざ FreeBSD の pkg を見てみると mono や monodevelop 等の環境が充実していることに驚いた。

**名無しさん＠お腹いっぱい。** · 2014/08/02(土) 16:23:26.66

BSD#プロジェクトってほとんど一人でやってるんだぜ・・・頭下がるわ

**名無しさん＠お腹いっぱい。** · 2014/08/02(土) 16:35:29.21

俺はいつもほとんど一人でしごいてるんだぜ・・・頭がハゲるわ

**104** · 2014/08/02(土) 17:04:28.53

>>170
二人とも tcsh ですね... これが関係しているのですかね？
>>162 さんが shell に触れているので気になりました。

**名無しさん＠お腹いっぱい。** · 2014/08/02(土) 17:34:26.31

#!/bin/sh って書いたスクリプト実行させるのにログインシェルとか関係ないからｗ

**名無しさん＠お腹いっぱい。** · 2014/08/02(土) 18:10:26.08

>>128
へえ、最近はそんなにでかいんだ

**162** · 2014/08/02(土) 18:20:02.16

シェルスクリプト介す場合はシェルを何にしてるかも影響しそうだけど、
シェルスクリプト介さずプロセス作った時のトラブルに影響するのかな？
>>175
#!/bin/shが実際どんなシェルにリンクしてるかは一応環境依存だけど、
そもそもエラー再現するときがgsc直で呼んでる時だからやっぱ関係ない系

**名無しさん＠お腹いっぱい。** · 2014/08/03(日) 09:01:53.51

ざっとソースを読んでみた感じでは、
sal/osl/unx/process.cxx
の中の
osl_executeProcess_WithRedirectedIO　の処理を修正すれば良いんでしょうかね。
ちょっと追っかけてみます。

**名無しさん＠お腹いっぱい。** · 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 とかに行くのですかね...
複雑過ぎです...

**名無しさん＠お腹いっぱい。** · 2014/08/04(月) 21:24:21.44

LOがらみ：
再現性について進展。
pstoeditがインストールされていると、
RenderAsEMF()が成功するのでRenderAsBMP()を呼ばず、フリーズしない。
pstoeditがインストールされていないと、フリーズする。

**名無しさん＠お腹いっぱい。** · 2014/08/05(火) 11:49:53.00

マスターのportがあって、そのスレーブのport個々でPORTREVISIONをバンプした後で
マスターのPORTVERSIONが上がったとき、そのバンプを元に戻すのは
やっぱ忘れやすいよなｗ

**名無しさん＠お腹いっぱい。** · 2014/08/05(火) 12:14:30.80

>>180
お疲れさまです。
なるほど。FreeBSDでもフリーズする人しない人が居る理由が判りました。
判ってよかったです。

**名無しさん＠お腹いっぱい。** · 2014/08/05(火) 16:36:43.00

>>180
RenderAsEMF も osl_executeProcess_WithRedirectedIO を使っているんですね。
このときは FreeBSD でも問題ないのは、gsc の問題を意味するのでしょうか？

>>164 にもあるようにフリーズ中は gsc が残っていて、これを kill するとフリーズは解けるのですが、
画像が正しく表示はされる事はないです。例えば、外枠だけ表示されて中が真っ黒となります。
gsc の処理が途中で止まっている様に見えます。

**名無しさん＠お腹いっぱい。** · 2014/08/05(火) 18:16:19.76

>>183
>このときは FreeBSD でも問題ないのは、gsc の問題を意味するのでしょうか？

いいえ。pstoeditの出力は標準出力ではなく指定したファイルに行うようになっているので該当しません。
どうせ読むならもっと正確にコードを読んで判断してください。

**名無しさん＠お腹いっぱい。** · 2014/08/05(火) 19:03:53.23

で、>>143はどうなった？
pstoedit入れずにLinuxで巨大EPSのテストもな。1MBはいるな。

**143** · 2014/08/05(火) 19:50:25.25

>>184
分かりました。

>>185
linux は手元にないです。Window はテストしました。
440KB の EPS で正常に動作しました。

**名無しさん＠お腹いっぱい。** · 2014/08/05(火) 22:24:50.35

LibreOfficeのバグであることは明白なんだから、いいかげんバグ報告すりゃいいのに。
ここでやるのはもうだいぶスレ違い。

**名無しさん＠お腹いっぱい。** · 2014/08/05(火) 22:31:23.20

わかっている範囲FreeBSDでしか発生していないバグをそのまま報告しても「わからん」
言われて終わる可能性は高いからなあ。スレ違いとまでは言えないと思うが。

SolarisとかでLibreOffice動くんだろうか。わざわざ試す気にはなれないけど。

**名無しさん＠お腹いっぱい。** · 2014/08/06(水) 02:12:13.47

pkgngって欠陥品では・・・

**名無しさん＠お腹いっぱい。** · 2014/08/06(水) 05:59:35.22

>>188
ではFreeBSDのパイプの実装を直すべきって言うかね？

**名無しさん＠お腹いっぱい。** · 2014/08/06(水) 08:05:06.58

本当に実装がまずいならそうするべきだし、あるいはportsにFreeBSD専用のパッチを
入れるか。
どっちにしろ「FreeBSDの話題」だよね?

**104** · 2014/08/06(水) 11:17:26.57

>>189
＞pkgngって欠陥品では・・・

pkgng はまぁ良いとしても、デフォルトで latest なのがマズイと思う。
latest はローリングリリースで数が減ったりするから、タイミングによって欲しいモノがない。
デフォルトはタグの付いたリポにしとくべきだ。
最低でも、そう変更する方法の説明があるべきだけど、それもない。

**名無しさん＠お腹いっぱい。** · 2014/08/06(水) 13:22:33.96

>>191
>本当に実装がまずいならそうするべきだし、あるいはportsにFreeBSD専用のパッチを
>入れるか。
ばーか。お前は今までの話を理解してないんだな。

**名無しさん＠お腹いっぱい。** · 2014/08/06(水) 13:31:10.23

>>191
もう一度問題の原因を読んで考えなおせ

**名無しさん＠お腹いっぱい。** · 2014/08/06(水) 14:58:18.55

なるほど。FreeBSDのパイプの実装がまずいわけですね。

**191** · 2014/08/06(水) 15:45:43.49

>>193,>>194
すまない、確かに自分がわかっていなかったようだ。
「gsに対するパイプへのreadをちゃんとせずにwriteするからお互いにwriteしようと
してデッドロックする」ということであっているだろうか。

これに対する修正なら確かにFreeBSD固有ではないな。ツッコミ感謝。

**名無しさん＠お腹いっぱい。** · 2014/08/06(水) 15:50:41.55

read/writeのデッドロックじゃなくて、
パイプからの1回のreadで全サイズ読めないとエラー扱いにしてしまうソフトの問題かと。

**名無しさん＠お腹いっぱい。** · 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) してる。

**名無しさん＠お腹いっぱい。** · 2014/08/06(水) 17:24:26.66

読まずに書いてしまったが、>>193と>>194はこの現象をどう思う？
>>197はどこからそう判断してるの？

**名無しさん＠お腹いっぱい。** · 2014/08/06(水) 18:28:48.13

いい感じに盛り上がってるね。