Re: git: d8a3e1d47a90 - main - www/firefox: update to 117.0 (rc1)

On Fri, 1 Sep 2023 07:02:08 +0900
Tatsuki Makino <tatsuki_makino@hotmail.com> wrote:

 *** From now on, removed dev-commits-ports-main ML from recipients. ***

> Tomoaki AOKI wrote on 2023/08/30 21:40:
> > On Tue, 29 Aug 2023 09:06:46 +0900
> > Tatsuki Makino <tatsuki_makino@hotmail.com> wrote:
> >> So, it is better to put it on lldb.
> >> For example,
> >> lldb -o r -- /usr/local/bin/firefox --ProfileManager --no-remote --private-window
> >
> > Thanks for advice!
> > Uploaded backtrace to Bug 273291.
> > 
> 
> Thank you. And sorry, that may not be enough.
> 
> We all don't need to worry about ProfileManager, no-remote and private-window because they are for my experimentation, choosing profiles, launching multiple processes at the same time, and keeping the profiles as clean as possible :)
> 
> And here are some reasons why I think this core is still not enough.
> That is not limited to firefox, so I will write to the mailing list :)
> 
> >> lldb -o r -- /usr/local/bin/firefox
> The reason we want the program to run on lldb like this is because firefox has a feature to generate crash reports.
> Cores created by such programs may have stopped at the same time the crash report was created.
> If we are running it on the debugger, it will stop when the problem first occurs, so it will be in the correct position.
> This was encountered with multimedia/{lib,}openshot.
> 
> One of the reasons I want you to recreate the backtrace one more time is that firefox is a multi-threaded program.
> I don't have an understanding on this and would like someone with more knowledge to take over explaining it, but I think it is a compatibility issue between signal and multithreading.
> It seems that the backtrace of the current thread obtained by bt may not be the backtrace of the thread that caused the problem.
> We need to see all the backtraces by "bt all".
> I also reflexively paste only the backtrace by bt, but I think it happened before with www/chromium that the backtrace by bt I pasted did not contain anything :)
> 
> I'm not a particularly knowledgeable person, but I have had such first-hand experience, and I hope the story can be used as a shortcut for others :)
> 
> Regards.

Thanks!
Uploaded `bt all` log using core obtained from firefox on lldb
to Bug 273291.

And another person popped in for "+1" report there.

Note that ports tree is updated to commit
fb0373a15c107e3b50a5706d018aa35ad9892afc, including devel/glib20
update, and rebuilt updated ports built using poudriere.

Moreover, checked OPTIONS against default and found now-non-default
LIBPROXY is still set, and reversed it to off.
Now only difference from default is intentionally set PULSEAUDIO and
unset ALSA.

Now updating base to stable/14 ALPHA4 in conjunction with
cherry-picking timerfd-related fixes (include differential revisions on
phablicator). I wanted to cherry pick ZFS-related ones to avoid
deadlock on poudriere runs, but didn't do so yet as currently cannot
determine which to cherry pick (couldn't dig into prerequisites).

So the next test would be on the updated base. But I may be forced to
rebuild all pkgs by poudriere as of BRANCH variable change.
It would force me over 24 hours.


Regards.

-- 
Tomoaki AOKI    <junchoon@dec.sakura.ne.jp>