From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from e2i251.smtp2go.com (e2i251.smtp2go.com [103.2.140.251]) by sourceware.org (Postfix) with ESMTPS id 25FC23857432 for ; Tue, 18 Oct 2022 10:34:42 +0000 (GMT) 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==; Received: from [10.176.58.103] (helo=SmtpCorp) by smtpcorp.com with esmtpsa (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.94.2-S2G) (envelope-from ) id 1okjvk-Y8PHs7-Bq for cygwin@cygwin.com; Tue, 18 Oct 2022 10:34:40 +0000 Received: from [10.62.31.23] (helo=romulus.metastack.com) by smtpcorp.com with esmtpsa (TLS1.0:DHE_CUSTOM__RSA_SHA1__AES_256_CBC__SHA1:256) (Exim 4.96-S2G) (envelope-from ) id 1okjvk-9EWg8x-0N for cygwin@cygwin.com; Tue, 18 Oct 2022 10:34:40 +0000 Received: from Thor ([172.16.0.127]) (authenticated bits=0) by romulus.metastack.com (8.14.2/8.14.2) with ESMTP id 29IAYcvC017610 for ; Tue, 18 Oct 2022 11:34:38 +0100 From: "David Allsopp" To: 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 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: Adji3Qq+OheDNzUWQ+SUSPnwrLIncw== Content-Language: en-gb 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 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 List-Id: 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*