GNU bug report logs - #74805
30.0.92; Trying to build scratch/igc on Cygwin

Previous Next

Full log

View this message in rfc822 format

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Ken Brown <kbrown <at> cornell.edu>
Cc: 74805 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, Pip Cet <pipcet <at> protonmail.com>, rb <at> ravenbrook.com
Subject: bug#74805: 30.0.92; Trying to build scratch/igc on Cygwin
Date: Sat, 21 Dec 2024 18:21:53 +0100

Ken Brown <kbrown <at> cornell.edu> writes:

> On 12/21/2024 2:24 AM, Eli Zaretskii wrote:
>>> Date: Fri, 20 Dec 2024 18:48:37 -0500
>>> Cc: 74805 <at> debbugs.gnu.org, Richard Brooksby <rb <at> ravenbrook.com>
>>> From: Ken Brown <kbrown <at> cornell.edu>
>>> 3. The "mmap" branch is a straightforward port, mostly imitating the
>>> FreeBSD port.  It currently (with Cygwin 3.5.5) fails because of a
>>> limitation of Cygwin's mmap.  But I have a simple patch to Cygwin in the
>>> works that removes that limitation.  With that patch, 37 of the 38 MPS
>>> tests pass.  I still need to debug the failing test.  I'm cautiously
>>> optimistic that I can get this approach to work.  Either way, I expect
>>> the Cygwin patch to soon be available in a test release of Cygwin 3.6.0
>>> so that other Cygwin users can try it.
>> Thanks for the update, I think this is very good news.
>
> I could use some help from the MPS experts in debugging the failing
> test, which is arenacv.  I ran the test under strace and didn't see
> any mmap or munmap failures.  I'm attaching the test log, which
> doesn't mean a thing to me.  I also built an unoptimized arenacv and
> can run it under gdb if someone tells me what to look for.
>
> TIA.
>
> Ken

Hi Ken.

I'm not an MPS internals expert, but AFAICT, this likely comes from here
in arenacv.c, but without being able to debug this, I find it hard to
tell what's going on in the allocator->alloc.

static void testAllocAndIterate(Arena arena, Pool pool,
                                Size pageSize, Count numPerPage,
                                AllocatorClass allocator)
{
  AllocInfoStruct offsetRegion, gapRegion, newRegion, topRegion;
  LocusPrefStruct pref;
  Count offset, gap, new;
  ZoneSet zone = (ZoneSet)2;
  int i;

  LocusPrefInit(&pref);

  /* Testing the behaviour with various sizes of gaps in the page table. */

  /* Assume the allocation strategy is first-fit.  The idea of the tests is */
  /* to allocate a region of memory, then deallocate a gap in the middle, */
  /* then allocate a new region that fits in the gap with various amounts */
  /* left over.  Like this: */
  /* |-offsetRegion-||----gapRegion----||-topRegion-| */
  /* |-offsetRegion-||-newRegion-|      |-topRegion-| */
  /* This is done with three different sizes of offsetRegion, in two */
  /* different zones to ensure that all page boundary cases are tested. */
  for(i = 0; i < 2; ++i) { /* zone loop */
    for(offset = 0; offset <= 2*numPerPage; offset += numPerPage) {
      if(offset != 0)
        die(allocator->alloc(&offsetRegion, &pref, offset * pageSize, pool),
            "offsetRegion");
      for(gap = numPerPage+1; gap <= 3 * (numPerPage+1);
          gap += (numPerPage+1)) {
        die(allocator->alloc(&gapRegion, &pref, gap * pageSize, pool),
            ^^^^^^^^^^^^^^^^
            "gapRegion");

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.