impressions のバックアップ(No.85)

impressions

(by K, 2012.09.09)
簡易掲示板です。

自己紹介ページを作っていない人は、NameLinkにチェックを入れないでください。 -- K 2012-09-10 (月) 06:58:43

MacOSX版OSECPUにメモリリークバグを発見しました。osecpu078dのosecpu.cで3311行目に相当するdrawRect関数ですが、colorSpaceとimageが解放されていません。CFReleaseでそれぞれの変数を解放する必要があると思います。 -- hikarupsp 2014-03-11 (火) 22:02:29
わおー。Livaさんに聞いてみますね。＞メモリリークバグ -- K 2014-03-14 (金) 16:18:03
hikarupspさん、バグ報告ありがとうございます。仰る通りcolorSpaceとimageでメモリリークバグが発生していますね。実はお恥ずかしい話、Macアプリの開発の経験不足より、contextの解放についてよく分かっておらず、（今でも分かってないのですが）contextを解放した時にプログラムが落ちるという挙動を見て、colorSpaceとimageも下手に解放してしまうのが怖かったため、解放せずに放置したと記憶しています。先ほど試した所、この２変数については解放できると分かったので、次のosecpuの更新でbug fixが為されるかと思います。今後ともバグを発見され次第、このwikiで報告をして頂けると非常に助かります。これからもよろしくお願いします。 -- Liva 2014-03-15 (土) 00:53:31
対応ありがとうございます。自分もこのバグを自力で発見したというよりは、XCodeのAnalyze機能で何度も同じようなバグを指摘されたために、すぐに思い至ったのです。もしXCodeをお使いでしたら、Product>Analyzeで、メモリリークの可能性のあるコードを検出できるので、活用してみるのもいいかもしれません。最近のコンパイラはすごいですよね（笑）。 -- hikarupsp 2014-03-15 (土) 13:32:45
hikarupspさんのUTF-8型のポインタっていうのは、実はSINT32でもできる。ファイルから読んだり書いたりするときにコンバートすればいいと思う。で、そういうコンバートは確かにシステムでやってくれたらいいのになとは思う。 -- K 2014-03-26 (水) 22:04:52
UUIDの利用支援も面白そうなアイデア。UUIDは128ビットなので、UINT128型を扱えれば、それで問題は一応解決する。OSECPUの先にある第三世代OSASKでは、レジスタ幅は最大256ビットになるので、128ビットくらいは余裕で扱える。・・・でもOSECPUとしては32ビットが上限なので、支援するにはAPIかなあ。 -- K 2014-03-26 (水) 22:08:57
Ubuntu13.10(32bit) などでも osecpu078d を動くように修正するパッチです。GCC4.8.x 以降で ++ のルールが変わったことが原因だったようです。 https://gist.github.com/takeutch-kemeco/9846313 -- けめっぽ 2014-03-29 (土) 20:40:41
Linux(32bit) での非X11環境（起動直後またはCtrl+Alt+F1〜7などで行けるDOSのような黒い画面）でも osecpu078d でテトリス遊べるようにするドライバーです（と、それをosecpu078d/osecpu.c に組み込んだ場合のサンプルも）。32bitリトルエンディアンのグラフィックボードのみ対応してます（Intel G31 オンボードグラフィックで動作テストしてます） https://gist.github.com/takeutch-kemeco/9703915 -- けめっぽ 2014-03-29 (土) 20:56:57
osecpu077dをクラッシュさせるバグ(脆弱性？)を見つけました。テストしてませんがおそらくosecpu078dも同様でしょう。
```
#include "osecpu_ask.h"
DB(0x03,0x81-0x40); DDBE(0);
junkApi_fopenRead(R00, P01, 1);
```
関数jitCompilerでPLIMMをコンパイルする際にレジスタの番号をチェックしていないため、構造体Regsのポインタレジスタより高位のメモリ領域を破壊できてしまうことが原因だと思われます。 -- yao 2014-03-31 (月) 14:01:15
これはひどい！教えてくださりありがとうございます。 -- K 2014-04-01 (火) 18:09:21
けめっぽさん、GCC4.8.x以降での問題を突き止めてくださりありがとうございます。そして、マニアックなドライバもありがとうございます！ -- K 2014-04-01 (火) 18:20:59
osecpu077dで任意のx86コードを実行させる脆弱性を見つけました。 https://gist.github.com/yuta-aoyagi/9935015 -- yao 2014-04-02 (水) 23:20:24
free周りの手抜きを狙われてしまった！！・・・ご指摘ありがとうございます。 -- K 2014-04-04 (金) 18:16:21
えっと,FrontPageがスパムを受けていたので回復しました。必要ないと思いますが、書いてあった文を載せます -- MANA 2014-05-26 (月) 05:39:01
スパムとされてしまい、投稿できませんでした。(当たり前か)。バックアップページ：http://osecpu.osask.jp/wiki/?cmd=backup&action=source&page=FrontPage&age=61 -- MANA 2014-05-26 (月) 05:44:19
MANAさんありがとうございます！ -- K 2014-05-26 (月) 07:50:16
FrontPageが書き換えられていました。緊急な対処が必要だと思ったので、勝手ながら最後のバックアップからコピーandペーストして”復旧”させていただきました。一応表示は戻りましたが、履歴から復元するやり方が間違っていたら申し訳ありません。確認していただけたらありがたいです。 -- ttwilb 2014-05-26 (月) 23:34:42
さらに数時間でまた書き換えられたようです。ttwilbさんと同じ方法で復元しました。 -- MANA 2014-05-27 (火) 04:34:52
さらに数分で書き換えられました。またも同じ方法で復元しました。 -- MANA 2014-05-27 (火) 04:43:46
戻し方は問題ありません。ありがとうございます。攻撃が激しいようなので、ページを凍結しました。 -- K 2014-05-27 (火) 07:09:25
このたびサーバーを作りまして、いろいろ作りました。それで、OSECPUの勉強を兼ねて、「30日でできるOS自作入門」みたいに、「初心者でもわかるOSECPU入門」というサイトを作りたいのですが、作ってよいでしょうか。 -- MANA 2014-05-31 (土) 11:58:08
もちろんいいですよ。＞MANAさん -- K 2014-06-01 (日) 09:43:03
ありがとうございます。Media Wikiで作成します。 -- MANA 2014-06-01 (日) 11:29:42
ところで、OSECPUのロゴ(カオスちゃんみたいな)はないのですか。 -- MANA 2014-06-01 (日) 13:14:19
やっぱり第三世代OSASKになる、ということでカオちゃんなのでしょうかね。あと109aのinteger.c:326 で初期化していない変数bitを使っているようですが...。 -- ttwilb 2014-06-01 (日) 18:00:36
うーん。kさんはどう思われますか。 -- MANA 2014-06-01 (日) 20:29:38
そうですね。そもそもOSECPU-VMプロジェクトはOSASK計画の一部なのです。ということで、ttwilbさんの予想は正しいです。 -- K 2014-06-02 (月) 11:25:30
初期化していない変数「bit」の件、発見ありがとうございます！ -- K 2014-06-02 (月) 11:27:51
では、「初心者でもわかるOSECPU入門」のロゴにhrb.osask.jp/wiki/hrblogo1.gifを使ってよろしいでしょうか。 -- MANA 2014-06-02 (月) 19:49:56
hideyoshiさんのサイトにもいっぱいありますよ！でもライセンスは分かりません。ごめんなさい。(追記: 大変ありがたいことに、このサイトの素材は自由に使ってよいようです。) -- ttwilb 2014-06-02 (月) 22:28:22
ttwilbさん、ありがとうございます。開設しました。http://mnas.0am.jp/osecpu/です。アクセスできたら、そこに何かページを作ってもらえませんか。まだ外部からアクセスしたことがないので。あとOSWiki も作りました。http://mnas.0am.jp/oswikiです。どちらもゆっくり書いていきます。 -- MANA 2014-06-03 (火) 07:59:13
MANAさんのサーバーにはつなげないっぽいですよ。そちらの環境からドメインが通っているか確認してみてください。 -- ttwilb 2014-06-03 (火) 22:45:42
ドメインは通っているけど、osecpu及びoswikiサブディレクトリにはつなげません。ディレクトリやファイルのオーナーやパーミッションを確認してください。 -- ttwilb 2014-06-03 (火) 22:52:43
ドメインに関連づけられているipアドレスがローカルアドレスみたいですよ(192.168.11.8)。だから外部からは接続できないのだと思います。ドメインに設定するアドレスはグローバルipアドレスでなければ、外から接続できません。グローバルipアドレスは取得されましたか？>MANAさん -- hikarupsp 2014-06-03 (火) 23:16:16
あと、小さいことですが、execStep_checkBitsRange()内で、prefix[0]がセットされている時はレジスタ値(といってもプログラムから見えない部分だと思いますが)をセットしているので、checkという名前にはすこし違和感があります。(ちなみにairJOsecpu Rev.2ではarrangeRegisterUpperBitsという名前にしています) -- ttwilb 2014-06-03 (火) 23:25:30
hikarupspさんの続きですが、ここのページの「あなたのIPアドレス」に表示されているIPをMyDNSのIPアドレス指定ボックスに入力してくださいね。 -- ttwilb 2014-06-03 (火) 23:27:17
質問ばかりで申し訳ないですが、VisualStudio君によればosecpu108aではRxxにBIT_DISABLE_REGを設定しているコードはないそうです。しかしinteger.cのいたるところで、Rxxがこの定数でないことを確認するIF文が見られます。では、この定数には一体どんな役割があるのでしょうか。 -- ttwilb 2014-06-03 (火) 23:59:59
Wikiがメインページへ転送させる際、ローカルアドレスで指定したようです。…うぅ設定中にOSが壊れちゃいました。復旧に時間がかかります。 -- MANA 2014-06-04 (水) 07:32:05
>checkという名前にはすこし違和感があります。・・・なるほど、それは一理あります。まあprefix[0]による修飾はかなり「まれ」なので、ほとんどの場合は名前のとおりcheckなのです。だから関数名はそのままにしますが、コメントは入れておくことにします。正しい名前はcheck-or-fixくらいでしょうかねえ・・・。 -- K 2014-06-04 (水) 08:31:03
BIT_DISABLE_REGについて。ご指摘のとおり、今のVMではRxxのbitがBIT_DISABLE_REGになることはありません。ではこれがセットされるのはどういう状態かというと、高速モードなどの「bitを持たないVM」が実行していた状態をいったん停止して、bitなどのフィールドを付与して安全モードで再開した直後の場合のみに生じる状態です。もともとフィールドがなかったので値が分かりません。仕方ないのでBIT_DISABLE_REGにすることになっています。 -- K 2014-06-04 (水) 08:59:23
今更命令セットについて一つ考えたのですが、DATA命令はこれまでラベルの直後にしか出現しない命令だったと思います。なので、DATA命令のオペランドに、直前のLB命令にあたるフィールドを入れれば、わずかではありますがアプリサイズを削減できると思います。 -- hikarupsp 2014-06-04 (水) 20:06:51
つまり、今までLB+DATAでセットだったのを、DATA命令のみで完結できるようにしたらどうか、ということです…。 -- hikarupsp 2014-06-04 (水) 20:08:13
なるほど、そういうことでしたか。bitが無い環境のことも考えられているのですね。そうすると、bitが無い環境だと、prefix2f[0]が立っている時に違う動作をしてしまうということで、VMを作る側もプログラムを書く側も気を付けた方がよいですね。 -- ttwilb 2014-06-04 (水) 23:02:50
>bitが無い環境だと、prefix2f[0]が立っている時に違う動作をしてしまうということで、VMを作る側もプログラムを書く側も気を付けた方がよいですね。・・・この部分についてもう少し理解してもらえるように説明します。 -- K 2014-06-05 (木) 06:14:03
- 2F-0プリフィクスがあると、安全モード・高速モードで結果が変わるのではないか？・・・これはYesです。しかしNoでもあります。
- 高速モードでは、bit[]がなく、したがってレンジチェックもされず、レジスタの上位ビットにゴミが混ざっていても放置されます。高速モードでは2F-0プリフィクスがあっても無視されて値の補正はありません。ゴミがあっても問題ないからです。
- 安全モード時に上位ビットのゴミを常に取り除いてきれいにしておくのは、レンジチェックのためだけなのです。
- 上位ビットのゴミを明示的に取り除くためには、SBXという命令を実行します。いつでもこれでゴミのない結果に修正できます。これは安全モードでも高速モードでもどちらでも確実に動作します。
- ということで2F-0プリフィクスがあってもなくても、ゴミ部分以外の意味を持つビットだけに注目すれば結果は変わっていないはずです。しかしゴミ部分については結果は変わっているでしょう。先のYes・Noはそういう意味です。
- 2F-0プリフィクスの意味：この演算結果は一時的にどうしても上位ビットにゴミを生じてしまうので、たとえ安全モードであってもレンジチェックをするな、プログラマはわかってやっているのであって、ミスではないぞ。
```
たとえばこんな状況：
R00に0x12、R01に0x34が入っている。R00とR01はどちらもbit=32。これらを足し合わせて、下位4ビットだけがほしい。
これには2つの書き方がある。
(1) ADD(32, R02, R00, R01); LIMM(4, R3F, 0x0f); AND(4, R02, R02, R3F);
(2) PREFIX_2F(0); ADD(4, R02, R00, R01); LIMM(4, R3F, 0x0f); AND(4, R02, R02, R3F);
1のやり方はプレフィクスがいらないけど、ADDは32ビットで演算している。これは必要のない精度の計算だといえる。
無駄な書き方を「強要」しなければいけないとしたら、それは本当に「いい仕様」といえるだろうか？
それに対して2は不要な演算は全くない。
```
復旧が終わると同時にWikiの方もなおりました。Wikiの感想ページに何か書き込んでもらえませんか。 -- MANA 2014-06-05 (木) 18:57:26
http://mnas.0am.jp/osecpu/ とhttp://mnas.0am.jp/oswiki -- MANA 2014-06-05 (木) 18:58:42
ttwilbさん、ありがとうございます。 -- MANA 2014-06-06 (金) 05:53:14
なるほど、ということはVM側のbit[]は、オーバーフローのチェックと各オペレーションの引数bitのチェックをするためのもので、それが必要ない(エラーのない)コードであればVM側にbit[]が無くても正しく処理できる、ということですね。そう考えるといろいろな仕様がつながってくるように感じます。ありがとうございます。 -- ttwilb 2014-06-06 (金) 11:59:53
osecpu本体のみですが、MacOSXで動作するようにいくつか変更を加えてみました。主な変更部分はdriver.cのmain関数です。それと、これをコンパイルするために必要なMakefileもつけました。
- https://sourceforge.jp/users/hikarupsp/pf/OSECPU_VM_2/scm/blobs/mod_for_mac_110d/vm/driver.c
- https://sourceforge.jp/users/hikarupsp/pf/OSECPU_VM_2/scm/blobs/mod_for_mac_110d/vm/Makefile -- hikarupsp 2014-06-12 (木) 23:10:32
どうやらdriver.cを修正しなくてもMakefileの変更だけでうまく動くのですが、XCode経由でビルドしたときにウィンドウが出ない症状を直すためには、上記のdriver.c:main()の修正が必要みたいです。 -- hikarupsp 2014-06-12 (木) 23:17:21
hikarupspさんへ。どうもありがとうございます。そのドライバを採用させていただきます！ -- K 2014-06-13 (金) 09:28:11
ttwilbさんへ。bit[]について分かっていただけたようでうれしいです！ -- K 2014-06-13 (金) 09:32:57
hikarupspさんへ。LB+DATAの提案の件です。まずサイズ重視のフロントエンドコードでは、rev1の時点ですでにhikarupspさんの提案のようになっています。しかしシンプルさ重視のバックエンドではrev2でもDATA命令にLBの機能を含ませていません。これがいいかどうかは確かに疑問もあるのですが、とりあえずこのまましばらくはやってみたいと思います。 -- K 2014-06-13 (金) 09:41:54
beginFunc()とendFunc()で何をやっているのか教えてください。 -- ttwilb 2014-06-22 (日) 09:57:18
ざっとソース読んだ感じではrev2ではまだ関数には対応できていないようです。今あるbeginFuncとendFuncはrev1からのコピペでしょう。以下rev1時代の話です。beginFuncは(1)関数先頭のラベルを定義し(2)関数ローカルのレジスタ(R00からR1Fまで・P00からP1Fまで・P30)を保存します。endFuncは(1)先に保存したレジスタを復帰し(2)P30へジャンプして呼び出し元へ返ります。 -- yao 2014-06-22 (日) 15:37:13
なるほど、ありがとうございます。beginFunc()の定義中でのDBで置いている値が明らかにhh4でなかったので疑問に思っていました。確かにrev.1のバイトコード仕様を見てみると、下の方に小さく、レジスタのスタック待避のことが書いてありますね！（しかもASKA専用の命令！）これと同じことをrev.2で実現しようとした場合は、やっぱりスタックに相当するものを自力で実装する必要が有るのでしょうか、、、。 -- ttwilb 2014-06-22 (日) 15:54:28
でも、まだmallocもtallocも実装されていませんよね。ということは待つしかない!? -- ttwilb 2014-06-22 (日) 16:46:44
rev1時代は3C/3D命令で、VMが管理するスタックにレジスタを退避・復帰させていました。rev2にはまだこのようなスタックが用意されていないので、文字通りに「同じことをrev.2で実現」は原理的に不可能です。(malloc/tallocがなくてもdata命令でメモリを確保できるので)整数レジスタ用のスタックを自力で実装することはなんとか可能です。しかし、PSMEM/PLMEM命令がまだ実装されていないのでポインタレジスタのスタックを作るのは不可能に近く思えます。これは関数呼び出しのネストが難しいことを意味します(呼び出し規約に細工をすれば不可能ではないでしょうが)。これらの命令もそう遠からず実装されるでしょうからそれまで待つか、待ちきれないなら自分で実装するのがいいでしょうね。 -- yao 2014-06-22 (日) 16:57:14
レジスター全部をスタックへ退避・復帰するような命令(TASKSAVE, TASKLOAD のような)をユーザーレベルでも使える形で公開しておいて、もしユーザーが関数ネスト的な動作をさせたい場合はユーザー自身がそれを使って自前でやってね的な形でもいいような気もします。ラベルジャンプの自由度が高いので関数ネストのサポートって大変そうな気がしますし。 -- けめっぽ 2014-06-22 (日) 18:47:10
そうなんです、現在実装中なのです。もうちょっと待っていてください！ -- K 2014-06-23 (月) 07:28:48
了解です。レジスタを全部コピーする処理を書くと、コードのサイズを消費するのでやっぱりTASKSAVEというか、PUSHAD的な機能がほしいですね。でも不要なレジスタまでコピーすると無駄なような気もする（本来ならば関数内で使われているレジスタだけ待避すればいいから）ので、ちょっと複雑な心境です。ところで、実装までもうしばらくかかるということであれば、先にmallocやtallocの詳しい仕様を教えて頂ければ助かります。>Kさん -- ttwilb 2014-06-23 (月) 08:49:55
enter/leave命令は、保存する範囲を指定するようになります。詳しくはpage0092に書きます。 -- K 2014-06-23 (月) 11:02:37
なるほど、ENTER命令がまさにレジスタをスタックに積む役割を担うのですね。となるとmalloc/tallocはosecpu113dよりも後になるのでしょうか。ENTER/LEAVEやMALLOC/TALLOCのオペコード仕様も、確定したら教えてください！ -- ttwilb 2014-06-23 (月) 21:00:53
malloc/tallocはosecpu114dくらいの予定です。これらがないと文字列関係のAPIが使えないので。 -- K 2014-06-23 (月) 21:21:42
先日「整数レジスタ用のスタックを自力で実装することはなんとか可能」と書きましたが、SMEM命令がまだ実装されていないので現在のVMでは不可能でした。LMEMがあるならSMEMもあるだろうと考えて見落としていました。計算理論の用語を使うと「有限オートマトンは実装できるがプッシュダウンオートマトンは実装できるとは限らない」と言えます。つまり、現在のVMでは計算できない処理が存在するということです。 -- yao 2014-06-24 (火) 23:04:29
ドキュメントには書いてないですが、osecou112dにはSMEM命令があります！（でもまだテストしてないですが）。まあなんにせよ、enter/leave, malloc/mfree, talloc/tfree, plmem/psmemは追加していきますので（つまりrev2で命令をなくすわけじゃない）、どうぞご安心を。 -- K 2014-06-25 (水) 05:19:20
SPAMっぽいので nrfawa というページを削除しました。 -- K 2014-06-26 (木) 14:59:58
http://mnas.0am.jp/console.html で、一応 osecpuコマンドをつけてみました。今はOSECPUのシグネチャを判別するだけですが、命令を実行できるようにがんばります。 -- MANA 2014-07-06 (日) 10:20:34
すみません。本題に入る前にEnterを押してしまいました。アプリ用途.oseはシグネチャが3バイトで、05,E2,00なはずなのですがapp****_.oseは05,E2の2バイトになっています。OSECPU（アプリ用途）の正式なシグネチャは05,E2,00の三バイトで正解ですか？ -- MANA 2014-07-06 (日) 10:53:58
3バイト目が00かそうでないかで、「バックエンド形式」なのか「フロントエンド形式」なのかを判定しています。つまり、どちらも「正式な」「アプリの」シグネチャです。 -- K 2014-07-06 (日) 11:43:17
しかしバックエンドしか当面はサポートしない、というのは十分に許されるので、00以外を受け付けないというのはありです。だたそれを「正式ではない」とは言わないでほしいです。 -- K 2014-07-06 (日) 11:45:51
なるほど、そういう仕組みでしたか。バックエンド方式を採用します。 -- MANA 2014-07-06 (日) 18:16:44
osecpu117dのother.cでapiGetRxx()を使っているけど、osecpu-vm.hでもother.cでもプロトタイプ宣言をしていないので、名前解決ができないようです。other.cの中でプロトタイプ宣言すべきだと思います。また、decode.cでtek.cをインクルードしていますが、これがあるとVisual Studioでは、tek_lzrestore_tek5が二重に宣言されるとエラーがでます。VisualStudioでコンパイルしたい人のために修正方法をまとめておきます。
```
// この変更はosecpu117d専用です。

// other.c 121行目付近
fin:
	if (retcode == -1)
		retcode = 0;
fin1:
	return retcode;
}
Int32 apiGetRxx(OsecpuVm *vm, int r, int bit);    // ←この一行を追加
int jitcAfterStepOther(OsecpuJitc *jitc)
{
	int i, retcode = 0;
	if (jitc->hh4Buffer[0] != 0x2f) {

// decode.c 1行目付近
#include "osecpu-vm.h"

// #include "tek.c"   //←この一行をコメントアウト
typedef unsigned char UCHAR;
typedef unsigned int UINT32;
typedef UINT32 tek_TPRB;
int tek_lzrestore_tek5(int srcsiz, UCHAR *src, int outsiz, UCHAR *outbuf);
// ↑この4行を追加
```
以上の修正をすれば、通常版osecpu-vmをVisualStudioでもコンパイルできます。 -- ttwilb 2014-07-06 (日) 19:38:40
XCodeでもほぼ同等のエラー(tek_lzrestore_tek5が二重に宣言)が出るので、私からもttwilbさんの意見を支持します。tek.cをインクルードするのではなく、tek.hを作成するのが良いと思います。 -- hikarupsp 2014-07-06 (日) 20:54:51
HeavyOSECPUではtek.hにtek.cのプロトタイプ宣言をまとめているので、参考にしていただくと良いと思います。http://sourceforge.jp/projects/heavyosecpu/scm/git/HeavyOSECPU/blobs/master/tek.h -- hikarupsp 2014-07-06 (日) 20:57:03
らしいです。まあ、tek関係はdecorder.c内でしか使わない設計だと思うので、osecpu-vm.hとは別にヘッダを作るか、またはdecode.c内にプロトタイプ宣言するかですね。(tek.cをtek.hにリネームするという裏ワザもあり!?) -- ttwilb 2014-07-06 (日) 21:55:01
あと、ttwilb#ASKAで文字列を配置した例にも書きましたが、ASKAで文字列を配置したときに LBした後で文字列データをベタにおかず、一文字ずつtallocしてsmemしているのはなぜなのでしょうか。 -- ttwilb 2014-07-06 (日) 21:57:01
あと、DB("hello, world")する前にREM38()する時点でなぜ文字列長 0x0C が分かっているのかも教えてください。 -- ttwilb 2014-07-06 (日) 21:59:06
other.cとtek.cの件については、osecpu118dで対処します。 -- K 2014-07-07 (月) 15:23:55
OS Wiki が大々的に攻撃を受けていたので,修復しました。あれ…OSECPUも受けている -- MANA 2014-07-25 (金) 10:18:17
OSECPUも直しました -- MANA 2014-07-25 (金) 10:22:56
os-wikiの荒しの対処はどうしたらいいですか？直していいですか？>K -- skyblue 2014-09-01 (月) 14:30:26
zakkyさんに頼めば、凍結などの処置をしてくれると思います。・・・それとも、もうzakkyさんの負担も相当なものだと思うので、osask.jpドメインでミラーwikiを作ったほうがいいかなあ。 -- K 2014-09-01 (月) 17:48:42
1ヶ月以上対処している様子がないので他の人に頼むなりしたほうがいいと思います。それと、複数の人に管理を頼んだ方がいいと思いますので考慮をお願いします。>K -- skyblue 2014-09-02 (火) 18:03:46
skyblueさんへ：この件は、以後 http://oswiki.osask.jp/?administration にてお願いします。 -- K 2014-09-04 (木) 11:42:04
SPAMが作成したと思われるいくつかのページを削除しました。 -- hikarupsp 2015-03-16 (月) 23:16:42
どうもありがとうございます！ -- K 2015-03-17 (火) 10:25:14
SPAMが作成したと思われるページを削除しました…きりがない…。 -- hikarupsp 2015-03-23 (月) 08:48:43
これまでスパムによって作成されたページのタイトルには毎回半角スペースが含まれているようです。
pukiwikiのplugin/edit.inc.phpの238行目に以下の一行を追加すると、名前に半角スペースを含むファイルの作成や編集を阻止することができます。
```
  if(preg_match('/\s/', $page)) exit; 
```
もしかするとスパムアクセスに効果があるかもしれません。 -- ttwilb 2015-03-28 (土) 09:48:57
SPAMが作成したと思われるページを削除しました。ttwilbさんの提案などのように、なんらかの対策を講じたほうが良いと思います。 -- hikarupsp 2015-03-29 (日) 09:47:15
私と同じことを考えていますね・・・。＞毎回半角スペースが含まれているようです。 -- K 2015-03-30 (月) 15:35:35
時間ができたら対処したいです。 -- K 2015-03-30 (月) 15:35:58
SPAMページ削除ありがとうございます！ -- K 2015-03-30 (月) 15:36:20
ttwilbさんの提案パッチを入れてみました！ -- K 2015-03-31 (火) 11:16:08

コメント	お名前	NameLink