Re: librewolf 153.0.4-1 segfault

On 2026/08/19 14:28, [email protected] wrote:
> Le Sat, Aug 15, 2026 at 12:37:50PM -0400, Ronald Dahlgren a écrit :
> > Hello ports,
> > 
> > librewolf has been segfaulting after profile selection for about a
> > week now (maybe 10 days?). The behavior started after a `sysupgrade
> > -s` and has not been resolved with subsequent updates, so I thought
> > I'd report here. The first time I try to start it, the profile
> > selection screen appears. I choose a profile and a moment later it
> > segfaults. On subsequent runs, I can select the profile and the main
> > browser window will appear but all tabs have the "Gah. Your tab just
> > crashed." content. Even `about:blank` shows the same "gah" message.
> > `about:config` loads.
> > 
> > If I select another profile, it will core dump the first time, and
> > then subsequently open the browser window with "Gah. Your tab just
> > crashed." messages.
> > 
> > If I create a new profile, it will open the browser window with "Gah.
> > Your tab just crashed." messages. There is _some_ sort of interaction
> > with profiles here, but I can't tell if it's meaningful or not.
> > 
> > It drops a core, but there isn't much helpful here:
> 
> this hints at pledge violations, maybe in a child process, refer to the
> pkg-readme for the steps to provide more useful information (eg use
> egdb, install debug packages, learn to decipher ktrace...)
> 
> > ATTENTION: default value of option mesa_glthread overridden by environment.
> > librewolf[69235]: pledge "proc", syscall 195
> > librewolf[13877]: pledge "proc", syscall 195
> > ATTENTION: default value of option mesa_glthread overridden by environment.
> > librewolf[57614]: pledge "proc", syscall 195
> > librewolf[6793]: pledge "proc", syscall 195
> 

195 is setrlimit().

try running under ktrace -di and showing a few screens full of kdump
output from a crashing pid before the crash (e.g. kdump -p 69235 | tail
-300 or something if the above run had been done under ktrace).

also if you run "while true; do ps axwww|grep [l]ibrewolf >> /tmp/ps;
done" while triggering it, you might catch the process arguments that
might let you figure out what type of process the crashing pid is.