FC2ブログ

ゆとりっちうやつ

ゆとり教育の弊害、とかなんとか最近うるさくて。
円周率がだいたい3、とか、どうでもいいこっちゃ。

うちの子供はみんなどっぷりゆとり世代なんだけれども、のほほんとしてる割にはしっかりしてるし、他人の長所を認める術を心得ている。

『あいつはバカだから』、と普段から言ってる同級生についても、『でも~をやらせたらクラスじゃ一番だ』、みたいな事を自分の事のようにうれしそうに語る。

まぁ、そういうほんのちょっとした部分なんだけれど、教科書以外の部分の、成長と関わる部分の、学習ってのが多少はできてるように思ったりする。
これはゆとりのおかげなのかもしれないな、と。

三無主義と揶揄されたお父さん世代からみりゃー、随分と人間らしい人間に見えるわけで。

うちの奥さん曰く、『長男(お父さん=俺)が一番の問題児』、ってぇのは間違いないんだよな。


三無主義:無気力・無感動・無関心。やる気のなさげな'70~'80年代当時の若者世代を揶揄した言葉。
スポンサーサイト

デバッグモードっちうやつ

VCをしばらく使ってgccに戻ると、つまらない事で戸惑うことがあるんだが、今回はデバッグ モード

VCでいうデバッグモードとは、シンボルの埋め込みに留まらず、デバッグ用のライブラリに差し替えることで実行時の細かな監視が可能となっている。また最適化をオフにすることで正確なトレースも可能となっている。
便利なんだが、ライブラリが差し変わるということで、リリースビルドしたものとは随分と挙動が変わってきてしまう。

マルチスレッドものだと、デバッグモードでは同期に近い動きをする場合があり、リリース時に発生するバグがなかなかとれないという事もままある。

そういうのもあって、デバッグモード=遅いというイメージもついてたりするんだが、先日gccで開発中のとある場所で、
「-g外したら劇的に早くなるんじゃない?」
と聞かれて考え込んでしまった。
「いや...そうでもないと思いましたが...」
となんともキレのない返事をしてしまった。

VCの例もあって遅いと思われがちなんだけれども...以前確認したような記憶があって、もやもやが。

んで今ちょっと確認してみたんだが、やっぱりgccでは-gつけようとも最適化はちゃんとされる。
当然デバグ用のシンボルやなんやが埋まるわけでサイズはバカでかくなるし、決して速くなることはないのだろうが、速度的に大きな差があるわけでもない。
gdbでトレースしてみるとわかるが、明示的に最適化を抑制しない限り、適度な最適化は行われていて、トレースもずっこんずっこん飛びながらもgdbはちゃんとついてくる。偉い。

まぁVCでリリースビルドでも、デバッグ用のシンボルが埋まっていればデバッガでのトレースは可能なわけで、それとおんなじなんだけれども。

てぇことで、問題はデバッガやシンボルがうんぬんていうよりも、-D_DEBUGで切り分けてるコーディングの方にあるわけだよ、と。

NetBSD3.1インスコちう

インスコまではすんなり行ったNetBSD3.1
さていろいろ入れて設定を、っていうほどの時間がなかなかとれず、Network設定してFireFox入れて、KTermの設定してとりあえず日本語が見れるあたりまでで。

今日は日本語入力せねば、ってところでwnn入れたがjserverが立ち上がらない...調べる前に居眠りしちゃってそのまま終了。あとは来週か...

日本語入力できるようになればフォント入れてOpenOffice入れてプリンタ繋いで、ってところまでだが、いぢれる時間がとれるのは4月中旬かな。
開発用環境としては、ちょっとWideStudioも入れて使ってみたいなと画策しておるです。
さてどうなるやら。

連結リストで特許?

スラッシュドット ジャパン | リンクトリストが2006年に特許承認
によると、米で連結リスト(Linked-List)のアイデアが特許申請され承認されたようだ。

