From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oo1-xc35.google.com (mail-oo1-xc35.google.com [IPv6:2607:f8b0:4864:20::c35]) by sourceware.org (Postfix) with ESMTPS id A71A23839DCE for ; Thu, 20 Oct 2022 09:39:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A71A23839DCE Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-oo1-xc35.google.com with SMTP id c187-20020a4a4fc4000000b004808e2f7affso3894063oob.13 for ; Thu, 20 Oct 2022 02:39:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=hp9ygYqCSeIRsmDimgtv6AZe5djxWQ+alytph5ujq7Q=; b=dzYNKNmA0w5cpcXlqyLc45PtGz+bCoHCPzdzFBu/66vixXm2ChvzsmsFyI0V/rZCcE QQuI9Lu10/M7rkJeDTY19MgR6I9esHEwptVSNvGMLUyshS9iT/kVacXl03Al7E0Kd20U aYO8Hw30HRa3ztuqfIw4rLhs2qkSdkesJCTOdYAGts0nh2Yh4OTpO/obNo8s5K0KQoRI Fb+XQ6nA834NyGPySrSazSgbRQDUrs0rZ5gYgLRN3eAyXz8N/7Bgo08pwGLc9+mbls2M /pmnj/5ummKQlniX3JDxzC/uDs4JxZ8q56Rse39XbgNE7puzgBgWciDd5kKUgbAemPsZ OqMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=hp9ygYqCSeIRsmDimgtv6AZe5djxWQ+alytph5ujq7Q=; b=dIao9fJsEUDHGQ9X6gMdHxs3jiznfIX4g+ezEmbgGKwib1WymYzHHUEk31oW/ybmjx 6QLJJftKCgdhvEGGfAwApDdMiGVKYNUvSVDdGCPV/5M/Llj/RGSIbWu6LfWT57u7Zbkr Ly7ilh2shzvZN+4cnHPdFQct3XoGtt2kTJ1poyT4fBpzxVJe9wozhs3o2oMbEevkw9fq wOcqUwdDI+GtrdcDps7/61OP3KFMkHbIfAThxhtKwI6qdHRde7LHNrNYq7xEDTJyLiif ufN4WJVOzKH6QQSzh3guSXeh+pJMAoVLULVNWDmMGK3UG2DIWxvj0GyYJSkmMgKHeD6q I+rg== X-Gm-Message-State: ACrzQf30JGN4f7/rwJYqh2OqgBXol1GRlx3nnPLrsujE99zOteCZnG2Z whAAedc24R353N/ecTwujTGZjylilvC9m7iQ/no= X-Google-Smtp-Source: AMsMyM433Z5fnKP/HM+qUTo8bUiSE5W8n8mXiMxAFnVZxGr4HM8cmFO1RmwC4ad8bdBWaBA8MMJOTec4RaJMdWvPX6c= X-Received: by 2002:a4a:c20e:0:b0:476:59ad:b02b with SMTP id z14-20020a4ac20e000000b0047659adb02bmr5876159oop.65.1666258741820; Thu, 20 Oct 2022 02:39:01 -0700 (PDT) MIME-Version: 1.0 References: <000001d8e2dd$51be37a0$f53aa6e0$@cl.cam.ac.uk> In-Reply-To: From: Ariel Burbaickij Date: Thu, 20 Oct 2022 11:38:51 +0200 Message-ID: Subject: Re: Debugging malloc crash in gdb To: David Allsopp Cc: Jon Turney , The Cygwin Mailing List Content-Type: multipart/alternative; boundary="00000000000069006605eb741834" X-Spam-Status: No, score=-1.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: --00000000000069006605eb741834 Content-Type: text/plain; charset="UTF-8" Hello David, congrats on your bug fixing but gdb is pretty open that it considers it as its own bug while running its "inferior", somewhere here: if (tp->control.may_range_step) { /* If we're resuming a thread with the PC out of the step range, then we're doing some nested/finer run control operation, like stepping the thread out of the dynamic linker or the displaced stepping scratch pad. We shouldn't have allowed a range step then. */ gdb_assert (pc_in_thread_step_range (pc, tp)); } whatever the logic behind setting may_range_step might be, it is (or should be) as much decoupled from all the probable bugs in allocators of all the possible flavours. So, it should be investigated from the side of gdb maintainers too, for sure, as I see it. Kind Regards Ariel Burbaickij On Thu, Oct 20, 2022 at 10:22 AM David Allsopp wrote: > On Tue, 18 Oct 2022 at 20:09, Jon Turney wrote: > > > > On 18/10/2022 11:35, David Allsopp wrote: > > > 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: > > > > Firstly, if the crash is inside the cygwin DLL, you must follow the > > advice in [1], and use 'set cygwin-exceptions on' to tell gdb to stop on > > an exception inside cygwin itself. > > > > [1] https://cygwin.com/faq.html#faq.programming.debugging-cygwin > > > > > > > > /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. > > I'm not sure now which combination of stepping directly into the > malloc call, adding set cygwin-exceptions on or switching to gdb 12.1, > but either way I was able to get to an invalid memory access in > mmap_alloc in malloc.cc. At this point, p was a pointer to the start > of the 256M block which had been passed to munmap. > > What I then noticed from that is a bug in our code - the mmap'd region > was actually 256M+64K but the size passed to munmap was 256M... so the > munmap call was not releasing the entire block. Fixing that on the > OCaml side fixes the error completely - I don't know whether what we > were seeing before counts as a bug in Cygwin's allocator? > > Many thanks! > > > David > > -- > 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 > --00000000000069006605eb741834--