Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Very large crunches can possibly overflow the Xen static segments #396

Open
avsm opened this issue May 1, 2015 · 4 comments
Open

Very large crunches can possibly overflow the Xen static segments #396

avsm opened this issue May 1, 2015 · 4 comments
Labels

Comments

@avsm
Copy link
Member

avsm commented May 1, 2015

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
Copy link
Member Author

avsm commented May 2, 2015

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

@hannesm
Copy link
Member

hannesm commented Apr 14, 2016

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)

@yomimono yomimono added the bug label Nov 17, 2017
@cfcs
Copy link

cfcs commented Jan 2, 2018

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
Copy link
Member Author

avsm commented Jan 2, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants