Subject: bug#74805: 30.0.92; Trying to build scratch/igc on Cygwin

From: Ken Brown <[email-masked]>
Date: Mon, 27 Jan 2025 11:20:24 -0500

On 1/22/2025 7:43 AM, Eli Zaretskii wrote:
>> Date: Tue, 21 Jan 2025 15:07:06 -0500
>> From: Ken Brown <[email-masked]>
>> Cc: Gerd Möllmann <[email-masked]>,
>>   [email-masked], Pip Cet <[email-masked]>
>>
>> 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.
> 
> That _is_ good news, thanks.
> 
>> 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?
> 
> A stab in the dark: could it be that the call to fprintf you added in
> the patch causes malloc to be called from fprintf, and thus changes
> the state of malloc and/or the arena in a way that causes the above
> unexpected effects?  Can you try using a different print-out function
> instead that is guaranteed not to allocate any memory?

Thanks, but that doesn't explain it.  I tried simply removing the call 
to fprintf, but the strace output still shows no calls to mmap or 
munmap.  Very strange.

Ken