Date: Mon, 11 Sep 2023 01:24:46 +0000 From: bugzilla-noreply@freebsd.org To: gecko@FreeBSD.org Subject: [Bug 273291] www/firefox: Crashes on start after upgrading from 116.0.3_1,2 to 117.0,2 Message-ID: <bug-273291-21738-VCryIqmEUH@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-273291-21738@https.bugs.freebsd.org/bugzilla/> References: <bug-273291-21738@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D273291 --- Comment #24 from Tatsuki Makino <tatsuki_makino@hotmail.com> --- (In reply to Tomoaki AOKI from comment #20) It would seem that it is "failing normally (=E6=AD=A3=E5=B8=B8=E3=81=AB=E5= =A4=B1=E6=95=97)". If the surviving processes are using profiles, we should also consider using killall firefox to terminate all processes. In rare cases, a process may remain unreachable from the debugger. (e.g. It= is encountered by apache httpd.) Off topic, but it seems to me that the profile evacuation needs to be done = in two places. ~/.mozilla/firefox and ~/.cache/mozilla/firefox I don't know where ~/.cache is these days :) It gets lost because of XDG_RUNTIME_DIR. In this case, it is better to include -g in CFLAGS instead of using the DEB= UG option. If make patch has already been run and make clean has not been run, lldb can find the source. For step execution and breakpoints to work properly, it is better if the optimization is -O0. Well, for some people, it may be easier to look directly at the source inst= ead of using the debugger, if the backtrace is successful in identifying where = the problem occurs :) --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-273291-21738-VCryIqmEUH>