delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2022/10/18/06:35:48

X-Recipient: archive-cygwin AT delorie DOT com
X-Original-To: cygwin AT cygwin DOT com
Delivered-To: cygwin AT cygwin DOT com
DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 25FC23857432
Authentication-Results: sourceware.org;
dmarc=fail (p=none dis=none) header.from=cl.cam.ac.uk
Authentication-Results: sourceware.org;
spf=pass smtp.mailfrom=return.smtpservice.net
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
d=smtpservice.net; s=md6hz0.a1-4.dyn; x=1666090182; h=Feedback-ID:
X-Smtpcorp-Track:Message-ID:Date:Subject:To:From:Reply-To:Sender:
List-Unsubscribe; bh=uKYPqExR4RGcY7iyAaGx4p8cVvA9Z3bh197SmH7k+7s=; b=X3cF7KwE
wEFyeKbhuq1MMk905uSKhorvbmDdQ9S3SrA7i+vbF1FCGbHz+16RkYFY5lF/3CdrzkYLdGywQfrcH
qum4Zn/rJXUB9wiRoA/n9LZUd6zZfmvjFJpjlvqRlIymegn59u3yASL9ANIYVYqrmsoZQkY9HT85q
30aLXj6sn7t6Jwj0k/JmjuVzMbuSrKD9HahJbdf3gM6KNX89cVzm9UQyfOA+l9dyPO912qx1xDavu
HJ0HNJtQBcwEHPl1CZxJ3VxzayKek+/i2hJf6QEM9T3/b5qD3+pBQkBzknBcX8pwf+myaki76lJvl
nhZbT9I/RdDbxaHacRKfaXwTqw==;
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
X-Mailer: Microsoft Outlook 16.0
Thread-Index: Adji3Qq+OheDNzUWQ+SUSPnwrLIncw==
X-Scanned-By: MIMEDefang 2.65 on 62.31.23.242
X-Smtpcorp-Track: 1okMvk9EWg8x0N.TMFURANnF7e21
Feedback-ID: 614951m:614951apMmpqs:614951sd4jvghCq-
X-Report-Abuse: Please forward a copy of this message, including all headers,
to <abuse-report AT smtp2go DOT com>
X-Spam-Status: No, score=1.7 required=5.0 tests=BAYES_05, DKIM_INVALID,
DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, SPF_HELO_PASS,
SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.6
X-Spam-Level: *
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
server2.sourceware.org
X-BeenThere: cygwin AT cygwin DOT com
X-Mailman-Version: 2.1.29
List-Id: General Cygwin discussions and problem reports <cygwin.cygwin.com>
List-Archive: <https://cygwin.com/pipermail/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-request AT cygwin DOT com?subject=help>
List-Subscribe: <https://cygwin.com/mailman/listinfo/cygwin>,
<mailto:cygwin-request AT cygwin DOT com?subject=subscribe>
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

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019