トップページ⇒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/
0060名無しさん＠お腹いっぱい。2014/07/23(水) 22:50:45.50
わしもBochsで「うひょーーー遅えｗｗｗｗ」する一択だと思う
0061542014/07/24(木) 07:24:21.77
>>58
ええ、それが正しく開けた状態です。
なるほど。もしパッチで修正されたのなら希望が持てます。
フリーズせずに表示されない場合は gs が入ってない場合と思います。

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

自分で原因を突き止めて直したいと思うのですが、フリーズは場所の特定が難しく挫折しました。
クラッシュならコアを調べる等あるのですが、フリーズはどうして良いものか....
gdb の attach も場所の特定には至らない様ですし...
0062名無しさん＠お腹いっぱい。2014/07/24(木) 07:49:55.38
よく分からんけどドキュメントを部分ごとに分割して、
どの部分の表示でフリーズするとか絞り込んだり
できないかな
0063名無しさん＠お腹いっぱい。2014/07/24(木) 07:54:46.14
ああ、>>62の分割ってのは、編集できる環境で編集して。
Debian Jessieで正しく表示されるなら、LMDE(Linux Mint Debian Edition)や
Mint17やUbuntu14.04などのLiveDVDに入ってるLibreで編集できるかも知れん。
0064542014/07/24(木) 08:43:18.72
>>63
そう言う意味では切り分けはできています。
EPS file が貼られたファイルでフリーズが起こります。
FreeBSD の gs に問題があるのですかね？
でも、問題起こす EPS file も gv では問題なく表示されます。うーむ。
0065名無しさん＠お腹いっぱい。2014/07/24(木) 10:03:56.54
>>61
コアがあればいいだけならシグナル送ってコアを吐かせればいい。
attachするのと変わらないと思うけど。

gdbでまともに見るには全部 -g つけるとか。WITH_DEBUGとか効くかな？
0066名無しさん＠お腹いっぱい。2014/07/24(木) 10:16:14.43
ktrace/kdumpで何をwait4しようとしてるのか見てみるのが良さそう。
0067名無しさん＠お腹いっぱい。2014/07/24(木) 10:43:21.53
>>66
スレッドまわりかなと思ってたが、waitと特定できてるの？
まあktraceしておくのは有効だよね。
0068名無しさん＠お腹いっぱい。2014/07/24(木) 11:07:09.15
pkg1.3の新機能でSATソルバ搭載とか書いてるけど、何にSATがいるの？
0069名無しさん＠お腹いっぱい。2014/07/24(木) 14:24:05.17
この時期脇汗が多い奴ってwait4を使ってるよなｗ
0070名無しさん＠お腹いっぱい。2014/07/24(木) 15:10:41.98
>>67
http://peace.2ch.net/test/read.cgi/unix/1390323139/974
彼はlibcが悪いの？とかトンチンカンな事言ってたが、
コレ見る分にはwait4で止まってたということらしい。
0071名無しさん＠お腹いっぱい。2014/07/24(木) 15:13:41.00
正常動作中のソフトだって平常時にダンプするとwait4で止まってるのが観測できるぞ。
0072名無しさん＠お腹いっぱい。2014/07/24(木) 15:22:55.13
この人がこのスレッドが主犯だと判断した理由が分からんとなんともだけど、
コールスタック見ると長く待つ為のwait4が入る場所ではなさ気だから怪しくはある。
0073名無しさん＠お腹いっぱい。2014/07/24(木) 15:51:31.32
誤報SIGCHLDが飛んでwait4()で待ちぼうけというのが一般的にはある。
0074名無しさん＠お腹いっぱい。2014/07/24(木) 22:22:09.32
>>73
誤報っつーか、それアプリケーション側のバグでしょｗ
SIGCHLDが飛ぶ機会が終了以外にもあるとか、シグナルの非同期性を理解してないコーディングになってたりとか。
0075名無しさん＠お腹いっぱい。2014/07/25(金) 00:07:52.53
>>59
デフォルトになったというか、tetexがバンバン消されていっているようなんですが、
これってちょっと変化が急激すぎやしませんかね？
今後、日本語tex環境を入れようとしたら、これっていうメタポートはあるんだろうか
0076名無しさん＠お腹いっぱい。2014/07/25(金) 00:24:03.36
>>75
俺はもっとやれ派
0077名無しさん＠お腹いっぱい。2014/07/25(金) 00:55:02.51
なんでここってゲーム＝紙芝居なの？
マリオ動かしたり飛行機操作する方が楽しいのに
0078名無しさん＠お腹いっぱい。2014/07/25(金) 00:56:32.22
見なかったことにしてください
0079名無しさん＠お腹いっぱい。2014/07/25(金) 08:06:30.74
>>75
個人的には
print/texlive-full
を使っているが
いらない機能までインストールしすぎ
という悪寒もある
0080542014/07/25(金) 13:28:10.25
>>66
ktrace しながらフリーズさせてキルして見ました。

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