本家スラドの記事(英語)によると(ようわからんが)、triply-linkedとか、Multi-linkedとか出てくるので、その辺にアイデアがあるんだろう。

といっても、基本的な連結リストは、単純な単/双方リストでさへもアイデアの宝庫であって、それこそがプログラマの腕の見せ所でもあるわけで。
逆に言えば、実用的なアイデアから奇抜なもの、特異なものまで世の中には溢れかえっているともいえる。

ってぇことで、このパテント主が果たしてパテント料を徴収する気があるのかどうか、って部分が今後の焦点。
大方の見かたは、
パテントの過度な主張はトラブルの元だし、せっかくとった特許が取り消される恐れも十分にある状況で、妙な動きはしないであろう

というもののようである。

UnisysのLZWの件もあるし、妙な制限を受けることのないよう世のプログラマの皆様には、例え稚拙でもバグありでも、ソースはどんどん公開して欲しいと願う。

ネットも繋がらないTerminal上でのviだけで、それも小一時間でやっつけなければならないような状況下では、アイデアもクソもあったもんじゃないんだけどもさっ。ふん。

RFID児童登下校管理システム

高木浩光@自宅の日記 - RFID児童登下校管理システムのクオリティは安心安全ソリューションってレベルか
より

高木氏の視点はセキュリティだから、「あらあら」のような醒めたコメントがついてるんだが、業務系に身を置くものとしちゃ他人事ではない話で。
ユーザ側からの”メール停止 - 情報科な日々のつれづれ” のような切実な悲鳴は、開発者にとっては堪えがたいものだ。

システムの概要は
RFIDによって児童の登下校を認識し、登下校の状況を保護者へメールリアルタイムに通知する

というようなもので、当初は学校側の登下校(出欠)管理での利用を主に考えていたものが、保護者への通知という”おまけ”の期待度が上がっていったということのようだが。

情報化な...のブログを読んでわかる富士通の罪は、以下の二つ。
  1. 十分なサポートを行わなかったこと。
  2. インターネットメールの仕組みを十分に説明していなかったこと。


お金の都合でサポートが十分にできないケースも実際にはままあることだし、契約上明記されていなければなおさらトラブルになるケースも多いから、これはまぁしょうがないといえばしょうがないのかもしれない。
もちろん開発者としちゃ不具合に対応できないってのは我慢ならん事なんだけれども、飢えるわけにもいかず。

んで問題なのは後者の方。
インターネットメールに信頼できるほどのリアルタイム性がある、ってこの先生思っちゃってます。
富士通は一体どんな説明/プレゼンしたんでしょうか。
いいことばっか言ったんじゃねーのか?>F

百歩譲って、当初は保護者への通知はおまけであった、としても、説明は十分にすべきだし、おまけならおまけらしく無駄に冗長な注意書きを添付するなりできたはずでしょうに。
それに障害用にWebサーバ立てるくらい簡単な事のはずなんだが。
日記中に「セキュリティうんぬん」てあるのはたぶんWebサーバ立てるなりミラー立てるなりって話なんだろうけれど、そんな面倒な話じゃないんだからササっと立てちゃえよと。
他の現場でも同じ事起きるんだし、「本来はここまでやらねばならず、その為にはこれだけ金がかかる」とかならまだいいのに、「セキュリティに多少問題があるが...」なんてのはちょっと見識/良識疑われてもしょうがないさな。

客とこんだけ気持ちが離れちゃうともう修復難しいかもね。
まー、この先生もなんだかこの件に関しちゃ冷静に見れなくなってるようで、どっちもどっちと言えなくもないんだが、思惑と違った所で旨みが出ることも良くある話なんだから、もちっと大切にしちゃらんとさ。大手なんだし。>F(とかNとかHとかIとかSとかも、ね)

とかいいながらも、周りの電話の応対で耳に入ってくるのは、似たような受け答えなんだなぁこれが...

NetBSD

