Segfault on OOM Failure?

[ghost]

I wanted to test what happened when wren was pushed to it's limits so I wrote the following script, test.wren:

var l = ["banana"]
while (true) {
    l.add("banana")
}

to generate out-of-memory conditions for the CLI VM.

Running the script on a fresh build of the CLI I get:

$ ./wren test.wren 
Segmentation fault (core dumped)

I would expect something like Java's OutOfMemoryError or Python's MemoryError to bubble up to the user, or at the very least have a somewhat graceful abort, rather than a segmentation fault.

Tested on:

• commit: d1a0d0682ac072fa20f2dcca356dac06565e93a1
• OS: Ubuntu MATE 18.04
• hardware info:

  $ lscpu
  Architecture:        x86_64
  CPU op-mode(s):      32-bit, 64-bit
  Byte Order:          Little Endian
  CPU(s):              2
  On-line CPU(s) list: 0,1
  Thread(s) per core:  1
  Core(s) per socket:  2
  Socket(s):           1
  NUMA node(s):        1
  Vendor ID:           GenuineIntel
  CPU family:          6
  Model:               122
  Model name:          Intel(R) Celeron(R) N4000 CPU @ 1.10GHz
  Stepping:            1
  CPU MHz:             2422.418
  CPU max MHz:         2600.0000
  CPU min MHz:         800.0000
  BogoMIPS:            2188.80
  Virtualization:      VT-x
  L1d cache:           24K
  L1i cache:           32K
  L2 cache:            4096K
  NUMA node0 CPU(s):   0,1
  Flags:               fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg cx16 xtpr pdcm sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave rdrand lahf_lm 3dnowprefetch cpuid_fault cat_l2 pti cdp_l2 ssbd ibrs ibpb stibp ibrs_enhanced tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust smep erms mpx rdt_a rdseed smap clflushopt intel_pt sha_ni xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts umip rdpid md_clear arch_capabilities

  $ cat /proc/meminfo | grep 'MemTotal'
  MemTotal:        3850880 kB

[mhermier]

Error is trivial, code doesn't check if list's array gets properly resized.

[ruby0x1]

We can definitely add an OOM error in debug mode! It has interesting implications when the user is the one in control of the allocations, i.e if the config is specifying a realloc function where exactly the check is handled and how it propagates to the user is an unknown.

[mhermier]

Not sure if it is the right way to think. I mean it is an error that is expected to happen at run-time, unless you can always control what you feed the system with. So considering a debugging feature is an error to me. That said handling it gracefully is a huge topic, that might imply we way need to rethink error handling in the VM.

[ghost]

Given that users can use their own allocator, potential OOM error could be propigated back up the call stack for every bad alloc or allocations could call some sort of user-defined handler whenever there is bad alloc.

I've seen both methods used in library code. The former requires a lot of boilerplate error handling code, which can get complex and a bit confusing. The latter allows you to assume allocs are good and just defer to a handler otherwise, perhaps some sort of setjmp/longjump mechanism, but can lead to memory leaks unless there is a way to cleanup resources.

I'm not sure if either of these might be good ways to handle OOM or other panic-worthy conditions, but they're ideas none the less.

[mhermier]

I thought about set/longjmp since a while. But I wonder about portability and possible errors due to partially initialised values.