何か分かるでしょうか？
0081名無しさん＠お腹いっぱい。2014/07/25(金) 15:50:53.19
portmasgerの……というか、pkgを更新したらこうなったのだけど、
REPLACE_ORIGINが効かなくなってない?
0082名無しさん＠お腹いっぱい。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
0083名無しさん＠お腹いっぱい。2014/07/27(日) 20:06:01.28
>>75
obsolete過ぎて危ないのに、直ぐには消せないからということで
むしろここまですごく時間を掛けてやっと辿りついたっていう印象なんだけどなあ。
0084名無しさん＠お腹いっぱい。2014/07/28(月) 14:56:13.95
ネット未接続の環境でFreeBSDを8.2->10.0に入れなおして三週間、
ようやく満足に動く環境が出来た。
・sysinstallドコー、mount_ntfsドコー
・pkg bootstrapてどうよ
から始まってC++とRubyの開発環境が揃うまで長かった……

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

clangとgccの互換性は高いが混ざると落ちることもあるみたい。
色々勉強になったからよしとしよう
0085名無しさん＠お腹いっぱい。2014/07/28(月) 19:34:51.43
10.0 では DVD から package を入れる事は出来ないと思ったけど。
0086名無しさん＠お腹いっぱい。2014/07/28(月) 19:47:07.42
pkg 1.2.7でオリジナルリポジトリをtbzで作製してうまく動作していたのですが
pkg 1.3.2では pkg repo でtbzを認識してくれません

対処方法はありますでしょうか？
0087名無しさん＠お腹いっぱい。2014/07/28(月) 23:27:13.43
age
0088名無しさん＠お腹いっぱい。2014/07/29(火) 01:08:14.70
どんだけチューニングしてる浦島太郎ですかw
portsが使えるからまだ大丈夫だよ
0089名無しさん＠お腹いっぱい。2014/07/29(火) 13:30:19.38
今北産業

pkg 何かアレなことになってるん?
0090名無しさん＠お腹いっぱい。2014/07/29(火) 19:43:17.01
pcdm を FreeBSD で使っている人は居ませんか？
0091802014/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 "
-----------------------------------------------------------------
0092名無しさん＠お腹いっぱい。2014/07/29(火) 21:49:38.87
>>91
4KBピッタリって辺りからして、4KBずつ書き込むんじゃね？
次の4KBを書き込む為の条件が満たせないと固まるとか。
0093名無しさん＠お腹いっぱい。2014/07/29(火) 21:57:09.64
>>92
なるほど。確かにそうですね。
次を書き込む為の条件を調査してみます。
と言っても、全然あてはないのですが...
0094名無しさん＠お腹いっぱい。2014/07/29(火) 21:58:16.93
ページサイズ単位のI/Oというと、stdio経由でのI/Oをしてるんかね。
0095名無しさん＠お腹いっぱい。2014/07/29(火) 23:52:07.44
入力が4KB溜まるまで待ってるってことはない？
0096名無しさん＠お腹いっぱい。2014/07/30(水) 05:32:01.13
wait4といいwriteといい、そこが原因ではないよ
0097名無しさん＠お腹いっぱい。2014/07/30(水) 06:34:45.00
>>96
特定したならパッチを投げてあげてくれ。
0098名無しさん＠お腹いっぱい。2014/07/30(水) 09:38:00.19
まっさらな状態からpkgでデスクトップ構築する手順って
どっかに買いてないですかね？
Ubuntuと同じデスクトップでいいので
0099.2014/07/30(水) 10:04:14.79
素のFreeBSDでgnome3を導入したこと無いや。
普段はmateかlxdeだし。
0100名無しさん＠お腹いっぱい。2014/07/30(水) 11:17:09.13
>>99
ログインマネージャーは使ってますか?
0101.2014/07/30(水) 12:16:21.61
>>100
gdm使ってます。
無設定ですぐ使えるので。
0102名無しさん＠お腹いっぱい。2014/07/30(水) 13:00:03.13
>>101
gdm 入れると gnome2 がほぼ全部入ってしまうけど気にしない、と言うスタンスでしたっけ。
0103.2014/07/30(水) 13:07:33.12
>>102
そうですね。
HAL周りもなにも弄らなくていいし。
0104802014/07/30(水) 13:18:52.10
>>91 の続きです。

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

