Very large crunches can possibly overflow the Xen static segments

[avsm]

The openmirage.org site is occasionally rebooting (and coming up again quite fast). Upon inspection, the domain crash looks like this:

(XEN) domain_crash_sync called from entry.S
(XEN) Domain 793 (vcpu#0) crashed on cpu#8:
(XEN) ----[ Xen-4.1.4  x86_64  debug=n  Not tainted ]----
(XEN) CPU:    8
(XEN) RIP:    e033:[<00000000001fb929>]
(XEN) RFLAGS: 0000000000010206   EM: 1   CONTEXT: pv guest
(XEN) rax: 00000000001fb350   rbx: 000000000024f0f8   rcx: 0000000000000001
(XEN) rdx: 0000000000000000   rsi: 0000000000000003   rdi: 000000000024f0f8
(XEN) rbp: 000000000086f970   rsp: 000000000024efe8   r8:  0000000010624dd3
(XEN) r9:  00000000d5dcf6dd   r10: 0000000000000000   r11: 0000000000826a40
(XEN) r12: 0000000000000000   r13: 00000000019ea0d8   r14: 000000000086fb10
(XEN) r15: 00000000019e9cb8   cr0: 0000000080050033   cr4: 00000000000026f0
(XEN) cr3: 00000003fde57000   cr2: 000000000024eff8
(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: e02b   cs: e033

The instruction pointer is at:

(gdb) x/i 0xe033
   0xe033 <camlStatic2__size_1974+2707>:        jo,pn  0xe0a4 <camlStatic2__size_1974+2820>
(gdb) 

which is a function call in static2.ml, which is actually the crunched file system. So I suspect that the mirage site content has just become a little too large for the static memory map that we gave it, hence the crashing. /cc @talex5 in case he has any idea if this changed in minios recently.

[avsm]

Confirmed to be because of too large a crunch, e.g. in the changelog.md file

[hannesm]

it would be great if there is a way to automatically detect this and error out early (instead of silently crashing, as it did for me)

[cfcs]

I seem to have this issue, it's really annoying. I can work around it by creating smaller files, but that is a bit hacky. Consider this stuff required to play the Tetris soundtrack on QubesOS (just embedding tetris.wav made the Mirage_kv_lwt.RO.read function hang with 100% CPU, with a filesize of ~16 MB):

      read_chunk "tetris01.wav" >>= play_wav >>= fun () ->
      read_chunk "tetris02.wav" >>= play_wav >>= fun () ->
      read_chunk "tetris03.wav" >>= play_wav >>= fun () ->
      read_chunk "tetris04.wav" >>= play_wav >>= fun () ->

[avsm]

Yeah, we need to detect this statically in the backend-specific linker script (it'll be different between xen and solo5 for example)