*Any* MAX_MEMORY setting can cause certain ports to fail to build

[ag-eitilt]

Prerequisites

• Have you checked for an existing issue describing your problem?
• Are you running the latest version?
• Is your ports tree recent?
• Is your FreeBSD Host on a supported release?

Describe the bug

There's a couple of ports bugs with rather-difficult-to-pin-down errors:

On www/qt6-webengine (bug 278293):

[ 99% 30402/30658] AR obj/components/visitedlink/renderer/librenderer.a
[ 99% 30403/30658] AR obj/components/web_cache/renderer/librenderer.a
[ 99% 30404/30658] STAMP obj/extensions/renderer/renderer.stamp
[ 99% 30405/30658] LINK ./v8_context_snapshot_generator
[ 99% 30406/30658] ACTION //tools/v8_context_snapshot:generate_v8_context_snapshot(/wrkdirs/usr/ports/www/qt6-webengine/work/.build/src/core/target_toolchain:target)
FAILED: v8_context_snapshot.bin 
/usr/local/bin/python3.9 ../../../../../qtwebengine-everywhere-src-6.6.3/src/3rdparty/chromium/build/gn_run_binary.py ./v8_context_snapshot_generator --output_file=v8_context_snapshot.bin
./v8_context_snapshot_generator failed with exit code -5
...
ninja: build stopped: subcommand failed.
*** [src/core/Release/amd64/QtWebEngineCore.stamp] Error code 1

make[3]: stopped in /wrkdirs/usr/ports/www/qt6-webengine/work/.build
1 error

make[3]: stopped in /wrkdirs/usr/ports/www/qt6-webengine/work/.build
*** [src/core/CMakeFiles/QtWebEngineCore_Release_amd64.dir/all] Error code 2

make[2]: stopped in /wrkdirs/usr/ports/www/qt6-webengine/work/.build
1 error

make[2]: stopped in /wrkdirs/usr/ports/www/qt6-webengine/work/.build
*** [all] Error code 2

make[1]: stopped in /wrkdirs/usr/ports/www/qt6-webengine/work/.build
1 error

make[1]: stopped in /wrkdirs/usr/ports/www/qt6-webengine/work/.build
===> Compilation failed unexpectedly.
Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to
the maintainer.
*** Error code 1

Stop.
make: stopped in /usr/ports/www/qt6-webengine

On lang/dotnet (bug 276713) (this thread starts with logs showing a different error code, so I think there were multiple things going wrong in their setup; the one I've pinned down to this issue is 0x800700E):

[00:29:34] Detected '--': passing remaining parameters '-maxcpucount:12' as build.sh arguments.
[00:29:36] GC heap initialization failed with error 0x8007000E
[00:29:36] Failed to create CoreCLR, HRESULT: 0x8007000E
[00:29:36] Using custom bootstrap SDK from '/wrkdirs/usr/ports/lang/dotnet/work/bootstrap_sdk', version ''
[00:29:36] Found bootstrap SDK , bootstrap Arcade 8.0.0-beta.23516.4, bootstrap SourceLink 8.0.0-beta.23510.2
[00:29:37] GC heap initialization failed with error 0x8007000E
[00:29:37] Failed to create CoreCLR, HRESULT: 0x8007000E
[00:29:38] *** Error code 137
[00:29:38] 
[00:29:38] Stop.
[00:29:38] make: stopped in /usr/ports/lang/dotnet

On multimedia/jellyfin (no Bugzilla bug; I found it myself after forcing lang/dotnet through):

[BABEL] Note: The code generator has deoptimised the styling of /wrkdirs/usr/ports/multimedia/jellyfin/work/jellyfin-web-10.10.7/node_modules/pdfjs-dist/build/pdf.js as it exceeds the max of 500KB.


#
# Fatal process out of memory: Failed to reserve virtual memory for CodeRange
#
----- Native stack trace -----



#
# Fatal process out of memory: Failed to reserve virtual memory for CodeRange
#
----- Native stack trace -----



#
# Fatal process out of memory: Failed to reserve virtual memory for CodeRange
#
----- Native stack trace -----



#
# Fatal process out of memory: Failed to reserve virtual memory for CodeRange
#
----- Native stack trace -----



#
# Fatal process out of memory: Failed to reserve virtual memory for CodeRange
#
----- Native stack trace -----



#
# Fatal process out of memory: Failed to reserve virtual memory for CodeRange
#
----- Native stack trace -----

 1: 0x250ca11 node::NodePlatform::GetPageAllocator() [/usr/local/bin/node]
 2: 0x34c29c2 v8::base::FatalOOM(v8::base::OOMType, char const*) [/usr/local/bin/node]
 3: 0x26932ef v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, v8::OOMDetails const&) [/usr/local/bin/node]
 1: 0x250ca11 node::NodePlatform::GetPageAllocator() [/usr/local/bin/node]
 4: 0x2895a28 v8::internal::Heap::SetUp(v8::internal::LocalHeap*) [/usr/local/bin/node]
 5: 0x27e8813 v8::internal::Isolate::Init(v8::internal::SnapshotData*, v8::internal::SnapshotData*, v8::internal::SnapshotData*, bool) [/usr/local/bin/node]
 6: 0x27e9399 v8::internal::Isolate::InitWithSnapshot(v8::internal::SnapshotData*, v8::internal::SnapshotData*, v8::internal::SnapshotData*, bool) [/usr/local/bin/node]
 2: 0x34c29c2 v8::base::FatalOOM(v8::base::OOMType, char const*) [/usr/local/bin/node]
 7: 0x2cbfe0d v8::internal::Snapshot::Initialize(v8::internal::Isolate*) [/usr/local/bin/node]
 8: 0x26b94ab v8::Isolate::Initialize(v8::Isolate*, v8::Isolate::CreateParams const&) [/usr/local/bin/node]
 9: 0x236e050 node::NewIsolate(v8::Isolate::CreateParams*, uv_loop_s*, node::MultiIsolatePlatform*, node::SnapshotData const*, node::IsolateSettings const&) [/usr/local/bin/node]
