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

Previous Next

Package: emacs;

Reported by: Ken Brown <kbrown <at> cornell.edu>

Date: Wed, 11 Dec 2024 22:56:02 UTC

Severity: normal

Found in version 30.0.92

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

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Richard Brooksby <rb <at> ravenbrook.com>
To: Ken Brown <kbrown <at> cornell.edu>, 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: bug#74805: 30.0.92; Trying to build scratch/igc on Cygwin
Date: Sun, 22 Dec 2024 08:24:03 +0000
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.

The test is exiting because the MPS is returning code ResRESOURCE from 
these lines 
https://github.com/Ravenbrook/mps/blob/9fd0577cf1231e61c9801c81499e5d16d0743806/code/arenacv.c#L356-L357 
while calling an allocator.

ResRESOURCE only occurs in a few places, and is almost certainly to do 
with a lack of available address space.  Given that you've had to patch 
mmap, that's a smoking gun, but it should be fairly easy to breakpoint 
all the lines that raise ResRESOURCE to figure out what's happening.

Sometimes it's difficult to breakpoint the MPS because it runs in weird 
signal contexts.  We've been known to crash debuggers.  I don't know if 
it's tricksy in Cygwin.  In that case, you can hack around with 
_mps_RES_ENUM in mps.h to make ResRESOURCE call a function.

$ grep --color=auto -nH --null -e ResRESOURCE *.c
arena.c:767:    return ResRESOURCE;
arena.c:1048:    return ResRESOURCE;
arena.c:1227:  return ResRESOURCE;
arenacv.c:461:      die((res == ResRESOURCE) ? ResOK : res, "right error 
code");
arenavm.c:722:    res = ResRESOURCE;
fotest.c:55:    return ResRESOURCE;
mpm.c:254:  return (res == ResMEMORY || res == ResRESOURCE || res == 
ResCOMMIT_LIMIT);
thw3.c:101:    return ResRESOURCE;
vman.c:52:    return ResRESOURCE;
vman.c:59:    return ResRESOURCE;
vmix.c:107:    return ResRESOURCE;
vmix.c:110:    return ResRESOURCE;
vmix.c:122:    return ResRESOURCE;
vmw3.c:117:    return ResRESOURCE;
vmw3.c:120:    return ResRESOURCE;
vmw3.c:130:    return ResRESOURCE;

It's very unlikely that you're actually running out of address space on 
a 64-bit system.





This bug report was last modified 103 days ago.

Previous Next


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