Closed burgholzer closed 1 year ago
To add to that: the same problem also trips up https://github.com/cda-tum/mqt-qcec/blob/1e3f721509f9425f962f1e16cec779c39d26fc75/test/legacy/test_general.cpp#L47-L76
See: https://github.com/cda-tum/mqt-qcec/actions/runs/5956825148/job/16158452626?pr=301#step:8:95
Fixed as part of #301
mqt.qcec version
latest (dates back to earlier versions)
OS
any (bug surfaced on Windows in Debug mode)
Python version
No response
C++ compiler
No response
Additional environment information
No response
Description
While working on improving our CI, the following error has popped up: https://github.com/cda-tum/mqt-qcec/actions/runs/5956825148/job/16158452626?pr=301#step:8:212
Which indicated that some vector is being accessed beyond its bounds. The failure can be traced down to the following method: https://github.com/cda-tum/mqt-qcec/blob/1e3f721509f9425f962f1e16cec779c39d26fc75/src/checker/zx/ZXChecker.cpp#L121-L147
and the problematic line that causes the out-of-bounds access is https://github.com/cda-tum/mqt-qcec/blob/1e3f721509f9425f962f1e16cec779c39d26fc75/src/checker/zx/ZXChecker.cpp#L127
In the IdleQubit test https://github.com/cda-tum/mqt-qcec/blob/1e3f721509f9425f962f1e16cec779c39d26fc75/test/test_zx.cpp#L380-L411 the second circuit has an idle qubit (
q[3]
) that is removed from the circuit as part of the ECM creation. This leaves the circuit with qubits0, 1, 2, 4
. Now, somewhere along the process, this gap in the number of qubits comes in and the problematic line above is called withk==4
andv==3
.Expected behavior
No out-of-bounds access should ever happen
How to Reproduce
Run the
IdleQubit
test from theZXTest
suite in Debug mode (easiest under Windows because that explicitly adds bounds checks). Otherwise, work with debug prints, etc.