高専ワイヤレスIoT技術実証コンテスト
高専フォーラムにて紹介のあった、高専ワイヤレスIoT技術実証コンテスト。
今年は、「5G活用部門」及び「ワイヤレスIoT活用部門」にて実施だそうです。
高専フォーラム2018参加
名古屋大学で8/20,21,22と開催された高専フォーラムにて、電子情報の西先生、村田先生、川上先生が発表されました。
これ以外にも、様々なテーマでのセッションが開催され、高専特有のテーマを聴講したりしました。
PCN武生のお手伝い
今日はPCN武生の最初の講座。
小学校の一年生で、簡単な命令と早押しゲームの体験でした。
緊急連絡システムのOS更新など
緊急連絡システムのOSが、Ubuntu/trusty でそろそろ、サポート期間に近づいているので、OS の更新を行った。
Ubuntu 更新
更新自体は、do-release-upgrade コマンドで、xenial に更新が進む。
$ sudo do-release-upgrade
しかしながら、openssh-server が、更新でエラーがでて、かなり悩んだ。解ってみれば、単純なミスで、自作の /etc/init.d/script を書いてあったけど、その insserv ヘッダで、ssh をコピーしてヘッダ部の # Provides: sshd の行を書き換えてなかった。
このおかげで、insserv が、ssh はすでに登録されている…と勘違いしていた。
緊急連絡システムの文字コードUTF-8 に変更
Ubuntu の更新をかけたら、php5 が使えなくなったため、php7.0 に更新を行うが、これに合わせ、取り扱い文字コードを EUC-JP から UTF-8 に変更を行った。
緊急連絡システムは、内部でデータベースを利用せず、テキストファイルですべてを管理しているが、最初は利用組織毎の設定ファイルや、データファイルをエディタでチマチマと修正を始めたけど、大量の組織のため、途中で断念。perl でファイル名や記載時のエンコーディングを修正するスクリプトを書いて一発変換。
あとは、プログラム中のエンコーディング依存の部分を修正し、送信できることを確認してひとまず移行作業完了。
情報構造論の追試のための解答例
情報構造論の成績不振者のための追試を、8/9(木) 15:30 より 4EI 教室で実施します。
インターンシップなどで当日参加困難な場合は、別日に実施しますので、連絡してください。
テスト問題の解答および解説を、以下に示します。
追試では、問題を変更して出題しますので、決して文字の暗記で臨まないこと。
局所変数配列をreturn
情報構造論の前期期末試験で、局所変数返しの解答が多かったので、メモ。
JavaScript でプログラムを書いていると、動くネタだけど、C言語では初心者がよく間違って書いてしまう定番であり、それなりに動いたりするから、誤解が増えてしまう可能性もある。
スタック変数返し
char* foo() { char str[ 20 ] ; strcpy( str , "Hello World" ) ; return str ; } char* bar() { char baz[ 20 ] ; memset( baz , 'A' , sizeof( baz ) ) ; return NULL ; } void main() { char* ans = foo() ; printf( "%s¥n" , ans ) ; // Hello World // 一見正しく動いているように思うかも。 bar() ; // 局所変数を触るだけの処理 printf( "%s¥n" , ans ) ; // AAAAAAAAAAA // ans の中身が壊れている。 }
静的局所変数返し
上記のスタック変数を返す問題点を示すと、じゃあ静的局所変数でいいじゃん….という話がでてくる。
char* foo() { static char str[20] ; strcpy( str , "Hello World" ) ; return str ; }
この方式なら、スタック領域ではなく静的変数領域なので、関数呼び出しで破壊されることはない。
しかし、この方式は「スレッドセーフ」ではない。foo() の処理後に、スレッドを起動した場合、スレッドではメモリ空間が共有されるため、foo() を保持していて、別スレッドがそのメモリを書き換えると、他方は中身が変わってしまう。
(参考「スレッドセーフではないCライブラリ関数」)
自室サーバ、やばいかな
自室のサーバ、OS 更新をかけて部屋を離れていたら、どうも気絶をしていたようだ。
パワーリセットをかけても起動をしないので、モニタをつないで確認したら、リカバー時の fsck がうまくいっていない様子。”(initramfs)”のプロンプトの出ている状態で、fsck /dev/sda1 を入力し、いくらかエラーを吐きながらもなんとか FIX は終了し、再起動をかけたら、これまた起動せず。
boot初期段階で、”unreliable CPU thermal sensor monitoring disabled”で止まってる。色々と対策をしらべていたら、なぜか起動処理が再開され、ひとまず復帰。
unreliable CPU thermal sensor monitoring disabled
でも、これはいつ再発してもおかしくない…。自室のサーバは “PowerEdge T105” で、これのカタログを拾うと 2007年の製品。ひとまず起動したマシンで /etc のファイルの最古参の日付を確認すると、2008年。ほぼ 10 年間使っていたのか。
エラーメッセージからすれば、「CPUの温度センサーが怪しい」とか、マザーボード故障の可能性が高い。こりゃ、次のサーバを準備すべきだな。