中古車を現車確認せずに通販で注文してみた

車検切れと同時に車を手放すことになったのでこの機会にと思って中古車を通信販売で買ってみた。ちなみに私は車のことは全然詳しくない。今まで買ったこともない。運転はするがそれは家族の車をたまに使う程度。つまり初めて買う車を、インターネットの通信販売で、車の画像数枚確認して、年式とか走行距離とかプロフィールを確認して、あと適当に電話で店の人に車の状態(修復歴とか気になるところとか)を聞いてみて、それだけで中古車を買ってしまった。

中古車の買い方として現車確認も試乗もせずに買うのは絶対間違っているだろうが、こういう無謀な買い方をする人は意外といるんじゃないだろうか。例えば遠方の自動車屋さんで車を買う場合など。近所の車屋さんで売っている車の中から選ぶというのなら堅実だが、自分が好きな乗りたい車を選んでからそれはどこに売っているか・・・と検討すると現車確認できない程遠くにあるというケース。私の場合がそれだが。

車を通信販売で電話一本で購入する流れは以下のような感じ。普通車と軽自動車とでやりとりに違いが出るようだが、今回は中古の軽自動車を注文する場合。

  • 電話で買う意思を伝える。そのとき店の人に無保証ですよと釘をさされてちょっとビビる。
  • 住民票と免許証のコピーをその自動車屋に郵送で送る。
  • お金を支払う。内訳は車両代金と車検代と名義変更などの事務手数料と陸送代。
  • 車検や名義変更、陸送の手配などを店の人にやってもらう。
  • 車検終わって名義変更も終わってナンバーもつけてもらって陸送してもらって受け取る←今ここ

注文してから陸送で納車までの手続きは約2週間ほど。郵送で書類を送ったり名義変更をしたりとするのでどうしても時間がかかる。普通車の場合は車庫証明を取得したりともっと時間がかかるかもしれない。

車が来たら追記します。

車が来た

陸送にて注文した中古車が来た。ここで初めての現車確認になる。正直なところ、注文する前に現車確認していたら注文するかどうかためらうぐらいの状態だった。うーん、ひどいのが来たなぁ・・・が、第一印象。状態が悪いのは覚悟していたが、予想よりも3割増しで悪いような気がする。

悪かった点

  • 車内のタバコの臭い
  • マフラーの騒音
  • モールの劣化
  • 可動すべきところの故障
  • 画像で確認できなかった部分に相当なカスタマイズが施されていた
  • パワーウインドウの動きが左右で違いなんか怪しい。運転席側の窓ガラスの一部が溶けてた
  • 車体の継ぎ目にあるゴム素材のモールは大体劣化および欠損していた
  • ビニールテープで雨漏り対策されてた(は?)
  • 洗濯バサミが落っこちてた(は?)
  • その他いろいろ

良かった点

  • 古い年式の車だったがエアコンは生きてた
  • 一応エンジンかかって自走できた(車検通ってきたから当たり前かもしれないが)
  • シートの破れは覚悟していたが奇跡的になかった

値段なりの車が届いたというのが客観的な現実だろうと思う。店の人が現状渡し、無保証ですと言った理由が
よく分かる気がした(現状渡しは承知だったが煙草の灰皿に吸い殻が残ったままだったのはさすがに閉口した)。それプラス現車確認を怠ったことによるいくつもの不安要素。現車確認せずに電話一本で中古車を購入した結果は悪いところばかりだが、自分が欲しいと思った車種の車が手に入ったという一点は達成できたので意外と満足感はある。これが自分の興味のない車種で買った理由が安かっただけというのなら最悪だったが。

return UIApplicationMain(argc, argv, nil, NSStringFromClass([AppDelegate class]));

xcodeでクラッシュする場合の話。

return UIApplicationMain をキャッチしてマウスカーソルを合わせるとEXC_BAD_ACCESSとだけ出る。コンソールログには何も出ていない。ゆえにどこで何が原因かということがまるでわからない。私の場合は特に処理の重いルーチンで発生していて、クラッシュの再現性もできなく不規則的に発生するので困難を極めた。それでもバグを取り除かなければならないのでまず手始めにやることはログの情報量を増やすことから始める。Edit SchemeからDiagnosticsタブでデバッグ時のオプションを選択できるようになっているので、そこからログに関係する項目にチェックしてコンソールに表示される情報を増やす。Loggingの項目のどれでもいいが例えばLog Dynamic Linker API Usageにチェックを入れて実行してみたところ変数名とその値がログに表示されるようになる。とりあえずその状態でデバッグをしてみることにする。クラッシュの再現性は不規則であったが、ログを確認してみると特定の関数内の変数に関わるところでクラッシュしているというのがわかった。クラッシュの原因は厳密にはわからないもののどこでクラッシュが発生しているかという関数の場所はログに表示される変数名から特定することができた。結局原因はプロパティ変数にアクセスする際のささいなミスだったんだけれども。

原因不明のEXC_BAD_ACCESSがでるクラッシュでもデバッグオプションでログの情報量を増やせば怪しい箇所を特定することができる。クラッシュした時に原因となる箇所がログに表示されれば一番いいのだけれど、表示されない場合もあるのでそういう場合は実行中にログを流し続ける設定にしてクラッシュしたらその直前のログをチェックして場所を限定する、という具合にやると厄介なバグでも修正できるかもしれない。

デバッグのオプション設定

Memory Management

Enable Malloc Scribble
Enable Malloc Guard Edges
Enable Guard Malloc
Enable Zonbie Objects

Runtime Sanitization

Enable Address Sanitizer Requires recompilation

Logging

Distributed Objects
Malloc Stack
Log Dynamic Linker API Usage
Log Library Loads

Dubugger

Stop on Debugger() and DebugStr()

スーパーロボット対戦F・完結編 精神検索

精神コマンドから該当するパイロットを一覧する

脱力
ボス、レミー、ミヤマ=アスフィー、レディ、ミオ
激励
さやか、ジュン、メリー、ベス、ハルル、沙羅、タシロ艦長、チャム、マーベル、エレ、シーラ、リリス、アム、ロザミィ、エマ、ファ、エル、イーノ、セシリー、レイン、シュバルツ、テュッティ、リューネ
再動
ギジェ、エレ、リリス、リィナ、リアル系副主人公
復活
シーラ、クリス
クリス、セシリー
補給
メリー、ちずる、ギャリソン、キャオ、カツ、レイン、サフィーネ
自爆
ボス、バーニィ、ヒイロ(とその他省略)