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

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ken Brown <kbrown <at> cornell.edu>
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: Wed, 22 Jan 2025 14:43:21 +0200

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

Previous Next

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