public inbox for
 help / color / mirror / Atom feed
From: "David Allsopp" <>
To: <>
Subject: Debugging malloc crash in gdb
Date: Tue, 18 Oct 2022 11:35:19 +0100	[thread overview]
Message-ID: <000001d8e2dd$51be37a0$f53aa6e0$> (raw)

I'm wondering if I may be able to have some pointers for debugging what
seems to be an unexpected interaction between mmap/mprotect/munmap and
malloc with the OCaml runtime.

At the moment, I know that we crash in malloc, so my main question is how to
go further in gdb. I installed the cygwin-debuginfo package, but all I'm
getting is:

: internal-error: void resume_1(gdb_signal): Assertion
`pc_in_thread_step_range (pc, tp)' failed.

The reproduction case is below (it's the OCaml runtime, so it's not exactly
minimal, but it seems to be very repeatable to get gdb to the position of
the crash).

In terms of memory, what OCaml is doing:

- At startup, 256M of address space is reserved (with mmap) for garbage
collected minor heaps ("minor arena")
- The first 2M of this is "committed" with mprotect for use by the program's
main thread
- The program then instructs the runtime to double the size of the minor
- The 2M portion is "decommitted" with mprotect
- The 256M mmap'd region is munmap'd
- A new 512M region of address space is reserved
- The first 4M of this is "committed" with mprotect for use by the program's
main thread
- The program performs some assertion checks
- Book-keeping at the end of this causes malloc to be called, which

The crashing call to malloc is the first call to malloc since the 256M ->
512M munmap/map dance.

If the call to caml_mem_unmap at the end of unreserve_minor_heaps in
runtime/domain.c is omitted, then this program succeeds - i.e. malloc does
not appear to crash if the 256M region is left mapped. Obviously, I realise
this may well be unrelated to what's going wrong.

Any assistance to debug this further hugely appreciated!



Full repro instructions

Cygwin packages required: gcc-core, make, flexdll

  git clone -b restore-cygwin-break --depth 1
  cd ocaml
  ./configure --disable-native-compiler --disable-debugger
--disable-ocamldoc && make -j
  runtime/ocamlrun.exe ./ocamlc.exe -nostdlib -I stdlib
testsuite/tests/regression/pr9326/ -o gc_set.byte.exe

  runtime/ocamlrun.exe ./gc_set.byte.exe

  OCAMLRUNPARAM=v=0x1FFF gdb runtime/ocamlrun.exe
  break caml_gc_get
  run ./gc_set.byte.exe
  break alloc_generic_table
  break caml_stat_alloc_noexc

             reply	other threads:[~2022-10-18 10:34 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-18 10:35 David Allsopp [this message]
2022-10-18 19:08 ` Jon Turney
2022-10-19  6:20   ` Ariel Burbaickij
2022-11-02 12:38     ` Jon Turney
2022-11-02 13:24       ` Ariel Burbaickij
2022-10-20  8:22   ` David Allsopp
2022-10-20  9:38     ` Ariel Burbaickij
2022-11-02 12:38     ` Jon Turney

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='000001d8e2dd$51be37a0$f53aa6e0$' \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).