2004年5月19日水曜日

適正・適職診断結果



まわりにつられて・・・


以下、書き直し面倒なので引用(http://www.haken.co.jp/haken/profiling.html



『夢見る』


気質です。


良い精神状態の時


心温かい・思いやりがある・表現力が豊か・独創的


悪い精神状態の時


意気消沈する・自意識過剰・片意地・気まぐれ


性格


豊かな感性を持つ芸術家タイプ。音楽や芸術を愛し、エスプリに富んでいる。深い情愛で他人と接し、心温まる関係をつくることができる。


注意


自分が周囲に理解されないと、自分を悲劇の主人公に仕立てて無気力で退廃的になり、殻に閉じこもってしまう場合もある。


仕事


自分の独創的な探求を支えるために、芸術や言語を手段とする音楽家、小説家、ジャーナリストなどの仕事に向いています。



うーん俺がアーティスト・・・ってのは甚だ疑問だけどそれ以外はあたってるかも





2004年5月18日火曜日

ttsoft32.acmとばしてもーた



いやぁファイルとばしてしましました。windowsのCDからてきとーなinfふぁいるでリカバーこころみてもだめだったし。結局


HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\drivers.desc


HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\Driver32


をてきとーに編集して復活・・・





portaudit



べんりだねぇ・・・portaudit




cvsup ports-supfile
portaudit -F
portaudit | grep "Affected package:" | sed 's/Affected package\: //' | xargs portupgrade -r


だけで、全てのセキュリティに問題を抱えているパッケージを更新してくれる。


すばらしい


あっ、やっぱ-rオプションきけんかも。。。ちゃんと一つひとつ検証したがよさげ


いくつかのパッケージが消えてしまった。どーも-rで依存しているパッケージをupgradeしてる最中にfailした模様。。。ログメッセージをよめばいいのだが。上記のようにしてしまうとログメッセージが大量にながれておっかけるのが大変。やっぱりportupgradeを一回たたいたら終了するまで待ったり待つのがきちっぽい。





ビデオカードandドライバ



いやぁFreeBSD使ってるんだけど、I845GM内蔵のグラフィックからnVidiaのじーふぉーす2 MX400なるものに替えたら早い早い。


モジラの体感速度まで違う。





男脳女脳診断なるものをやってみた



あなたのポイントは 5ポイントです。 (男脳度数:47.5%/女脳度数:52.5%)


だそーな。なんか論理的思考と感情的表現のバランスがとれていて云々と褒めてあるが。。。どんなもんだろ。


よーは野性から遠のいたってことかな。まっどーでもいいんだけど。。。。


チャットでたまに女に間違われるのはこのせいか???





2004年5月13日木曜日

うざーずjp



いやぁ、最近どこのうざーずjp(*-users-jp ML)もグタグダく~だらない釣りの会場になってるのかなぁ・・・。FreeBSD-users-jpもお祭り風味にょ。


http://home.jp.freebsd.org/mail-list/FreeBSD-users-jp/


まぁ、くだらない煽りの殿堂だからねぇ。もしかして2chからの刺客かにょ?





解説しよう!@PHP



http://bugs.php.net/bug.php?id=28374


このパッチについて。FreeBSD(or other unix??)+PostgreSQL+PHPな人でhttpdのCPU負荷が100%近くになってるひとに効くかもしれないパッチれす。


なんだか私が投稿し9分後にCVSにコミットしたのとメールが来たのでたぶん検証もなにもせずにつっこまれてる。ので未だにこいつが本当にhttpdの無限ループの犯人という確証ないんだけど。(ソース追えよ・・・俺)


取り合えず無限ループに陥ってるプロセスをgdbにアタッチしてスタックトレースすると。以下ののような感じ。(アタッチした時の都合でシンボルは自動では解決できなかったので、該当アドレスのバイナリコードとojbdump -s libphp.soを比較して推定したもの)



>|


#0 0x283fb4f3 in ?? xbuf_format_converter()


#1 0x283fc1a5 in ?? vspprintf()


#2 0x283f829b in ?? php_error_cb()


#3 0x284253a6 in ?? zend_error()


#4 0x2841d392 in ?? zend_timeout()


#5 0xbfbfffac in ?? ()//stackでのとらんぽりんこーど(シグナル?)


#6 0x283fc1a5 in ?? vspprintf()


#7 0x283f829b in ?? php_error_cb()


#8 0x284253a6 in ?? zend_error()


#9 0x2841d392 in ?? zend_timeout()


#10 0xbfbfffac in ?? ()//stackでのとらんぽりんこーど(シグナル?)


#11 0x283fc1a5 in ?? vspprintf()


#12 0x283f829b in ?? php_error_cb()


#13 0x284253a6 in ?? zend_error()


#14 0x2841d392 in ?? zend_timeout()


#15 0xbfbfffac in ?? ()


#16 0xbfbfffac in ?? ()


#17 0xbfbfffac in ?? ()


#18 0x2837750f in ?? _php_pgsql_trim_message()


#19 0x2837889b in ?? php_pgsql_get_link_info()


#20 0x28378a11 in ?? zif_pg_last_error()


#21 0x28437b80 in ?? execute()


#22 0x28437cfe in ?? execute()//アドレスがちがうのはさいてきかのせい?それともモ ジュール違い?


#23 0x28437cfe in ?? execute()


#24 0x28437cfe in ?? ()


#25 0x28437cfe in ?? ()


#26 0x28425753 in ?? zend_execute_scripts()


#27 0x283fa7a9 in ?? php_execute_script()


#28 0x2843e3f2 in ?? apache_php_module_main()


#29 0x2843f03b in ?? send_php()


#30 0x2843f0a4 in ?? send_parsed_php()


#31 0x8053f75 in ap_invoke_handler (r=0x8142038) at http_config.c:518


#32 0x80648d4 in process_request_internal (r=0x8142038) at http_request.c:1332


#33 0x8064935 in ap_process_request (r=0x8142038) at http_request.c:1348


#34 0x805d896 in child_main (child_num_arg=135536696) at http_main.c:4719


#35 0x805dacd in make_child (s=0x736ea3, slot=3, now=7564963) at http_main.c:4898


#36 0x805dd59 in perform_idle_server_maintenance () at http_main.c:5083


#37 0x805e259 in standalone_main (argc=2, argv=0xbfbffdd8) at http_main.c:5333


#38 0x805e79b in main (argc=2, argv=0xbfbffdd8) at http_main.c:5601




怪しいのは、php_pgsql_trim_mesageですな。トランポリンコードの直前ってことは多分Watch dog timerがphp_pgsql_trim_message実行中にかかったとおもうのねん。

さて該当ソース/usr/ports/lang/php4/work/php-4.3.6/ext/pgsql/pgsql.cを読んでみると。


218 static char * _php_pgsql_trim_message(const char *message, int *len)


219 {


220 register int i = strlen(message)-1;


221


222 if (i>1 && (message[i-1] == '\r' || message[i-1] == '\n') &&


message[i] == '.') {


223 --i;


224 }


225 while (i && (message[i] == '\r' || message[i] == '\n')) {


226 --i;


227 }


228 ++i;


229 if (len) {


230 *len = i;


231 }


232 return estrndup(message, i);


233 }




取り合えずstrlen()が0のときにi= -1・・・・いやな感じ。つうか225行目を見てみよう。非常にだめげなきがしますね。たまたまスタックに'r'か'n'が積まれている長さ0の文字列きたらすげーいやげなのですが・・・。取り合えず一つだけ'r'があったと仮定しておっかけましょう。
232行目でestrndup("",-1)を実行することになりますね。
そこでzend_alloc.cを眺めてみると。


376 ZEND_API char *_estrndup(const char *s, uint length ZEND_FILE_LINE_DC ZEND_FILE_LINE_ORIG_DC)


377 {


378 char *p;


379


380 HANDLE_BLOCK_INTERRUPTIONS();


381 p = (char *) _emalloc(length+1 ZEND_FILE_LINE_RELAY_CC ZEND_FILE_LINE_ORIG_RELAY_CC);


382 if (!p) {


383 HANDLE_UNBLOCK_INTERRUPTIONS();


384 return (char *)NULL;


385 }


386 HANDLE_UNBLOCK_INTERRUPTIONS();


387 memcpy(p, s, length);


388 p[length] = 0;


389 return p;


390 }




_emallocの仕様くわしくしらないけどlength-1がはいると長さ0のメモリを素直に確保してくれそうなよかーん。もしそうならmemcpyのところみてみると。lengthとして-1を渡してるので。この時点でセグフォがでてよさそうなんだけどなぁ・・なんらかの理由でスタックが破壊されてプロセスが暴走してたりするのかなぁ?(ヒープかもしれないけど)つーてーとトランポリンコードっておもっていたのは破壊されたスタックorメモリ上で動いていたなにか?

まっ。そのへんの謎はのこったものの、while(i~~のところをwhile(i>0に書き換えたらhttpdの無限ループはなおったからいいか。