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

Previous Next

Full log

Message #74 received at 74805 <at> debbugs.gnu.org (full text, mbox):

From: Ken Brown <kbrown <at> cornell.edu>
To: Richard Brooksby <rb <at> ravenbrook.com>, Eli Zaretskii <eliz <at> gnu.org>
Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>,
 74805 <at> debbugs.gnu.org, Pip Cet <pipcet <at> protonmail.com>
Subject: Re: bug#74805: 30.0.92; Trying to build scratch/igc on Cygwin
Date: Tue, 21 Jan 2025 15:07:06 -0500

On 12/23/2024 6:32 PM, Ken Brown wrote:
> On 12/22/2024 3:32 AM, Richard Brooksby wrote:
>> On 2024-12-22 08:24, Richard Brooksby wrote:
>>> On 2024-12-21 16:56, Ken Brown wrote:
>>>> 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.
>>>
>>> Hello.  I can't offer much direct help just now, but here's where I'd 
>>> start.
>> ...
>>  > It's very unlikely that you're actually running out of address 
>> space on a 64-bit system.
>>
>> I should add that arenacv is a coverage test that is *trying* to 
>> provoke the ResRESOURCE error paths in some circumstances https:// 
>> github.com/ Ravenbrook/mps/ 
>> blob/9fd0577cf1231e61c9801c81499e5d16d0743806/code/ arenacv.c#L461 but 
>> note that this isn't where the test is failing. However, it may be 
>> relevant, perhaps if your munmap doesn't successfully free address space.
> Thanks!  You've given me some good hints.
Here's the latest update on my attempts.  The good news is that I've 
been running a build from the igc branch with no noticeable problems. 
The bad news is that I am unable to debug the failing arenacv test.  I 
have no idea how critical this is from the point of view of the igc branch.

What follows is a very long description of my debugging efforts, in the 
hopes that someone familiar with the MPS code can help.

1. Of all the tests called in arenacv.c:main(), the only one that fails 
is this one:

  testPageTable((ArenaClass)mps_arena_class_cl(), TEST_ARENA_SIZE, 
block, FALSE)

at line 481.

2. Of the two calls to testAllocAndIterate in testPageTable, it's only 
the second one that fails, provided I apply the following patch:

--- a/code/arenacv.c
+++ b/code/arenacv.c
@@ -333,6 +333,7 @@ static void testAllocAndIterate(Arena arena, Pool pool,
   Count offset, gap, new;
   ZoneSet zone = (ZoneSet)2;
   int i;
+  mps_res_t res;

   LocusPrefInit(&pref);

@@ -353,8 +354,14 @@ static void testAllocAndIterate(Arena arena, Pool pool,
             "offsetRegion");
       for(gap = numPerPage+1; gap <= 3 * (numPerPage+1);
           gap += (numPerPage+1)) {
-        die(allocator->alloc(&gapRegion, &pref, gap * pageSize, pool),
-            "gapRegion");
+       res = allocator->alloc(&gapRegion, &pref, gap * pageSize, pool);
+       if (res != ResOK) {
+         fprintf(stdout, "res = %d, gap = %lu, offset = %lu, i = %d\n",
+                 res, gap, offset, i);
+         die(res, "gapRegion");
+       }
+        /* die(allocator->alloc(&gapRegion, &pref, gap * pageSize, 
pool), */
+        /*     "gapRegion"); */
         die(allocator->alloc(&topRegion, &pref, pageSize, pool),
             "topRegion");
         allocator->free(&gapRegion);
@@ -473,8 +480,8 @@ int main(int argc, char *argv[])

   testlib_init(argc, argv);

-  testPageTable((ArenaClass)mps_arena_class_vm(), TEST_ARENA_SIZE, 0, 
TRUE);
-  testPageTable((ArenaClass)mps_arena_class_vm(), TEST_ARENA_SIZE, 0, 
FALSE);
+  /* testPageTable((ArenaClass)mps_arena_class_vm(), TEST_ARENA_SIZE, 
0, TRUE); */
+  /* testPageTable((ArenaClass)mps_arena_class_vm(), TEST_ARENA_SIZE, 
0, FALSE); */

   block = malloc(TEST_ARENA_SIZE);
   cdie(block != NULL, "malloc");


If I don't apply that patch then the first call fails (and of course the 
second one doesn't get run).  I can't make sense out of that.

3. After I apply the patch, there are no calls to mmap or munmap 
(according to strace) except an initial call to mmap when the code calls 
malloc.  [This is an internal implementation detail, that Cygwin uses 
mmap in malloc.]  If I don't apply that patch, there are lots of calls 
to both, all of which succeed.  I don't understand why the code is not 
calling mmap/munmap when the patch is applied.  How else could it be 
trying to acquire address space?

4. When testAllocAndIterate fails, it's at the very first iteration 
through the loops.  In other words, i = 0, offset = 0, and gap = 
numPerPage = 2731.

5. The failure can be traced to PolicyAlloc() returning ResRESOURCE at 
policy.c:126.  Unfortunately, there are about 7 calls to 
ArenaFreeLandAlloc that have to *all* fail before we reach line 126.  I 
tried stepping through all 7 of them in the failure case, but, being 
completely unfamiliar with the code, I couldn't see what was happening.

6. Here's the backtrace when we reach policy.c:126 (in a run without the 
patch above):

#0  PolicyAlloc (tractReturn=0x7ffffc760, arena=0x6ffffbff0010,
    pref=0x7ffffc870, size=178978816, pool=0x6ffffc030248) at policy.c:126
#1  0x0000000100407852 in ArenaAlloc (baseReturn=0x7ffffc7f0, 
pref=0x7ffffc870,
    size=178978816, pool=0x6ffffc030248) at arena.c:1092
#2  0x000000010040135c in allocAsTract (aiReturn=0x7ffffc8d0, 
pref=0x7ffffc870,
    size=178978816, pool=0x6ffffc030248) at arenacv.c:164
#3  0x000000010040181c in testAllocAndIterate (arena=0x6ffffbff0010,
    pool=0x6ffffc030248, pageSize=65536, numPerPage=2730,
    allocator=0x10048e020 <allocatorTractStruct>) at arenacv.c:356
#4  0x0000000100401d46 in testPageTable (
    klass=0x1004b0180 <ClassStaticClientArena>, size=67108864,
    addr=0x6ffffbff0010, zoned=0) at arenacv.c:425
#5  0x0000000100401fc3 in main (argc=1, argv=0xa000017b0) at arenacv.c:481


Thanks in advance to anyone who has ideas about this.

Ken

Previous Next

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