DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 25FC23857432
From: "David Allsopp" <David DOT Allsopp AT cl DOT cam DOT ac DOT uk>
To: <cygwin AT cygwin DOT com>
Subject: Debugging malloc crash in gdb
Date: Tue, 18 Oct 2022 11:35:19 +0100
Organization: University of Cambridge
Message-ID: <000001d8e2dd$51be37a0$f53aa6e0$@cl.cam.ac.uk>
MIME-Version: 1.0
Thread-Index: Adji3Qq+OheDNzUWQ+SUSPnwrLIncw==
Content-Language: en-gb
Feedback-ID: 614951m:614951apMmpqs:614951sd4jvghCq-
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: "Cygwin" <cygwin-bounces+archive-cygwin=delorie DOT com AT cygwin DOT com>

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:

 
/cygdrive/d/a/scallywag/gdb/gdb-11.2-1.x86_64/src/gdb-11.2/gdb/infrun.c:2550
: 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
arena
- 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
segfaults.

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!

Thanks,


David


---
Full repro instructions

Cygwin packages required: gcc-core, make, flexdll

Build:
  git clone https://github.com/dra27/ocaml -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/gc_set.ml -o gc_set.byte.exe

Crash:
  runtime/ocamlrun.exe ./gc_set.byte.exe

Debug:
  OCAMLRUNPARAM=v=0x1FFF gdb runtime/ocamlrun.exe
  break caml_gc_get
  run ./gc_set.byte.exe
  continue
  break alloc_generic_table
  continue
  break caml_stat_alloc_noexc
  continue
  step
  step
  step
  *boom*


-- 
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple