DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 5B03A3858CDA
Message-ID: <20435aae-2753-d49f-2de6-94a4ac624813@dronecode.org.uk>
Date: Wed, 2 Nov 2022 12:38:06 +0000
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.4.1
Subject: Re: Debugging malloc crash in gdb
Content-Language: en-GB
To: David Allsopp <david@tarides.com>,
        The Cygwin Mailing List <cygwin@cygwin.com>
References: <000001d8e2dd$51be37a0$f53aa6e0$@cl.cam.ac.uk>
 <f4e9c183-a4b5-7c59-c608-9922beb76961@dronecode.org.uk>
 <CAJQQdJhkJrzJaGVNnbQNqHSDeq1kaXLt5AOXCk3akszCjp=jLA@mail.gmail.com>
From: Jon Turney <jon.turney@dronecode.org.uk>
In-Reply-To: <CAJQQdJhkJrzJaGVNnbQNqHSDeq1kaXLt5AOXCk3akszCjp=jLA@mail.gmail.com>
Precedence: list
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Errors-To: cygwin-bounces+archive-cygwin=delorie.com@cygwin.com
Sender: "Cygwin" <cygwin-bounces+archive-cygwin=delorie.com@cygwin.com>

On 20/10/2022 09:22, 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.
[...]>>> 
/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?

That depends.

Is the ocaml code relying on undefined behaviour, which just happens to 
work elsewhere, but fails on cygwin? Or is it defined behaviour, which 
Cygwin doesn't implement correctly?

(It's not unreasonable that Cygwin's memory allocator is more sensitive 
to some classes of errors than other implementations)


-- 
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