From: Mark Kettenis <mark.kettenis@xs4all.nl>
Subject: Re: MAXTSIZ vs chromium [Re: ungoogled-chromium-155.0.8059.39: ENOMEM on amd64 -current]
To: Stuart Henderson <stu@spacehopper.org>
Cc: d.haasler@gmx.at, ports@openbsd.org, robert@openbsd.org, deraadt@openbsd.org
Date: Mon, 12 Oct 2026 21:09:57 +0200

> Date: Mon, 12 Oct 2026 15:30:12 +0100
> From: Stuart Henderson <stu@spacehopper.org>

On a somewhat related topic:

These days I can't watch a an average youtube video anymore without
the tab crashing.  Bumping ulimit -d seems to fix that.  Currently
have it at 4G, but I'll see if a lower limit works as well.

> On 2026/10/12 15:48, Dorian Haasler wrote:
> >                     And I use abbrevations in the mails and text I
> > write; and with a bit of irony I agree that we all should write out
> > "change-directory" everytime we do want todo so, and not use cd instead.
> 
> well, that makes no sense at all, and is nothing to do with the report,
> so no point including this stuff.
> 
> > After upgrading to the latest -current packages, ungoogled-chromium no
> > longer starts. The executable fails at execve(2) with ENOMEM, apparently
> > because its executable ELF segment exceeds OpenBSD/amd64's MAXTSIZ limit
> > of 256 MiB.
> 
> confirmed
> 
> >     $ readelf -Wl /usr/local/ungoogled-chromium/ungoogled-chromium
> > 
> > The relevant PT_LOAD segment is:
> > 
> >     Type   Offset      FileSiz      MemSiz       Flg  Align LOAD
> >     0x349e340   0x10228870   0x10228870    E   0x1000
> > 
> > This executable segment has a size of 270,698,608 bytes (258.16 MiB).
> 
> > In sys/arch/amd64/include/vmparam.h:
> > 
> >     #define MAXTSIZ ((paddr_t)256*1024*1024)
> 
> you can bump to the next power of 2 (512*1024*1024), rebuild kernel,
> and see how things go.
> 
> > Would it be possible to adjust the Chromium build to keep the executable
> > text size below MAXTSIZ,
> 
> any reprieve here is only going to be temporary...
> 
> >                          or is an increase to the kernel limit being
> > considered?
> 
> I don't know the downsides of doing this, but iridium and chromium
> aren't far behind, and it's not as if they're likely to get any
> less piggy...
> 
> $ for i in chrome ungoogled-chromium iridium; do echo $i $(moo -b{10,16} $(readelf -Wl /usr/local/$i/$i | awk '/LOAD.*E/ {print $5}')); done
> chrome 0xf9311a0 261296544
> ungoogled-chromium 0x10228870 270698608
> iridium 0xf9b02e0 261817056
> 
> on aarch64, sizes for those of the packages which _can_ be built are
> similar:
> 
> chrome 0xff03d58 267402584
> iridium 0xfc3cb98 264489880
> 
> ungoogled-chromium fails to build on aarch64 at the moment; I wonder if
> this might be related...
> 
> fwiw, this has exceeded 256M text segment on linux for some time now:
> 
> ungoogled-chromium-150.0.7871.186-1-x86_64_linux/chrome 0xfae2f20 263073568
> ungoogled-chromium-151.0.7922.173-1-x86_64_linux/chrome 0x101a5d70 270163312
> ungoogled-chromium-152.0.7977.82-1-x86_64_linux/chrome 0x101d6190 270360976
> ungoogled-chromium-153.0.8010.52-1-x86_64_linux/chrome 0x109157a0 277960608
> ungoogled-chromium-154.0.8037.97-1-x86_64_linux/chrome 0x10989350 278434640
> ungoogled-chromium-155.0.8059.39-1-x86_64_linux/chrome 0x10c1f590 281146768
> 
>