- 投稿
江村様
いつもお世話になっております。
yasujiです。EmEditorの[ディスクベースを有効にする(B)]をOFFに設定した状態で、200.28GBのXMLファイル（文字エンコーディング:UTF-8）を開くと、物理メモリ128GBの空き容量がほとんど0Byteになり、それでもファイル読込処理を停止することなく、スワップファイルは利用可能な容量をすべて使用して、その状況で[一時フォルダ(F)]に一つ512MBのEME14E0.tmpのようなファイルが時間経過とともに作られ続けてCドライブの空き容量を加速度的に消耗し続ける致命的バグが見つかりましたのでご連絡いたします。
この時点で、EmEditor本体のステータスバーのファイル読込進捗率48%で、すでにWindowsOSや他の常駐ソフトウェアがやや不安定動作になり、システムデータ損失の危険を感じたため、手動でEmEditorのウィンドウの右上の閉じるボタンを押下して終了させました。少なくとも、ここまでファイルの読み込み処理を中止するような動作は一切見られませんでした。
なお、[カスタマイズ]->[高度]の[最大メモリサイズ(Y)]と[ファイル毎最大メモリサイズ(X)]により、ファイル読込で使用する最大メモリが制限されて読込が停止すると考えていましたが、全く効果がありませんでした。したがって、[一時フォルダ(F)]に予見できない大量の512MBの一時ファイルが作られ続けWindowsシステムを危険にさらしている点を考えて致命的バグと判断しました。[一時フォルダ(F)]のデフォルトは、
"C:\Users\$($Env:USERNAME)\AppData\Local\Temp"(PowerShell用表記)になっており、この事象の初回経験した時はCドライブのディスク空き容量が時間ともに減少していき、このままだと0バイトになりWindowsOSがBOSDになる可能性が予見されたため、十分空き容量があるうちにEmEditorを終了させることで問題発生を回避することができました。
Cドライブの空き容量の減少する速度が、スワップファイルの段階的な増加よりも速かったため、ユーザプロファイルのTempフォルダを確認したところ、２５０個以上のEMExxxx.tmp(xxxxは16進数文字列)のファイルが次々と作成され続けていることが原因であることが判明しました。
EmEditorを使用していない状態で再確認しましたが、そのようなファイルは一切見つかりませんでした。
再度、EmEditorを使用して巨大ファイルを開いて、Tempフォルダを観察したところ、物理メモリを使い切った直後からEMExxxx.tmpが多数作成される続けることを確認しました。
これらの確認した事実から[ディスクベースを有効にする(B)]をOFFに設定したEmEditorには、物理メモリサイズを超えるファイルを開く際には、事前にメモリ不足で開けないエラーや、読込処理中にメモリ不足に陥ってもエラーにならず、一時フォルダに512MBの一時ファイルを作成続けてファイル読込を強行してWindowsシステムを不安定にする致命的バグが存在しています。
念のため、物理メモリを確保できなかった時点でエラーを表示して、読込処理を中止するのが、正しくかつ安全なソフトウェア設計です。この場合の動作検証（テスト）を全くしていなかったのは明らかです。[カスタマイズ]->[高度]の一番上の位置には、「このページの設定を変更すると、予想しない結果が引き起こされることがあり、サポートの対象となりません。また、設定を変更すると、EmEditorを再起動する必要があります。」という警告文が記載されています。
この致命的バグは、その警告文の通りに解釈すれば、江村様は言い訳をするのが非常に上手ですので、変更した私が悪いという言い訳ができます。言い訳をして私が変更したのが問題だと言っていただいてもよいです。もし、ユーザで何かご意見や言いたいことがあれば、ぜひ書き込んでいただきたいです（江村様が言い逃れをする可能性があるのでどのように対応してほしいかなどのご意見をいただければと思います）。このトピックが、他のユーザの投稿で荒れるのは、仕方がないと思っています。
下記の〔再現手順〕については、このバグ報告に必要な情報収集のために実行した可能な限り安全になるように作成して、私が実機で実行した作業手順です。
もし、試したいと考えるならば、VirtualBoxなどで仮想マシンを作成してその中で試すのをお勧めします。
私が実機で試した理由ですが、（１）TrueImageでCドライブを毎日バックアップをとっている、（２）CドライブはPCIe Gen.4 SSDで実測値でWrite 6GB/s, Read 6GB/sが出るので、スワップファイルおよび一時ファイルの読書でI/O処理待ちによるOSの操作遅延になりにくい、（３）損害が出ても自己責任で対処できるからです。さすがに、EmEditorが一時ファイルを大量に書き出す処理をするのは、完全に予想外でした。〔対象〕
v24.4.1 (64bit)〔使用環境〕
CPU : AMD Ryzen 9 3900X 12-Core Processor 3.80 GHz
RAM : 128 GB
OS : Windows 10 Pro 64bit 22H2 build 19045.5011
MB : ASUS PRIME X570-PRO
SSD : 2TB (C:, PCIe Gen.4, 実測値: Write 6GB/s, Read 6GB/s)Windows 10:
(システムのプロパティ):詳細設定->パフォーマンス->設定
(パフォーマンスオプション):仮想メモリ->変更
(仮想メモリ):
全てのドライブのページングファイルのサイズを自動的に管理する(A)：OFF
各ドライブのページングファイルのサイズ
選択したドライブ: C:
カスタムサイズ：
初期サイズ(MB): 17269
最大サイズ(MB): 19456
すべてのドライブの総ページングファイルサイズ
最小限 ： 16 MB
推奨 ：17269 MB
現在の割り当て：17269 MB※()で囲まれた文字列はウィンドウタイトルを示す。
〔再現手順〕
０．事前準備
WikipediaのDatabase backup dumpsのファイルをダウンロードして、それぞれ展開する。展開のファイルサイズは、非常に大きいためディスクの空き容量に注意すること。enwiki-20241020-pages-meta-current.xml.bz2 (file size: bz2 39.3 GB, xml 200.3 GB, encoding: UTF-8)
なお、上記のファイルは、2024/11/08時点ではダウンロードできるが、３カ月程度でローテーションするため、最新の日付のURLからダウンロードする必要がある。
１．EmEditor 64bit ポータブル版を初期状態で起動
zipファイルから展開して、起動する。
初回のエディション選択は、Professionalを選択する。２．EmEditorの設定を変更する
[ツール(L)]->[カスタマイズ(C)…]を開いて、下記の通りに設定する。
[カスタマイズ]->[高度]
[ディスクベースを有効にする(B)]：OFF
[システムの一時フォルダを使用する(E)]：OFF
[一時フォルダ(F)]：D:\Temp“D:\Temp” は、Cドライブ以外に一時フォルダを作成して設定すること。
Cドライブの一時フォルダを使用した場合、最悪の事態としてCドライブの空き容量が0バイトになり、データ保存失敗によるOS動作不安定、BOSD(Blue Screen of Death)(日本語説明)を発生させる可能性があるので細心の注意を払う必要がある。下記は、初期設定のまま変更しない。〔使用環境〕で自動設定される設定値の参考として記載する。
——————
[スレッド数(N)]：自動(24)
[命令セット(I)]：自動(AVX2)
[すべてのメモリサイズを自動的に管理する(A)]：ON
[メモリサイズ(Z)]：31
[最大メモリサイズ(Y)]：98836 MB 90%
[ファイル毎最大メモリサイズ(X)]：74127 MB
——————３．EmEditorを再起動する
２．の設定を確実に反映させるため、念のためにEmEditorを再起動させる。４．検証前準備
タスクマネージャを起動させて、[パフォーマンス]->[メモリ]を表示させる。
情報を記録する必要があれば、メモ帳を起動させおく。
エクスプローラを起動して、PCをクリックして接続されているHDDとその空き領域を表示させておく。Cドライブの空き領域が0バイトになる前にEmEditorを終了させるため。ウイルス対策ソフトウェアが常駐している場合は、終了させておくこと。メモリ不足になった場合の安全に動作し続けるのかが不明で、万一にもEmEditorの挙動がマルウェアかウイルス扱いされて駆除動作をさせないようにする安全措置のため。
その他、必要なツールがあればここで起動させておく。なぜなら、物理メモリ不足になることがわかってていて、その状態でソフトウェアやアプリが起動できると限らないし、それがきっかけでWindowsが動作不安定になる危険性があるため。
５．ファイルを開く
下記のファイルを開く。
enwiki-20241020-pages-meta-current.xml６．状況の観測
タスクマネージャの[パフォーマンス]->[メモリ]を観測していると、１分ほどで128GBを使い切ってしまうことが確認できる。
タスクマネージャの[パフォーマンス]->[プロセス]に表示されるリストの中のEmEditorのメモリサイズを確認すると、113GBとなっている。物理メモリを使い切った直後、[一時フォルダ(F)]の中にEMExxxx.tmpが大量に作成され続ける現象が発生する。
EMExxxx.tmpのファイルサイズは、下記の通り。これらのファイルの数は、時間が経過するとともに増加する。おそらく、開いたファイルサイズのうち不足した物理メモリサイズの分まで作成されると推測している。
enwiki-20241020-pages-meta-current.xmlは、UTF-8で200.3GBになるが、おそらくEmEditorは内部ではテキストをUTF-16に変換してメモリに保存している。したがって、必要な物理メモリサイズは、およそ400.6GBと推測できる（UTF-8 ==> UTF-16への変換は元のデータサイズを２倍すれば正確ではないが推測できる）。不足している物理メモリサイズはおよそ287.6GBと推測できる。さらに継続して、タスクマネージャの[パフォーマンス]->[プロセス]に表示されるリストの中のEmEditorのメモリサイズを観測していると、時間経過とともにどういうわけか113GBから100MBまでに減少する。どうしてこのようなことが起きるのか全くわかりません。
スワップファイルのサイズ変化の監視するPowerShellスクリプト。実行すると１秒ごとにスワップファイルのサイズをMiB単位で出力する。停止する場合は、キーボードでCtrl+Cキーを押下する。
PS > while ($true) { “$($(dir -force C:\pagefile.sys).Length / 1MB)” + ” MiB”; start-sleep -seconds 1; }
[一時フォルダ(F)]に作成された一時ファイルの確認するPowerShellスクリプト。実行するとファイル名とサイズのみを一覧表示する。
PS D:\Temp> dir | select name,length
Name Length
—- ——
EME14E0.tmp 536870912
EME1994.tmp 536870912
EME1FFE.tmp 536870912
EME254E.tmp 536870912
EME2976.tmp 536870912
EME2F14.tmp 536870912
EME33E8.tmp 536870912
EME35CA.tmp 536870912
EME388C.tmp 536870912
EME38D8.tmp 536870912
EME3BD6.tmp 536870912
EME3D8E.tmp 536870912
EME3EC5.tmp 536870912
EME406.tmp 536870912
EME41C4.tmp 536870912
EME42BF.tmp 536870912
EME44D2.tmp 536870912
EME47F0.tmp 536870912
EME4A52.tmp 536870912
EME4AEF.tmp 536870912なお、EMExxxx.tmpのファイルの一つの中身を確認するために、エクスプローラを使用してそのファイルを他のフォルダへのコピーを試したが、コピーが失敗した。おそらくRead Lockがかけられているようです。
７．EmEditorの終了
EmEditorの動作確認が十分にできたか、WindowsOSが不安定な状態になり始めたら、速やかにEmEditorのウィンドウの閉じるボタンを押下して終了させる。ファイル読込処理が中止され一時フォルダの作成された一時ファイルもすべて削除、物理メモリもすべて解放されて正常な状態に回復します。
上記の操作ができない、または実行しても効果がない場合は、タスクマネージャからEmEditor.exeを強制終了させる。８．Windows OSの手動再起動
起動したツールなどは、正常終了させる。
メモ帳は、記録した情報をファイルへ保存して終了させる。その後に、念のためWindowsを再起動させる。
いつもお世話になっております。江村です。
ご指摘いただいた動作についてですが、これは不具合ではありません。私のブログで以下のように説明しています。
「v23.1 では、メモリに関連するアルゴリズムを見直し、より効率的な動作を実現しました。さらに、仮想メモリが不足すると一時ファイルを使用してデータを保存するようにしました。これにより、仮想メモリのサイズに気を遣わずとも、メモリ不足によるクラッシュの頻度を大幅に軽減することができました。このメモリ関連の改善の効果と、マルチスレッド、SIMD 命令セットの使用により、CSV を含む巨大ファイルの編集時に多くのコマンドで、v23.0 に比べて 1.51 から 41.2 倍に高速化しました。」
ストレージの残り容量がほとんどない場合には、一時ファイルを作成せずに警告メッセージを表示し、ファイルのオープンを中止する仕様になっています。ファイルを閉じたりEmEditorを終了すると、これらの一時ファイルは自動的に削除されます。EmEditorのプロセスが強制終了した場合でも一時ファイルは削除されます。Windowsの動作が不安定になったり、BSODの心配はありません。
よろしくお願いいたします。
江村様
いつもお世話になっております。
yasujiです。ご提示いただいたブログの説明とリンク先の内容を確認しました。
確かに、私がバグだと報告した動作が、v23.1の動作仕様通りであると理解しました。その動作仕様で確認です。
EmEditorを動作させたPC環境がC:しかなく、そのC:に開きたい200.3GBのXMLファイルがあり、[一時フォルダ(F)]はデフォルトのままだとします。
この状況下でEmEditorを起動して、200.3GBのXMLファイルを開くと、メモリ不足、ページファイル不足になり、[一時フォルダ(F)]のパスに一時ファイルを大量に作成して、最終的にはファイルを開く処理が完了して編集可能な状態になる。ただし、メモリ不足分のデータが、一時ファイルとして書き出された状態です。当たり前ですが、ファイルを編集しようとしてスクロールしたり書き換えたりすれば、その一時ファイル（ページファイルも含む）の読み書きが発生します（メモリに読み込まなければ処理できません）。HDDであれば、読取速度と書き込み速度はメモリより圧倒的に遅いです。（高速転送できるSSDを前提にしないでください。すべてのユーザが高速なSSDを持っているとは限りません）
「v23.1 では、メモリに関連するアルゴリズムを見直し、より効率的な動作を実現しました。」とありますが、HDD上の一時ファイルならびにページファイルを使うことは処理速度の低下を招くことは自明なのですが、どうして効率的な動作が実現できるのでしょうか？リンク先の文章を改めて読んでみたところ、とんでもないことが書かれておりましたので確認させてください。引用された文章の中にも含まれています。
「仮想メモリのサイズに気を遣わずとも、メモリ不足によるクラッシュの頻度を大幅に軽減することができました。」と書かれておりますが、これはv23.1をリリースした時点で、そのバージョンにはメモリ不足を契機としたクラッシュバグがまだ存在していますと江村様は認識してリリースしたと理解しました。実際に、「置換で改行が増加するとクラッシュする」で発生しております。この報告内容の事象で本当に江村様の下記のご説明は、間違いなく検証されて保証されているのでしょうか？Windowsの動作が不安定になったり、BSODの心配はありません。
よろしくお願いします。
- このトピックに返信するにはログインしてください。