子供のPCの調子が悪い、ってんで、お父さんのPC取られた。(T^T

んでこれまで子供が使っていたCeleron-566MHzという骨董品の部類に入るPCをお下がりで使うはめになったわけなんだが、今更Windowsでもなかろうってんで、まずはFedora Core 6のダウンロードを始めたのはいいが、Disk2がどうにも落ちずに断念。
たまたま手元にあったNetBSD 1.6.xを入れる事にした。
NetBSD

CDでBootした後は殆ど設定らしい設定も無いまま、すこんすこんとEnterを叩いて、Standard with Xをインスコ、何事もなく完了。
HDDから起動後、xf86cfgでキーボードやビデオカードの設定をして、startx。久しぶりのTWMの素っ気ない窓が現れる。
さてまぁここまで順調なので、もう一度インストールCDを入れて、今度はUpdate。最新はってぇと、3.1!?
ままよ、とFTPでの3.1へのUploadを進めること小一時間。
飯食ってから画面を覗くと止まってる。完了か?と思ったらDownload Failure...
xcontrib.tgzが無いとかほざいているので、FTPサイトを覗いたら、そんなファイルは無い。まぁしゃーないな。

てぇことでNetBSD 3.1のISOイメージをダウンロードをしているところ。
FedraのCD5枚組みに比べてこちらはたかだか200MB強。もうすぐ落ち終わる。
インスコは明日だな。

しかしCeleron-566MHzでXやらJavaやらがまともに動くだろか...せっかくXen対応のNetBSDだもの、一式買わないかんかな...(にやり

閑話休題

パソコンQ&A系のサイトをちょこちょこ見て回ってるんだが、Win-Vistaのトラブルのなんと多いことよ。
MSの開発者の名誉ために言っておくが、トラブルの殆どは、自分のマシンのスペックを理解しないままVistaへ移行した素人さんだ。

PCのポジションを一歩進めた、言うなれば先取りとも言えるVistaなのだから、現行システムでも切り捨てられる部分は多数ある。特にグラフィック/音声周りは将来を見据えてかなり手が入っているはずだ。
それをMeからXPにアップデートして、誰かに「メモリが少ない」と突っ込まれる程度のマシンに、躊躇なく、かつ、メーカーの対応状況など調べもせず、いきなりVistaをインストールし、「どうしたら良いのか」と質問を投げる。困ったもんだ。

まー素人さんだしなー、と思っていると、これが業界人でも直接開発に携わらない部署の人間だと、同じようなことを結構やってる。
汎用機/汎用機以外、の認識しかない人間だったりすると、
汎用機以外=Windows
という図式になる輩も少なからず。

んでまたそういう人間が上に居たりすると、現場である開発者に開発環境として、自分のお古のPCをあてがってくれたりする。

Pentium III -1GHz ですか...最新機器をくれとは言わないし、まぁ我慢しましょう。
でも、XP入れてメモリが128MBですか、使える程度に動きますかね?
で、開発者には隅がボケたCRTですか。メールのやりとりだけのあなたが新しい17'TFTモニタなんですね。もうこの際どうにでもしてください。
でもね、Linuxサーバの開発なんだから、Linuxマシンくらい買いましょうよ。Win上で秀丸だけでサーバ開発ってことですか、しかもこの秀丸は私物なんですけども。
あ、ちょっと、その「廃棄」って紙貼ったそれ、ちょっと待って、こっちのマシンよりスペック上なんじゃね?取り替えちゃだめ?そういう決まり?はぁそうですか。

個人情報だなんだで、自前環境での開発が著しく制限されている昨今、秀丸だけで机上で叩いたコンパイルさへ怪しいコードがどんどん増殖していくんだけれども、大丈夫なのか日本?

DeadLockの犯人探し2

この時点での重要参考人は__vfprintfだが、そもそもの問題であるdeadlockとの関係も、deadlockが起きる仕組みも明らかになったわけではない。
ただしこの現象は、初期処理直後に
signal(SIGCHLD, SIG_DFL)
とすることで改善されている。

手がかりを求めて操作は引き続き__vfprintfへ焦点をあてる。
__vfprintfは、/usr/src/lib/libc/stdio/vfprintf.cで定義されている。
__vfprintf内部での処理の殆どはformat処理であり、mallocを使用するのは唯一%S使用時のマルチバイト文字の処理の際のみ。
FILEはどうなったかというと、__sprint関数へそのまま投げられている。

__sprintはvfprintf.c内部で定義されており、__sfvwrite関数へとFILE *を引き渡している。

__sfvwriteはfvwrite.cで定義されており、

とここまで来るともう嫌気がさしてくるので、関数呼び出しツリーを作成してみることにする。

(つづく)

DeadLockの犯人探し

gccでの開発で、forkで子プロセスをパカパカ上げていると、親プロセスがうんともスンとも言わなくなった。

gdbでプロセスにアタッチしてスタックトレースを見ると、
#0 0x00ad27a2 in _dl_sysinfo_int80() from /lib/ld-linux.so.2
#1 0x00bbf69e in __lll_mutex_lock_wait() from /lib/tls/libc.so.6
#2 0x00bb7c49 in _L_mutex_lock_1947() from /lib/tls/libc.so.6
#3 0x00000000 in ??()

一行目のsysinfoは、gdbでアタッチしたことによる割り込みで、問題は二行目以降(#1~#3)の、mutex_lock
どうやらdeadlockのようだ。

mutex使ってこっそり排他と聞いてまず思い浮かぶのがalloc系関数。がしかし、パラで動くような所でmallocは使っていない。
_DEBUG関連か?と思い、-g -D_DEBUGを外して見ると頻度こそ減ったが、稀に同様の症状が発生。
ここで唸ること一週間...(これが歳老いたという事か)

ふと思いついて初期処理として呼んでいるライブラリ関数のソースを辿っていくと、あったあった、sigaction
シグナルを受けるとレポートする関数がしっかと刻まれていた。
この中で使われているC標準関数は、
  • memset
  • strncpy
  • strlen
  • strcpy
  • strcat
  • sprintf
  • time
  • localtime
  • perror
  • open
  • write
  • close
  • getenv

さぁ、犯人は誰だ!?
手が届くところにはFreeBSDのgcc 3.4.2しかないのでこのソースを見てみる。
  • memset - /usr/src/lib/string/memset.c - 白
  • strncpy - /usr/src/lib/string/strncpy.c - 白
  • strlen - /usr/src/lib/string/strlen.c - 白
  • strcpy - /usr/src/lib/string/strcpy.c - 白
  • strcat - /usr/src/lib/string/strcat.c - 白
  • sprintf - /usr/src/lib/stdio/sprintf.c - ...

お??、sprintfでFILEを使ってやがる。FILE操作でmallocが出てくるのは以前に何かで調べたが、すっかり忘れているので今回も追ってみる。
で、マクロでなにやらINITEXTRA(&f)??
INITEXTRAは/usr/src/lib/stdio/local.hの中で、
#define INITEXTRA(fp) { \\
(fp)->_extra->_up = NULL; \\
(fp)->_extra->fl_mutex = PTHREAD_MUTEX_INITIALIZER; \\
(fp)->_extra->fl_owner = NULL; \\
(fp)->_extra->fl_count = 0; \\
(fp)->_extra->orientation = 0; \\
memset(&(fp)->_extra->mbstate, 0, sizeof(mbstate_t)); \\
}

出た、mutex!しかしまだここではlock処理は出てこない。
PTHREAD_MUTEX_INITIALIZERは、/usr/include/pthread.hで、NULLに#defineされている。
この時点での重要参考人であるsprintfはこの後、va_start, __vfprintf, va_endと呼び出している。

(もう眠いのでこの続きはまた今度)
プロフィール

f_yamaki

Author:f_yamaki

アクセスカウンタ
最近の記事
最近のコメント
最近のトラックバック
月別アーカイブ
カテゴリー
ブロとも申請フォーム

この人とブロともになる

ブログ内検索
RSSフィード
リンク