Re: librewolf 153.0.4-1 segfault

Le Mon, Aug 24, 2026 at 03:59:52PM +0000, Ronald Dahlgren a écrit :
> Stuart, Landry, yaydn, and Leah,
> 
> Content and socket child processes check the rlimit for the number of files. If
> that number is too low, they try to set a new limit. Neither pledge.content nor
> pledge.socket has proc, so this is a pledge violation and the kernel kills the
> process. Normally the parent, which does have proc in pledge.main, raises the
> limit first and the children inherit something adequate and never call
> setrlimit at all. Two things have to be true to hit this: the soft limit has to
> be below whatever the browser wants, and there has to be no headroom under the
> hard limit for the parent's raise to take effect. Note that 1024/1024 also has
> no headroom and works fine, so 512 being too low is the other half of it. I
> have only traced the failing case, so the part about the parent sparing the
> children is inference.
> 
> I am using the staff login class. Stock staff sets no openfiles line and
> inherits openfiles-cur=512 from default, with a hard limit of 1024. My own
> /etc/login.conf is locally modified and was pinning both the soft and hard
> limits to 512, which is what removed the headroom. That is probably why this
> hasn't hit more people: stock ships 512/1024 and works fine. Setting both to
> 512 reproduces it reliably, and raising the soft limit to 1024 makes it go
> away.
> 
> Adding proc to pledge.content and pledge.socket would presumably also avoid the
> abort, but I haven't tested that, and it would needlessly widen the content
> sandbox. Skipping the setrlimit when it wouldn't change anything seems like the
> better fix.

thanks for the detailed analysis, much appreciated. my understanding
of what you describe would point at
https://searchfox.org/firefox-main/source/toolkit/xre/nsAppRunner.cpp#4194
which afaict is called at startup, or
https://searchfox.org/firefox-main/source/netwerk/base/nsSocketTransportService2.cpp#1732
 does that match what you've seen in your coredumps with egdb, once
installed the debug packages ?

i havent really analyzed the code (yet). dunno when that'll be possible,
but at least you've given the steps to reproduce so that should help.

if i get it right, with the default limits the problem doesnt exist ?

Landry