製品がリソースまたはハンドルを複数回クローズまたはリリースしようとし、クローズ操作の間にオープン操作が成功しなかった。
コードでは通常、メモリ、ファイル、デバイス、ソケット接続、サービスなどのリソースへのハンドルや参照を「オープン」する必要がある。コードがリソースの使用を終了すると、通常、リソースを「クローズ」または「リリース」することが期待されます。これは、（OSなどの）環境に対して、リソースが関連性のないプロセスやアクターによって、または場合によっては同じプロセス内で、再割り当てまたは再利用できることを示します。この解放を実行するために、API関数やその他の抽象化機能が使用されることが多く、C/C++ではfree()やdelete()、多くの言語で使用されているファイルハンドルのclose()操作などがあります。
残念なことに、そのようなAPIの実装や設計は、開発者がそのようなAPIがリソースのリリースごとに一度だけ呼び出されることを保証する責任を負うことを期待するかもしれません。もし開発者が同じリソース/ハンドルを複数回リリースしようとすると、APIの期待は満たされず、その結果、未定義かつ/または安全でない動作が発生します。これは、メモリ破壊、データ破壊、実行パスの破壊、またはその他の結果につながる可能性があります。
すべてではないにせよ）ほとんどのリソース予約割り当ての実装では、一意な識別子/ポインタ/シンボリック参照が使われますが、この識別子が再利用された場合、リソースのクローズ時に識別子をチェックすると、誤ったオープン状態になってしまい、間違ったリソースをクローズしてしまう可能性があることに注意してください。このため、識別子の再利用は推奨されない。
The product attempts to close or release a resource or handle more than once, without any successful open between the close operations.
Code typically requires "opening" handles or references to resources such as memory, files, devices, socket connections, services, etc. When the code is finished with using the resource, it is typically expected to "close" or "release" the resource, which indicates to the environment (such as the OS) that the resource can be re-assigned or reused by unrelated processes or actors - or in some cases, within the same process. API functions or other abstractions are often used to perform this release, such as free() or delete() within C/C++, or file-handle close() operations that are used in many languages.
Unfortunately, the implementation or design of such APIs might expect the developer to be responsible for ensuring that such APIs are only called once per release of the resource. If the developer attempts to release the same resource/handle more than once, then the API's expectations are not met, resulting in undefined and/or insecure behavior. This could lead to consequences such as memory corruption, data corruption, execution path corruption, or other consequences.
Note that while the implementation for most (if not all) resource reservation allocations involve a unique identifier/pointer/symbolic reference, then if this identifier is reused, checking the identifier for resource closure may result in a false state of openness and closing of the wrong resource. For this reason, reuse of identifiers is discouraged.