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

Previous Next

Full log

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

From: Ken Brown <kbrown <at> cornell.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: gerd.moellmann <at> gmail.com, 74805 <at> debbugs.gnu.org, pipcet <at> protonmail.com,
 rb <at> ravenbrook.com
Subject: Re: bug#74805: 30.0.92; Trying to build scratch/igc on Cygwin
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 <kbrown <at> cornell.edu>
>> Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>,
>>   74805 <at> debbugs.gnu.org, Pip Cet <pipcet <at> protonmail.com>
>>
>> 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

Previous Next

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