From: "David Allsopp" <David.Allsopp@cl.cam.ac.uk>
To: <cygwin@cygwin.com>
Subject: Debugging malloc crash in gdb
Date: Tue, 18 Oct 2022 11:35:19 +0100 [thread overview]
Message-ID: <000001d8e2dd$51be37a0$f53aa6e0$@cl.cam.ac.uk> (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:
/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*
next 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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='000001d8e2dd$51be37a0$f53aa6e0$@cl.cam.ac.uk' \
--to=david.allsopp@cl.cam.ac.uk \
--cc=cygwin@cygwin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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).