Tuesday, August 25, 2026

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

No comments:

Post a Comment