10: 0x25a0873 node::worker::WorkerThreadData::WorkerThreadData(node::worker::Worker*) [/usr/local/bin/node]
 3: 0x26932ef v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, v8::OOMDetails const&) [/usr/local/bin/node]
11: 0x259b3b3 node::worker::Worker::Run() [/usr/local/bin/node]
12: 0x259ee0e _register_external_reference_worker(node::ExternalReferenceRegistry*) [/usr/local/bin/node]
*** Error code 1

Stop.
make: stopped in /usr/ports/multimedia/jellyfin
=>> Cleaning up wrkdir
===>  Cleaning for jellyfin-10.10.7
build of multimedia/jellyfin | jellyfin-10.10.7 ended at Sun Aug 31 16:38:58 PDT 2025
build time: 00:01:58
!!! build failure encountered !!!

At first glance those are very different signatures, but they all clear up immediately with the same fix, and all seem to involve low-level access to memory (reserving it in the dotnet cases, snapshotting it in the qt-webengine/chromium cases) so my suspicion is that they stem from the same problem in the sandboxing. Specifically, even if you set a MAX_MEMORY value high enough that there should be no reasonable chance it gets hit (20GB in the attached conf, and I think I remember going higher when trying to debug these originally), the tooling involved fails. As soon as you comment out the MAX_MEMORY line, they run all the way through perfectly happily. I'm not sure what mechanism poudriere is using to limit memory and I have no idea why its simple presence is enough to make these specific cases fail, but it certainly seems to be the root cause.

I've attached my own logs for all of these proving they're still a problem; the qt6-webengine and jellyfin ones are from the previous patch-version poudriere release since I didn't want to rebuild the entire thing/reconstruct the tenuous, multi-stage environment (respectively) just to bump that third number, but I don't see how it would be any different now. I'm also attaching my poudriere.conf just in case it's due to some interaction with some other setting; the one I'm most suspicious of conflicting is the BUILD_AS_NON_ROOT, but since they can all be built just fine after removing the memory limit, I'm less inclined to think it's access restrictions coming into play. There's also a chance it's something to do with running poudriere in a jail itself (so the builds are happening in a jail launched from a jail), but that feels unlikely due to the below.

• qt6-webengine-6.9.1_2.log
• dotnet8-8.0.6_4.log
• jellyfin-10.10.7.log
• poudriere.conf¹

Making the debugging even more difficult, even if I kept the same builder jail around with -i/-I so I could jexec in and run make from the ports manually, that manual build had no issues getting through. It's very specifically whatever mechanism poudriere uses to spin out its child builders that's causing the problem, rather than anything at the jail or system levels.

How to reproduce

The easiest one to reproduce is lang/dotnet, since it happens only about a minute and a half in (the moment the build phase starts).

• Set any value for MAX_MEMORY in poudriere.conf
• Build lang/dotnet8 according to your standard practice; in my case it's jexec poudriere poudriere bulk -j 14_3amd64al -p 2025Q3 lang/dotnet8
• Wait a short bit until the build fails -- if the build actually starts then it's sensitive to something in my environment that's not in yours
• Remove or comment out the MAX_MEMORY limitation (do not just raise it to the point it would otherwise be irrelevant)
• Run the poudriere command again
• Wait a bit longer and watch the logs to observe it actually getting built
• Cancel the build if you don't actually have any need for dotnet on your system

Expected behavior

• The build to function correctly whether or not MAX_MEMORY was set (unless it's set to an unreasonably low value)

Screenshots

Logs are linked above, and images wouldn't give any extra info.

Environment

• Host OS: 14.3 amd64
• Jail OS: 14.3 amd64
• Browser: N/A
• Poudriere Version: poudriere-git-3.4.3_1 (yes, the _1 is a local patch; no it doesn't have anything to do with this -- I just replaced POUDRIERED with BASEFS in a few places to get the jail/port var-like files out of etc)
• Ports branch and revision: 2025Q3 76eafab14

Additional context

This issue has a long history of someone hitting it, other people being unable to replicate it, and the first person eventually giving up trying to pin it down, going silent, or having things start building just fine months later without knowing what changed to have the build work. So far as my search skills go, I'm the first to identify it as being an issue with MAX_MEMORY (even if it's in conjunction with other features²), so whether or not this is something y'all are able to fix, part of my goal here is just laying enough breadcrumbs that the next person to come along has a better place to start their own debugging from. Like I mentioned on Bugzilla:

Footnotes

1. Sorry for the extension on the conffile when you download it; GitHub's attachment filters are absolutely ridiculous for a site that's supposedly in service of software development -- you can't even upload a *.diff, it has to be specifically a *.patch -- and as demonstrated here, entirely worthless for actually restricting uploading anything. ↩

2. Notably, the USE_TMPFS=all diagnosis in the qt-webengine/chromium thread was set on speculation based on something that changed around the time the original reporter had -- briefly -- fixed things, but it was never actually isolated as the cause. I'm all but certain that that has nothing to do with this since I have tmpfs blacklisted for these ports, and have another memory of explicitly testing with tmpfs disabled across the board. (I did a lot of scattershot debugging, and didn't take notes on the failures; I'm familiar with how easily a fake memory can be suggested and take hold.) ↩