quantastica / quantum-circuit

Quantum Circuit Simulator implemented in JavaScript
MIT License
247 stars 49 forks source link

Long Identifiers(?) Crash when Importing from QASM #85

Closed DanBlackwell closed 5 months ago

DanBlackwell commented 5 months ago

I get an odd crash when importing QASM where there is a register with a long identifier. To reproduce the following code works:

const QuantumCircuit = require('quantum-circuit');

let qc = new QuantumCircuit();
let qasm = "OPENQASM 2.0;\n" +
           "include \"qelib1.inc\";\n" +
           "gate cphase_281472532(param0) q0,q1 {  }\n" +
           "qreg r1[2];\n" +
           "cphase_281472532() r1[1],r1[0];";

qc.importQASM(qasm, (error) => {
    qc.run();
})

And produces this stack trace:


<--- Last few GCs --->

[32091:0xaaaaee353860]     1369 ms: Scavenge 1163.0 (1196.4) -> 1163.0 (1196.4) MB, 32.7 / 0.0 ms  (average mu = 1.000, current mu = 1.000) allocation failure
[32091:0xaaaaee353860]     2255 ms: Mark-sweep 1736.9 (1770.2) -> 1723.7 (1758.4) MB, 471.0 / 0.7 ms  (+ 18.4 ms in 10 steps since start of marking, biggest step 7.5 ms, walltime since start of marking 1757 ms) (average mu = 0.751, current mu = 0.751) all

<--- JS stacktrace --->

==== JS stack trace =========================================

    0: ExitFrame [pc: 0xffffad358dec]
Security context: 0x0000256db9a1 <JSObject>
    1: /* anonymous */ [0x5d6cb839] [/python_js_test/node_modules/quantum-circuit/lib/quantum-circuit.js:~6162] [pc=0x28576888](this=0x0000347454e1 <QuantumCircuit map = 0xffffa24dee39>,0x0000385666b1 <String[#16]: cphase_281472532>)
    2: /* anonymous */ [0x5d6cb8b9] [/python_js_test/node_modules/quantum-circuit/lib/quantum-circuit.js:6237] [bytecode=0x385...

FATAL ERROR: invalid array length Allocation failed - JavaScript heap out of memory
 1: 0xffffac5df720 node::Abort() [/lib/aarch64-linux-gnu/libnode.so.72]
 2: 0xffffac5218d8 std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > node::SPrintF<>(char const*) [/lib/aarch64-linux-gnu/libnode.so.72]
 3: 0xffffac8fded8 v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [/lib/aarch64-linux-gnu/libnode.so.72]
 4: 0xffffac8fe08c v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [/lib/aarch64-linux-gnu/libnode.so.72]
 5: 0xffffaca9e668  [/lib/aarch64-linux-gnu/libnode.so.72]
 6: 0xffffaca7925c v8::internal::Factory::AllocateRawFixedArray(int, v8::internal::AllocationType) [/lib/aarch64-linux-gnu/libnode.so.72]
 7: 0xffffaca79710 v8::internal::Factory::NewFixedArrayWithFiller(v8::internal::RootIndex, int, v8::internal::Object, v8::internal::AllocationType) [/lib/aarch64-linux-gnu/libnode.so.72]
 8: 0xffffaca7a008 v8::internal::Factory::NewUninitializedFixedArray(int, v8::internal::AllocationType) [/lib/aarch64-linux-gnu/libnode.so.72]
 9: 0xffffacbd45a0  [/lib/aarch64-linux-gnu/libnode.so.72]
10: 0xffffacd73474 v8::internal::Runtime_GrowArrayElements(int, unsigned long*, v8::internal::Isolate*) [/lib/aarch64-linux-gnu/libnode.so.72]
11: 0xffffad358dec  [/lib/aarch64-linux-gnu/libnode.so.72]
Aborted

Oddly, it seems that changing the identifier from cphase_281472532 to cphase_28147253 makes the code run fine. It seems there's some code splitting at the _ so perhaps this is expected behaviour?

perak commented 5 months ago

@DanBlackwell thank you for reporting this! Will be fixed ASAP.

perak commented 5 months ago

@DanBlackwell fixed. Thank you again for reporting the issue!