Prevent / recover from a compilation that will / does exhaust the heap

[notmgsk]

Ideally would like the server mode to be indestructible.

[stylewarning]

Is there an example of this @notmgsk ?

[notmgsk]

@stylewarning courtesy of @ecpeterson

Eric Peterson [1:33 PM] /compile CONTROLLED CONTROLLED CONTROLLED CONTROLLED CONTROLLED CONTROLLED CONTROLLED CNOT 8 7 6 5 4 3 2 1 0

[stylewarning]

@notmgsk Is that blowing the stack? Do you have output? I'm running it right now and it's been going for a good while and it hasn't done any damage.

[notmgsk]

@stylewarning

Unhandled SB-KERNEL::HEAP-EXHAUSTED-ERROR in thread #<SB-THREAD:THREAD "RPC-server-thread-0" RUNNING
                                                       {1004CB4483}>:
  Heap exhausted (no more space for allocation).
11960320 bytes available, 16777232 requested.

PROCEED WITH CAUTION.

Backtrace for: #<SB-THREAD:THREAD "RPC-server-thread-0" RUNNING {1004CB4483}>
0: (SB-DEBUG::DEBUGGER-DISABLED-HOOK #<SB-KERNEL::HEAP-EXHAUSTED-ERROR {1000002263}> #<unused argument> :QUIT T)
1: (SB-DEBUG::RUN-HOOK *INVOKE-DEBUGGER-HOOK* #<SB-KERNEL::HEAP-EXHAUSTED-ERROR {1000002263}>)
2: (INVOKE-DEBUGGER #<SB-KERNEL::HEAP-EXHAUSTED-ERROR {1000002263}>)
3: (ERROR #<SB-KERNEL::HEAP-EXHAUSTED-ERROR {1000002263}>)
4: (SB-KERNEL::HEAP-EXHAUSTED-ERROR 5980160 8388616)
5: ("foreign function: call_into_lisp")
6: ("foreign function: funcall2")
7: ("foreign function: gc_heap_exhausted_error_or_lose")
8: ("foreign function: gc_find_freeish_pages")
9: ("foreign function: gc_alloc_large")
10: ("foreign function: alloc")
11: (SB-VM::ALLOC-TRAMP)
12: (SB-IMPL::HASH-TABLE-NEW-VECTORS #<HASH-TABLE :TEST EQL :COUNT 1048575 {1007646683}>)
13: ((FLET SB-THREAD::WITH-RECURSIVE-SYSTEM-LOCK-THUNK :IN SB-IMPL::MAYBE-REHASH))
14: ((FLET "WITHOUT-INTERRUPTS-BODY-67" :IN SB-THREAD::CALL-WITH-RECURSIVE-SYSTEM-LOCK))
15: (SB-THREAD::CALL-WITH-RECURSIVE-SYSTEM-LOCK #<CLOSURE (FLET SB-THREAD::WITH-RECURSIVE-SYSTEM-LOCK-THUNK :IN SB-IMPL::MAYBE-REHASH)
{7EFE2B4E59EB}> #<SB-THREAD:MUTEX "hash-table lock" owner: #<SB-THREAD:THREAD "RPC-server-thread-0" RUNNING {1004CB4483}>>)
16: ((FLET "BODY-FUN-8" :IN SB-KERNEL:%PUTHASH))
17: (SB-KERNEL:%PUTHASH #<CZ 0 1> #<HASH-TABLE :TEST EQL :COUNT 1048575 {1007646683}> T)
18: (CL-QUIL::LSCHEDULER-WALK-GRAPH #<CL-QUIL::LOGICAL-SCHEDULER {1004D99E53}> :BASE-VALUE 0 :BUMP-VALUE NIL :TEST-VALUES NIL)
19: (CL-QUIL::LSCHEDULER-ALL-INSTRUCTIONS #<CL-QUIL::LOGICAL-SCHEDULER {1004D99E53}>)
20: (CL-QUIL::CHIP-SCHEDULE-TO-STRAIGHT-QUIL #<CL-QUIL::CHIP-SCHEDULE {1004AB85D3}>)
21: (CL-QUIL::DO-GREEDY-TEMPORAL-ADDRESSING (#<CONTROLLED CONTROLLED CONTROLLED CONTROLLED CONTROLLED CONTROLLED CONTROLLED CNOT 8 7 6 5 4 3 2 1 0>) #<CL-QUIL::CHIP-SPECIFICATION of 9:36 objects> :ENVIRONS #<CL-QUIL:PARSED-PROGRAM {1004A88103}> :INITIAL-REWIRING #S(CL-$UIL::REWIRING :L2P #(0 1 2 3 4 5 6 7 8) :P2L #(0 1 2 3 4 5 6 7 8)) :USE-FREE-SWAPS T)
22: (CL-QUIL:COMPILER-HOOK #<CL-QUIL:PARSED-PROGRAM {1004A88103}> #<CL-QUIL::CHIP-SPECIFICATION of 9:36 objects> :PROTOQUIL NIL :REWIRI
NG-TYPE NIL)
23: (QUILC::PROCESS-PROGRAM #<CL-QUIL:PARSED-PROGRAM {1004A88103}> #<CL-QUIL::CHIP-SPECIFICATION of 9:36 objects>)
24: (QUILC::QUIL-TO-NATIVE-QUIL #<RPCQ::|NativeQuilRequest|
  quil -> "CONTROLLED CONTROLLED CONTROLLED CONTROLLED CONTROLLED CONTROLLED CONTROLLED CNOT 8 7 6 5 4 3 2 1 0
"
  target_device -> #<RPCQ::|TargetDevice|
  isa -> #<HASH-TABLE :TEST EQUAL :COUNT 2 {1004A68623}>

[ecpeterson]

perhaps this crash is only visible on JQE-grade workstations

[notmgsk]

It is on a pretty meager VPS. Still

[stylewarning]

That's not a stack issue, that's heap exhaustion. Is that what you mean?

[notmgsk]

I never said stack

[stylewarning]

I think we ought to put some nice checks in places that are prone to allocate a bunch, like allocation of matrices or allocation of wavefunctions.