>>96
原因は送った先にあると言うことでしょうか？
FreeBSD の ghostscript9 が win や linux のと違う振る舞いをする、とかですか？
0105名無しさん＠お腹いっぱい。2014/07/30(水) 13:19:11.62
>>98
http://www.freebsd.org/doc/ja/books/handbook/x11-wm.html
とか
0106名無しさん＠お腹いっぱい。2014/07/30(水) 13:22:50.59
>>104
サイズを4KBの倍数になるようパディングしたら正常に動作したりして
0107842014/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をインストールできるようになるよ。

正直オススメはしないが。
0108名無しさん＠お腹いっぱい。2014/07/30(水) 19:31:52.29
>>104
以下想像：
パイプかなんかで送っててパイプのバッファサイズが4KBしかない。
そこにwrite一発でファイル全体を送ってしまって、
書けた量を確認せず、waitでそのパイプ先の終了を待っている。
パイプ先は次の4KBが来るのを待っている。
01091042014/07/30(水) 20:56:02.85
>>108
その場合、直すべきは一発でファイル全体を送っているところでしょうか？
LibreOffice の source にバグがある？
0110名無しさん＠お腹いっぱい。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 がないので、これ以上は無理。
0111名無しさん＠お腹いっぱい。2014/07/30(水) 21:19:56.87
話続けるなら名前欄は固定してくれよ。
01121042014/07/31(木) 02:13:19.12
>>111
わかりました。その辺り調べてみます。
ようやく原因が絞れて希望が出てきました。

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

ちなみに、私の今のテスト環境は 9.3R です。
LibreOffice 4.2.5.2 がフリーズするのは 10.0R も 9.3R も同じでした。
0113名無しさん＠お腹いっぱい。2014/07/31(木) 10:11:29.46
>>111
面白そうなんで自分も見てみた。
RenderAsBMPThroughHelper()って、これダメじゃないか？
osl_writeFile()に渡してる引数&nCountでwrite()で書けたバイト数を貰ってくるが、
パイプから読むのは
if (nCount == nBytesRead)
の場合だけじゃん。
nCount != nBytesReadのときは子プロセスの出力読まずに終了待ちしようとするみたいだし。
01141042014/07/31(木) 11:31:27.04
>>113
>面白そうなんで自分も見てみた。

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

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

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

また、修正案はあるでしょうか？
いただければ、反映させて LibreOffice を make して試してみます。
0115名無しさん＠お腹いっぱい。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
0116名無しさん＠お腹いっぱい。2014/07/31(木) 12:02:21.00
PC-BSD は zfs になってしまうからダメでしょう。オススメできない。
0117名無しさん＠お腹いっぱい。2014/07/31(木) 12:19:55.30
>>114
> 修正案はあるでしょうか？
丸投げしすぎ。

どの言語であれ、ブレークポイント掛けてデバッガでトレースしていくか、
printfなりなんなりをつっこんで、ちまちまデバッグしていくのが、発見者の努め。
言語による差異なんてほとんどない。
0118名無しさん＠お腹いっぱい。2014/07/31(木) 12:21:34.53
> その辺り調べてみます。
って、自分では何やったんだよ。
0119名無しさん＠お腹いっぱい。2014/07/31(木) 12:52:06.14
>>116
違う。俺が書いたURLを見てみな。
FreeBSDをインストールしたあとに、PC-BSDやTrueOSにするには、どうしたら良いのかが書いてある。
別にzfsにする必要はない。
0120名無しさん＠お腹いっぱい。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
これだけだと、ビジュアルシェルだけしか入らないような
0121名無しさん＠お腹いっぱい。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とバージョンがバッティングしないはずなので、それでやってみるのはどうでしょう？
0122名無しさん＠お腹いっぱい。2014/07/31(木) 14:01:06.11
>>121
PC-BSDでports, pkgが使えるのですか
それならまずPC-BSDをやってみようかな
0123名無しさん＠お腹いっぱい。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でしたね...
0124名無しさん＠お腹いっぱい。2014/07/31(木) 18:06:09.96
>>114
> また、修正案はあるでしょうか？
> いただければ、反映させて LibreOffice を make して試してみます。

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

それが目に見えて分かるフリーズとかではなく、情報(計算数値など)
が微妙に間違って表示されるようなものだったとしたら、
仕事になんか安心して使えない。
0125名無しさん＠お腹いっぱい。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;
}
0126名無しさん＠お腹いっぱい。2014/07/31(木) 19:44:24.69
Linuxだと、パイプに巨大なwrite()を実行しても1回のwrite()で全部書けてしまうみたいだわ。
パイプサイズ自体は4096byteのはずだけど、syscall内部でうまく計らってるのか？？
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
■ このスレッドは過去ログ倉庫に格納されています