バグ報告
- あるNotebookから別のNotebookにノートを移動する操作をした後にマウスカーソルがレインボーカーソルに変わり、一切の応答をしなくなる。
- しばらく待っても応答がないため、アクティビティモニタからInkdropを強制終了させて、起動し直しても同じ状況になる。
- 強制終了→起動を何度か繰り返すと、すべてのNotebookのノート数が0になる。相変わらず応答しない。
- 起動したままにしておくと数時間後にノート数が戻り、操作もできるようになる。
現在発生中のため、メニュー Developer -> Toggle Developer Tools を確認できない。CPU負荷は常に100%前後になっているが、ネットワークトラフィックはほとんどない。
4.にかかる時間は、昨夜発生したときに夜中のうちに終わっていたことから5時間程度はかかっていたようだ。今回はCPU時間で7時間が過ぎたが未だに戻ってこない。ただし、徐々にメモリ使用量が増えている（現在、約170MB）ことから、いずれは戻ってくる可能性がある。
利用環境
- Platform: macOS
- Platform version: High Sierra 10.13.6
- App Version: 4.3.2
再現方法
前述のバグ報告1.の操作で必ず起きる訳ではなく、再現条件を確認できていない。複数枚を選択して移動したときに起きる、もしくは起きやすい感覚がある。再現すると前述のように、操作可能になるまで最低でも数時間はかかるために、気軽に試せない。
craftzdog
(Takuya Matsuyama)
2
Mikihikoさん
こんにちは。ご報告ありがとうございます。
Notebook間でノートを移動する操作をするとアプリが数時間ハングするとの事ですね。
手元で何度か試してみたのですが、再現できませんでした。
複数のノートを移動した時に起きやすいとの事ですが、その数はいくつぐらいでしょうか？
アカウントを拝見したところ、ノートの数がかなり多いようです。
可能性のある原因としては、おそらくノートの移動に際する再インデックスに時間がかかっているものと思われます。
しかし、基本的には差分のみ再インデックスするので、そこまで長時間ハングするのはなぜなのか今のところ検討が付きません。
もし数個のノートでの移動でも現象が発生し、なおかつランダムという事であれば別の可能性が考えられます。
例えば、バックアップの書き込みに時間がかかっているとか…なにかI/O周りな気がします。
もし心当たりがありましたら教えて下さい。
ちなみに、Notebookの中身をまるごと別の場所に移し替えたい時は、Notebookのコンテキストメニューから「Move Notebook…」でNotebook自身を移動できます。
この操作では変更対象がNotebookだけですので、再インデックスコストが抑えられます。
ご参考下さい。
その後、私の方でも試しましたが、再現できませんでした。
最初の報告のMacではない、別のMacにおいて、類似の現象が起きていたので追加します。今回は、ノートを追加したタイミングで起きました。そのときの手順は次のとおりです。
- あるNotebookを選択する
- ノートリストの上にあるCreate Noteアイコンをクリックする
- 左下の利用者名の下に表示されるステータス（普段は最終同期日時）が「Syncing…」のまま同期アイコンが回り続け、マウスカーソルはレインボーカーソルのままになる
- 正常に動作するまでに6時間程度かかった
その後にDeveloper > Toggle Developer Toolsを開いた際に表示されていたエラーを添付します。
複数のノートを移動した時に起きやすいとの事ですが、その数はいくつぐらいでしょうか？
たしか10ノート程度です。
例えば、バックアップの書き込みに時間がかかっているとか…なにかI/O周りな気がします。
もし心当たりがありましたら教えて下さい。
2台のMacBookでどちらも起きます。どちらも内蔵のSSDに保存していて、有線・無線とも外部のドライブ等の接続機器は繋がっていません。
ちなみに、Notebookの中身をまるごと別の場所に移し替えたい時は、Notebookのコンテキストメニューから「Move Notebook…」でNotebook自身を移動できます。
この操作では変更対象がNotebookだけですので、再インデックスコストが抑えられます。
ありがとうございます。
今まで、次のようにしていました。
- あるNotebookで選択対象の最初のノートをクリック
- 最後の選択対象をShift+クリックで範囲指定するか、個別にCommand+クリックで選択して指定
- ラッグ&ドロップで別のNotebookに移していました。
この場合も同じ内部動作になるとありがたいと思います。
craftzdog
(Takuya Matsuyama)
4
ご報告ありがとうございます。
なるほど、ノートの数は問題ではなさそうですね。
ノートの新規作成でも同様の現象が発生したのですね。
とするとなかなか原因の切り分けが厄介です。
前回の僕の仮説は、「ノートの再インデックスでハングしている」でしたが、その可能性が薄れました。
しかしその確信を得るために、以下の操作を試していただけますでしょうか？
- メニュー Developer -> Rebuild FTS Index
この操作で、全文検索インデックスが再構築されます。
これでアプリがハングすれば、なにか特定のノートのインデックス作成で時間がかかっていると推測できます。
たとえば、1万行超えのものすごく長いノートがあるとか。
ipmのsymlink権限エラーは関係無いかと思われます。
権限周りの原因の可能性を疑う場合は、ディスクユーティリティにてFirst Aidをお試しください。
アプリがハングする過去の例としては、IMEが原因で内部ブラウザのChrominium自身がハングする事例があります。
現象の発生がランダムであり再現が困難なことを考えると、アプリ内部ではなくなにか外的要因によって引き起こされている可能性があります。
再現方法が分かり次第対処したいところですが、報告の操作内容で6時間かかる処理というのは実装的に心当たりがなく調査は難航しそうです。
それは仕様上できません。ご了承ください。
この操作で、全文検索インデックスが再構築されます。
これでアプリがハングすれば、なにか特定のノートのインデックス作成で時間がかかっていると推測できます。
ハングアップしました。（ノートを新規作成した際にハングアップした方です。いちおう念のために。）
各ノートの行数などを見る方法を教えていただければ確認します。
たとえば、1万行超えのものすごく長いノートがあるとか。
少し心当たりがあります。Evernoteのノートをインポートした中に、コンソール画面をコピー＆ペーストするなどして作業ログを長々と貼り付けたものがあります。ただし、巨大なノート(HTML)は、インポートしようとするとエラーが出てできなかったため、できるものだけをインポートしています。（このエラーについては、後ほど報告しようとしたままになっていました。）
craftzdog
(Takuya Matsuyama)
6
なるほど、とすると特定のノートが原因のようですね。
そのノートを特定するためのパッチを後日ビルドします。
少々お待ち下さい。
ご報告ありがとうございます。
HTMLインポートのエラーについてはまた別の問題だと思われます。
そちらは別途ご詳細を報告ください。
craftzdog
(Takuya Matsuyama)
7
@Mikihiko_Mori
こんにちは。
全文検索インデックス(FTS)のパフォーマンスを少し改善してみました。
こちらのパッチをお試しいただけますか？
https://inkdrop-dist.s3-ap-northeast-1.amazonaws.com/tmp/Inkdrop-4.3.2-Mac-patch-3.zip
このパッチでは、FTSに関するログも出力するようにしています。
以下のファイルをターミナルから叩いて実行してください：
<PATH_TO_APP>/Inkdrop.app/Contents/MacOS/Inkdrop
もし処理の途中にハングすれば、直前に出ていたログから原因となっているノートIDが特定できます。
動作確認よろしくお願いします！
