must be why i couldn't reproduce it myself. i set those limits crazy high on my test machine Am 24.08.26 um 16:59 schrieb Ronald Dahlgren: > Stuart, Landry, yaydn, and Leah, > > Thank you for your guidance with how to proceed. I did some digging and was > able to identify the root cause and a workaround for the issue. This occurs in > both Firefox and Librewolf, although the manifestation is a bit different. In > Firefox, I get "Gah" crash tabs for all content but it doesn't dump its core > during startup. > > 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. > > This is from a content process, `kdump -f lw.ktrace -p 60048`: > 60048 librewolf CALL getrlimit(RLIMIT_NOFILE,0x73c4725c9450) > 60048 librewolf STRU struct rlimit { cur=512, max=512 } > 60048 librewolf RET getrlimit 0 > 60048 librewolf CALL setrlimit(RLIMIT_NOFILE,0x73c4725c9450) > 60048 librewolf PLDG setrlimit, "proc", errno 1 Operation not permitted > 60048 librewolf PSIG SIGABRT SIG_DFL > The socket process shows an identical sequence. > > Here are the pledge records, with the file each process read: > 45999 pledge.main stdio rpath wpath cpath inet proc exec prot_exec flock > ps sendfd recvfd dns vminfo tty drm unix fattr getpw > mcast video route <- has proc, survives > 37962 pledge.socket stdio rpath recvfd sendfd inet dns <- aborts > 60048 pledge.content stdio rpath wpath cpath recvfd sendfd prot_exec unix > drm ps inet dns getpw <- aborts > 27325 pledge.rdd stdio rpath cpath wpath recvfd sendfd unix <- exits 0 > > Sample argv for a socket child, from a separate run: > /usr/local/lib/librewolf/librewolf -contentproc -parentBuildID 20260821003545 > -prefsHandle 0:29239 -prefMapHandle 1:294854 -ipcHandle 2 -initialChannelId > {6b255f3d-0c85-4651-8c76-84ec325f4138} -parentPid 82697 -appDir > /usr/local/lib/librewolf/browser 1 socket > > The parent's SIGSEGV happens after the children abort, and it re-raises to get > the core: > 45999 librewolf PSIG SIGSEGV caught handler=0xe4a7694acc0 mask=0<> > code=SEGV_MAPERR addr=0xd8 trapno=6 > 45999 librewolf CALL sigaction(SIGSEGV,0xe4a774d7d90,0) > 45999 librewolf CALL sigprocmask(SIG_UNBLOCK,0x400<SIGSEGV>) > 45999 librewolf CALL thrkill(0,SIGSEGV,0) > 45999 librewolf PSIG SIGSEGV SIG_DFL addr=0x0 trapno=0 > > librewolf-154.0pl2p0 and firefox-154.0p0 are both affected. thunderbird behaves > without the issue. The issue can be reproduced with a new profile, in > --safe-mode, with cleared cache, and under env -i. > > Happy to run anything else that would help, or test patches. > > Ron -- Company director, Minifree Ltd Registered in England, No. 9361826 | VAT No. GB202190462 Registered Office: 19 Hilton Road, Canvey Island, Essex SS8 9QA, UK
No comments:
Post a Comment