Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 750038 - www-client/chromium-87.0.4280.20: random crashes
Summary: www-client/chromium-87.0.4280.20: random crashes
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Chromium Project
URL: https://bugs.chromium.org/p/chromium/...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-10-19 01:43 UTC by Andrew Udvare
Modified: 2020-10-30 19:57 UTC (History)
7 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
GDB output (gdb-chromium.txt,44.68 KB, text/plain)
2020-10-19 03:34 UTC, Andrew Udvare
Details
service-worker-registration-double-destruction.patch (service-worker-registration-double-destruction.patch,1.08 KB, patch)
2020-10-25 07:54 UTC, Peter Levine
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew Udvare 2020-10-19 01:43:05 UTC
It seems that after a while Chrome simply crashes. I am not able to reliably reproduce this or figure out what thee cause is yet. I left some tabs open and attached GDB and then left Chrome alone for a while. It crashed at an unknown time after.

I have a core dump file but I would like to clear it up of personal data before sending it (not sure how to do that however).

This may not be the thread or process that crashed. It may also have been a subprocess I do not have a dump for.

It *may* be flags set in chrome://flags and I'm going to do more testing with no flags, some flags, and I will reset my profile and cache data completely.

Crash was not happening in 86.

Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x0000562abd867a25 in content::ServiceWorkerRegistrationObjectHost::~ServiceWorkerRegistrationObjectHost() ()
#1  0x0000562abd867aa2 in content::ServiceWorkerRegistrationObjectHost::~ServiceWorkerRegistrationObjectHost() ()
#2  0x0000562abd7fd63b in std::_Rb_tree<long, std::pair<long const, std::unique_ptr<content::ServiceWorkerRegistrationObjectHost, std::default_delete<content::ServiceWorkerRegistrationObjectHost> > >, std::_Select1st<std::pair<long const, std::unique_ptr<content::ServiceWorkerRegistrationObjectHost, std::default_delete<content::ServiceWorkerRegistrationObjectHost> > > >, std::less<long>, std::allocator<std::pair<long const, std::unique_ptr<content::ServiceWorkerRegistrationObjectHost, std::default_delete<content::ServiceWorkerRegistrationObjectHost> > > > >::_M_erase(std::_Rb_tree_node<std::pair<long const, std::unique_ptr<content::ServiceWorkerRegistrationObjectHost, std::default_delete<content::ServiceWorkerRegistrationObjectHost> > > >*) ()
#3  0x0000562abd7f60a8 in content::ServiceWorkerContainerHost::~ServiceWorkerContainerHost() ()
#4  0x0000562abd7f6262 in content::ServiceWorkerContainerHost::~ServiceWorkerContainerHost() ()
#5  0x0000562abd8388e6 in content::ServiceWorkerHost::~ServiceWorkerHost() ()
#6  0x0000562abd8af24c in content::ServiceWorkerVersion::~ServiceWorkerVersion() ()
#7  0x0000562abd8af4f2 in content::ServiceWorkerVersion::~ServiceWorkerVersion() ()
#8  0x0000562abd865766 in content::ServiceWorkerRegistration::~ServiceWorkerRegistration() ()
#9  0x0000562abd8657e2 in content::ServiceWorkerRegistration::~ServiceWorkerRegistration() ()
#10 0x0000562abd867a81 in content::ServiceWorkerRegistrationObjectHost::~ServiceWorkerRegistrationObjectHost() ()
#11 0x0000562abd867aa2 in content::ServiceWorkerRegistrationObjectHost::~ServiceWorkerRegistrationObjectHost() ()
#12 0x0000562abd7fd63b in std::_Rb_tree<long, std::pair<long const, std::unique_ptr<content::ServiceWorkerRegistrationObjectHost, std::default_delete<content::ServiceWorkerRegistrationObjectHost> > >, std::_Select1st<std::pair<long const, std::unique_ptr<content::ServiceWorkerRegistrationObjectHost, std::default_delete<content::ServiceWorkerRegistrationObjectHost> > > >, std::less<long>, std::allocator<std::pair<long const, std::unique_ptr<content::ServiceWorkerRegistrationObjectHost, std::default_delete<content::ServiceWorkerRegistrationObjectHost> > > > >::_M_erase(std::_Rb_tree_node<std::pair<long const, std::unique_ptr<content::ServiceWorkerRegistrationObjectHost, std::default_delete<content::ServiceWorkerRegistrationObjectHost> > > >*) ()
#13 0x0000562abd7f599a in content::ServiceWorkerContainerHost::RemoveServiceWorkerRegistrationObjectHost(long) ()
#14 0x0000562abd86bc96 in mojo::ReceiverSetBase<mojo::AssociatedReceiver<blink::mojom::ServiceWorkerRegistrationObjectHost, mojo::RawPtrImplRefTraits<blink::mojom::ServiceWorkerRegistrationObjectHost> >, void>::Entry::OnDisconnect(unsigned int, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) ()
#15 0x0000562ac040827f in mojo::InterfaceEndpointClient::NotifyError(base::Optional<mojo::DisconnectReason> const&)
    ()
#16 0x0000562ac040cb6a in mojo::internal::MultiplexRouter::ProcessNotifyErrorTask(mojo::internal::MultiplexRouter::Task*, mojo::internal::MultiplexRouter::ClientCallBehavior, base::SequencedTaskRunner*) ()
#17 0x0000562ac040e333 in mojo::internal::MultiplexRouter::ProcessTasks(mojo::internal::MultiplexRouter::ClientCallBehavior, base::SequencedTaskRunner*) [clone .part.0] ()
#18 0x0000562ac0411112 in mojo::internal::MultiplexRouter::OnPipeConnectionError(bool) ()
#19 0x0000562ac04066d0 in mojo::Connector::HandleError(bool, bool) ()
#20 0x0000562ac0429cb6 in mojo::SimpleWatcher::OnHandleReady(int, unsigned int, mojo::HandleSignalsState const&) ()
#21 0x0000562abfc28992 in base::TaskAnnotator::RunTask(char const*, base::PendingTask*) ()
#22 0x0000562abfc3e38c in base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::DoWorkImpl(base::sequence_manager::LazyNow*) ()
#23 0x0000562abfc3e72e in base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::DoWork() ()
#24 0x0000562abfbd6eca in base::MessagePumpGlib::Run(base::MessagePump::Delegate*) ()
#25 0x0000562abfc3d6b2 in base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::Run(bool, base::TimeDelta) ()
#26 0x0000562abfc0671c in base::RunLoop::Run() [clone .part.0] ()
#27 0x0000562ac00da069 in ChromeBrowserMainParts::MainMessageLoopRun(int*) ()
#28 0x0000562abd2e1431 in content::BrowserMainLoop::RunMainMessageLoopParts() ()
#29 0x0000562abd2e37b5 in content::BrowserMainRunnerImpl::Run() ()
#30 0x0000562abd2de289 in content::BrowserMain(content::MainFunctionParams const&) ()
#31 0x0000562abf9bc4ff in content::ContentMainRunnerImpl::Run(bool) ()
#32 0x0000562abf9b9976 in content::RunContentProcess(content::ContentMainParams const&, content::ContentMainRunner*) ()
#33 0x0000562abf9ba0c2 in content::ContentMain(content::ContentMainParams const&) ()
#34 0x0000562abbc2b855 in ChromeMain ()
#35 0x00007f8a9d614e0a in __libc_start_main (main=
    0x562abbbf0450 <main>, argc=2, argv=0x7ffe1972c618, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffe1972c608) at ../csu/libc-start.c:314
#36 0x0000562abbc2b69a in _start ()
Comment 1 Andrew Udvare 2020-10-19 03:33:05 UTC
I removed ~/.cache/chromium and ~/.config/chromium, signed into my account again, let it sync, and the crash is the same. And basically random.

This one happened while going to ARIN's CIDR calculator for the first time with the newly synced data.

Attaching output from GDB based on the instructions that Google links to: https://wiki.ubuntu.com/Chromium/Debugging
Comment 2 Andrew Udvare 2020-10-19 03:34:59 UTC
Created attachment 666662 [details]
GDB output

This is based on the steps shown here: https://wiki.ubuntu.com/Chromium/Debugging

--single-process was not used, as this creates way more unpredictable instability.
Comment 3 Andrew Udvare 2020-10-19 03:56:42 UTC
I'm downgrading for now as it's too unstable for me.
Comment 4 Stephan Hartmann (RETIRED) gentoo-dev 2020-10-19 06:52:21 UTC
(In reply to Andrew Udvare from comment #3)
> I'm downgrading for now as it's too unstable for me.

Please comment in ${URL} that happens for you too. Maybe they start investigating.
Comment 5 Andrew Udvare 2020-10-19 07:56:31 UTC
I added a comment to upstream.

The URL I can trigger the crash with sometimes is https://account.arin.net/public/cidrCalculator
Comment 6 Andrew Udvare 2020-10-19 14:46:51 UTC
Been trying really hard to trigger this crash again.

I rebuilt with USE=official and with -ggdb with splitdebug. I am attaching to the process as before and I have not yet got a crash in the last 30 minutes or so.
Comment 7 Andrew Udvare 2020-10-19 15:00:18 UTC
Got the crash once.

I have set a breakpoint on content::ServiceWorkerRegistrationObjectHost::~ServiceWorkerRegistrationObjectHost
 but this is not a silver bullet to catch the crash as it happens. This doesn't always crash the process.

Also I noticed the ebuild filters out -g* CFLAGS by default so ignore my last comment about that. I don't know if I should try building with USE="component-build custom-cflags" yet.
Comment 8 Andrew Udvare 2020-10-19 19:01:54 UTC
I was not successful in building version 87 with USE=custom-cflags to get -ggdb in the flags. USE=component-build cannot be set to reduce memory requirements.

[ebuild     U  ] www-client/chromium-87.0.4280.20::gentoo [86.0.4240.75::gentoo] USE="cups custom-cflags* hangouts js-type-check official* (pic) proprietary-codecs pulseaudio suid system-ffmpeg system-icu tcmalloc vaapi%* widevine (-component-build) (-headless) -kerberos (-selinux) ...

I switched to build with USE=official but this made no difference in the crash behaviour.

I have switched back to 86 for now.
Comment 9 Jan Baklo 2020-10-20 06:33:29 UTC
All previous builds of chromium-87 also crashes randomly. These crashes are very similar to the crashes in the first builds of chromium-86.
Comment 10 Stephan Hartmann (RETIRED) gentoo-dev 2020-10-20 07:44:01 UTC
I have released a new patchset. Please try to test with it. To use just change PATCHSET="6" to PATCHSET="7" in chromium-87.0.4280.20.ebuild and regenerate Manifest (ebuild chromium-87.0.4280.20.ebuild manifest).
To get good stack trace (without gdb) compile with USE=-official and FEATURES=nostrip.
Comment 11 Andrew Udvare 2020-10-20 12:10:41 UTC
Retr(In reply to Stephan Hartmann from comment #10)
> I have released a new patchset. Please try to test with it. To use just
> change PATCHSET="6" to PATCHSET="7" in chromium-87.0.4280.20.ebuild and
> regenerate Manifest (ebuild chromium-87.0.4280.20.ebuild manifest).
> To get good stack trace (without gdb) compile with USE=-official and
> FEATURES=nostrip.

Attempting to build now. Will report back.

 $ fgrep PATCH /var/db/repos/gentoo/www-client/chromium/chromium-87.0.4280.20.ebuild
PATCHSET="7"
PATCHSET_NAME="chromium-$(ver_cut 1)-patchset-${PATCHSET}"
        https://github.com/stha09/chromium-patches/releases/download/${PATCHSET_NAME}/${PATCHSET_NAME}.tar.xz"
PATCHES=(

 $ cat /etc/portage/package.env/chrome
www-client/chromium nostrip

 $ cat /etc/portage/env/nostrip
FEATURES="nostrip clean-logs"
Comment 12 Andrew Udvare 2020-10-20 19:25:14 UTC
Finished the build and got a crash while scrolling in chrome://serviceworker-internals. The crash is sometimes triggerable by clicking the Unregister buttons a few times. It is not consistent.

Make sure to have a few sites with service workers going, like:

https://docs.google.com/drawings/
https://docs.google.com/document/
https://docs.google.com/presentation/
YouTube

This does not have line numbers unfortunately but the bug on Chromium Bugs does. The crash is 100% the same every time, at content::ServiceWorkerRegistrationObjectHost::~ServiceWorkerRegistrationObjectHost+69 in the debugger (built with -O2 -pipe -march=native).

It looks like it is something to do with the .erase() calls on std::_Rb_tree (probably a subclass of it) which cascade to all child objects and appear to get the wrong address on a method to call.

#0  0x0000561f1a501a25 in content::ServiceWorkerRegistrationObjectHost::~ServiceWorkerRegistrationObjectHost() ()
#1  0x0000561f1a501aa2 in content::ServiceWorkerRegistrationObjectHost::~ServiceWorkerRegistrationObjectHost() ()
#2  0x0000561f1a49763b in std::_Rb_tree<long, std::pair<long const, std::unique_ptr<content::ServiceWorkerRegistrationObjectHost, std::default_delete<content::ServiceWorkerRegistrationObjectHost> > >, std::_Select1st<std::pair<long const, std::unique_ptr<content::ServiceWorkerRegistrationObjectHost, std::default_delete<content::ServiceWorkerRegistrationObjectHost> > > >, std::less<long>, std::allocator<std::pair<long const, std::unique_ptr<content::ServiceWorkerRegistrationObjectHost, std::default_delete<content::ServiceWorkerRegistrationObjectHost> > > > >::_M_erase(std::_Rb_tree_node<std::pair<long const, std::unique_ptr<content::ServiceWorkerRegistrationObjectHost, std::default_delete<content::ServiceWorkerRegistrationObjectHost> > > >*) ()
#3  0x0000561f1a4900a8 in content::ServiceWorkerContainerHost::~ServiceWorkerContainerHost() ()
#4  0x0000561f1a490262 in content::ServiceWorkerContainerHost::~ServiceWorkerContainerHost() ()
#5  0x0000561f1a4d28e6 in content::ServiceWorkerHost::~ServiceWorkerHost() ()
#6  0x0000561f1a54924c in content::ServiceWorkerVersion::~ServiceWorkerVersion() ()
#7  0x0000561f1a5494f2 in content::ServiceWorkerVersion::~ServiceWorkerVersion() ()
#8  0x0000561f1a4ff766 in content::ServiceWorkerRegistration::~ServiceWorkerRegistration() ()
#9  0x0000561f1a4ff7e2 in content::ServiceWorkerRegistration::~ServiceWorkerRegistration() ()
#10 0x0000561f1a501a81 in content::ServiceWorkerRegistrationObjectHost::~ServiceWorkerRegistrationObjectHost() ()
#11 0x0000561f1a501aa2 in content::ServiceWorkerRegistrationObjectHost::~ServiceWorkerRegistrationObjectHost() ()
#12 0x0000561f1a49763b in std::_Rb_tree<long, std::pair<long const, std::unique_ptr<content::ServiceWorkerRegistrationObjectHost, std::default_delete<content::ServiceWorkerRegistrationObjectHost> > >, std::_Select1st<std::pair<long const, std::unique_ptr<content::ServiceWorkerRegistrationObjectHost, std::default_delete<content::ServiceWorkerRegistrationObjectHost> > > >, std::less<long>, std::allocator<std::pair<long const, std::unique_ptr<content::ServiceWorkerRegistrationObjectHost, std::default_delete<content::ServiceWorkerRegistrationObjectHost> > > > >::_M_erase(std::_Rb_tree_node<std::pair<long const, std::unique_ptr<content::ServiceWorkerRegistrationObjectHost, std::default_delete<content::ServiceWorkerRegistrationObjectHost> > > >*) ()
#13 0x0000561f1a48f99a in content::ServiceWorkerContainerHost::RemoveServiceWorkerRegistrationObjectHost(long) ()
#14 0x0000561f1a505c96 in mojo::ReceiverSetBase<mojo::AssociatedReceiver<blink::mojom::ServiceWorkerRegistrationObjectHost, mojo::RawPtrImplRefTraits<blink::mojom::ServiceWorkerRegistrationObjectHost> >, void>::Entry::OnDisconnect(unsigned int, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) ()
#15 0x0000561f1d0a227f in mojo::InterfaceEndpointClient::NotifyError(base::Optional<mojo::DisconnectReason> const&) ()
#16 0x0000561f1d0a6b6a in mojo::internal::MultiplexRouter::ProcessNotifyErrorTask(mojo::internal::MultiplexRouter::Task*, mojo::internal::MultiplexRouter::ClientCallBehavior, base::SequencedTaskRunner*) ()
#17 0x0000561f1d0a8333 in mojo::internal::MultiplexRouter::ProcessTasks(mojo::internal::MultiplexRouter::ClientCallBehavior, base::SequencedTaskRunner*) [clone .part.0] ()
#18 0x0000561f1d0ab112 in mojo::internal::MultiplexRouter::OnPipeConnectionError(bool) ()
#19 0x0000561f1d0a06d0 in mojo::Connector::HandleError(bool, bool) ()
#20 0x0000561f1d0c3cb6 in mojo::SimpleWatcher::OnHandleReady(int, unsigned int, mojo::HandleSignalsState const&) ()
#21 0x0000561f1c8c2992 in base::TaskAnnotator::RunTask(char const*, base::PendingTask*) ()
#22 0x0000561f1c8d838c in base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::DoWorkImpl(base::sequence_manager::LazyNow*) ()
#23 0x0000561f1c8d872e in base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::DoWork() ()
#24 0x0000561f1c87103a in base::(anonymous namespace)::WorkSourceDispatch(_GSource*, int (*)(void*), void*) ()
#25 0x00007ff70cd3ae2b in g_main_dispatch (context=0xbb1e738b00) at ../glib-2.64.5/glib/gmain.c:3309
#26 g_main_context_dispatch (context=0xbb1e738b00) at ../glib-2.64.5/glib/gmain.c:3974
#27 0x00007ff70cd3b0d8 in g_main_context_iterate (context=context@entry=0xbb1e738b00, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>)
    at ../glib-2.64.5/glib/gmain.c:4047
#28 0x00007ff70cd3b18f in g_main_context_iteration (context=0xbb1e738b00, may_block=1) at ../glib-2.64.5/glib/gmain.c:4108
#29 0x0000561f1c870eaf in base::MessagePumpGlib::Run(base::MessagePump::Delegate*) ()
#30 0x0000561f1c8d76b2 in base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::Run(bool, base::TimeDelta) ()
#31 0x0000561f1c8a071c in base::RunLoop::Run() [clone .part.0] ()
#32 0x0000561f1cd74069 in ChromeBrowserMainParts::MainMessageLoopRun(int*) ()
#33 0x0000561f19f7b431 in content::BrowserMainLoop::RunMainMessageLoopParts() ()
#34 0x0000561f19f7d7b5 in content::BrowserMainRunnerImpl::Run() ()
#35 0x0000561f19f78289 in content::BrowserMain(content::MainFunctionParams const&) ()
#36 0x0000561f1c6564ff in content::ContentMainRunnerImpl::Run(bool) ()
#37 0x0000561f1c653976 in content::RunContentProcess(content::ContentMainParams const&, content::ContentMainRunner*) ()
#38 0x0000561f1c6540c2 in content::ContentMain(content::ContentMainParams const&) ()
#39 0x0000561f188c5855 in ChromeMain ()
#40 0x00007ff709054e0a in __libc_start_main (main=
    0x561f1888a450 <main>, argc=3, argv=0x7ffcf08f9858, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffcf08f9848) at ../csu/libc-start.c:314
#41 0x0000561f188c569a in _start ()

Dump of assembler code for function _ZN7content35ServiceWorkerRegistrationObjectHostD2Ev (content::ServiceWorkerRegistrationObjectHost::~ServiceWorkerRegistrationObjectHost()):
   0x0000561f1a5019e0 <+0>:     push   rbp
   0x0000561f1a5019e1 <+1>:     lea    rax,[rip+0xb633c10]        # 0x561f25b355f8 <_ZTVN7content35ServiceWorkerRegistrationObjectHostE+16>
   0x0000561f1a5019e8 <+8>:     mov    rbp,rsp
   0x0000561f1a5019eb <+11>:    push   r12
   0x0000561f1a5019ed <+13>:    push   rbx
   0x0000561f1a5019ee <+14>:    mov    rbx,rdi
   0x0000561f1a5019f1 <+17>:    mov    QWORD PTR [rdi],rax
   0x0000561f1a5019f4 <+20>:    add    rax,0x68
   0x0000561f1a5019f8 <+24>:    lea    rsi,[rbx+0x8]
   0x0000561f1a5019fc <+28>:    mov    QWORD PTR [rdi+0x8],rax
   0x0000561f1a501a00 <+32>:    mov    rdi,QWORD PTR [rdi+0x28]
   0x0000561f1a501a04 <+36>:    mov    rax,QWORD PTR [rdi]
   0x0000561f1a501a07 <+39>:    call   QWORD PTR [rax+0x8]
   0x0000561f1a501a0a <+42>:    lea    rdi,[rbx+0xb0]
   0x0000561f1a501a11 <+49>:    call   0x561f1c870660 <_ZN4base8internal18WeakPtrFactoryBaseD2Ev>
   0x0000561f1a501a16 <+54>:    mov    rdi,QWORD PTR [rbx+0xa8] ; rdi = rbx+0xa8[0:8]
   0x0000561f1a501a1d <+61>:    test   rdi,rdi
   0x0000561f1a501a20 <+64>:    je     0x561f1a501a28 <_ZN7content35ServiceWorkerRegistrationObjectHostD2Ev+72>
   0x0000561f1a501a22 <+66>:    mov    rax,QWORD PTR [rdi] ; rax = rdi[0:8]
=> 0x0000561f1a501a25 <+69>:    call   QWORD PTR [rax+0x8] ; rax+8 is not a valid address
   0x0000561f1a501a28 <+72>:    lea    rdi,[rbx+0x98]
   0x0000561f1a501a2f <+79>:    call   0x561f1d09e710 <_ZN4mojo8internal31AssociatedInterfacePtrStateBaseD2Ev>
   0x0000561f1a501a34 <+84>:    lea    rdi,[rbx+0x88]
   0x0000561f1a501a3b <+91>:    call   0x561f1c870660 <_ZN4base8internal18WeakPtrFactoryBaseD2Ev>
   0x0000561f1a501a40 <+96>:    mov    rdi,QWORD PTR [rbx+0x58]
   0x0000561f1a501a44 <+100>:   call   0x561f1a501960 <_ZNSt8_Rb_treeImSt4pairIKmSt10unique_ptrIN4mojo15ReceiverSetBaseINS3_18AssociatedReceiverIN5blink5mojom35ServiceWorkerRegistrationObjectHostENS3_19RawPtrImplRefTraitsIS8_EEEEvE5EntryESt14default_deleteISD_EEESt10_Select1stISH_ESt4lessImESaISH_EE8_M_eraseEPSt13_Rb_tree_nodeISH_E.isra.0>
   0x0000561f1a501a49 <+105>:   lea    rdi,[rbx+0x38]
   0x0000561f1a501a4d <+109>:   call   0x561f1c848490 <_ZN4base8internal12CallbackBaseD2Ev>
   0x0000561f1a501a52 <+114>:   lea    rdi,[rbx+0x30]
   0x0000561f1a501a56 <+118>:   call   0x561f1c848490 <_ZN4base8internal12CallbackBaseD2Ev>
   0x0000561f1a501a5b <+123>:   mov    r12,QWORD PTR [rbx+0x28]
   0x0000561f1a501a5f <+127>:   test   r12,r12
   0x0000561f1a501a62 <+130>:   je     0x561f1a501a81 <_ZN7content35ServiceWorkerRegistrationObjectHostD2Ev+161>
   0x0000561f1a501a64 <+132>:   lea    rdi,[r12+0x8]
   0x0000561f1a501a69 <+137>:   call   0x561f1c86e640 <_ZNK4base6subtle14RefCountedBase11ReleaseImplEv>
   0x0000561f1a501a6e <+142>:   mov    eax,DWORD PTR [r12+0x8]
   0x0000561f1a501a73 <+147>:   test   eax,eax
   0x0000561f1a501a75 <+149>:   jne    0x561f1a501a81 <_ZN7content35ServiceWorkerRegistrationObjectHostD2Ev+161>
   0x0000561f1a501a77 <+151>:   mov    rax,QWORD PTR [r12]
   0x0000561f1a501a7b <+155>:   mov    rdi,r12
   0x0000561f1a501a7e <+158>:   call   QWORD PTR [rax+0x18]
   0x0000561f1a501a81 <+161>:   lea    rdi,[rbx+0x18]
   0x0000561f1a501a85 <+165>:   pop    rbx
   0x0000561f1a501a86 <+166>:   pop    r12
   0x0000561f1a501a88 <+168>:   pop    rbp
   0x0000561f1a501a89 <+169>:   jmp    0x561f1c8705b0 <_ZN4base8internal11WeakPtrBaseD2Ev>

info registers
rax            0xffffd6a1ee5f9f1b  -45483999387877
rbx            0x295cb76933c0      45478190855104
rcx            0x0                 0
rdx            0x295cb8885050      45478209671248
rsi            0x295cb76933c8      45478190855112
rdi            0x295cba1a5e20      45478236020256
rbp            0x7ffe54dffa30      0x7ffe54dffa30
rsp            0x7ffe54dffa20      0x7ffe54dffa20
r8             0x0                 0
r9             0x10                16
r10            0x295caf314000      45478052970496
r11            0x295caf1a4200      45478051463680
r12            0x295cb76933c0      45478190855104
r13            0x295cb8374958      45478204361048
r14            0x0                 0
r15            0x295cb8374960      45478204361056
rip            0x55774958ba25      0x55774958ba25 <content::ServiceWorkerRegistrationObjectHost::~ServiceWorkerRegistrationObjectHost()+69>
eflags         0x10202             [ IF RF ]
cs             0x33                51
ss             0x2b                43
ds             0x0                 0
es             0x0                 0
fs             0x0                 0
gs             0x0                 0
Comment 13 Peter Levine 2020-10-25 07:54:27 UTC
Created attachment 668387 [details, diff]
service-worker-registration-double-destruction.patch

This is a candidate patch if anyone wants to help test.  Based on the first hunk of https://sources.debian.org/data/main/c/chromium/83.0.4103.116-3.1/debian/patches/fixes/serviceworker-double-destruction.patch with a few things changed (ServiceWorkerRegistrationObjectHost instead of ServiceWorkerObjectHost and registration_id instead of version_id).
Comment 14 Andrew Udvare 2020-10-25 09:29:56 UTC
(In reply to Peter Levine from comment #13)
> Created attachment 668387 [details, diff] [details, diff]
> service-worker-registration-double-destruction.patch
> 
> This is a candidate patch if anyone wants to help test.  Based on the first
> hunk of
> https://sources.debian.org/data/main/c/chromium/83.0.4103.116-3.1/debian/
> patches/fixes/serviceworker-double-destruction.patch with a few things
> changed (ServiceWorkerRegistrationObjectHost instead of
> ServiceWorkerObjectHost and registration_id instead of version_id).

I'm trying it out. Will report back.
Comment 15 Andrew Udvare 2020-10-26 03:48:18 UTC
I am running on the service-worker-registration-double-destruction.patch and things seem to work now. I am going to rebuild with USE=official and without nostrip and test again.

Is this really because of GCC vs Clang? It seems unusual that this would cause a pointer type issue. The official builds (Linux, macOS) use Clang and on those I've never seen this crash.
Comment 16 Peter Levine 2020-10-26 05:10:24 UTC
(In reply to Andrew Udvare from comment #15)
> I am running on the service-worker-registration-double-destruction.patch and
> things seem to work now. I am going to rebuild with USE=official and without
> nostrip and test again.
> 
> Is this really because of GCC vs Clang? It seems unusual that this would
> cause a pointer type issue. The official builds (Linux, macOS) use Clang and
> on those I've never seen this crash.

It looks like a cyclic ownership bug (see https://chromium-review.googlesource.com/c/chromium/src/+/2094496).  I'm guessing it shows up with a particular compiler or version because of changes in how it optimizes the code. I'm using clang-11 fwiw.
Comment 17 Andrew Udvare 2020-10-26 08:16:20 UTC
It would appear this patch fixes the issue. Been using the browser for quite some time with no issues (very refreshing).

This patch might only fix for those building with GCC and not what is posted at Chromium bugs https://bugs.chromium.org/p/chromium/issues/detail?id=1135070 (the OP is building with Clang).
Comment 18 Peter Levine 2020-10-26 19:36:25 UTC
(In reply to Andrew Udvare from comment #17)
> It would appear this patch fixes the issue. Been using the browser for quite
> some time with no issues (very refreshing).
> 
> This patch might only fix for those building with GCC and not what is posted
> at Chromium bugs
> https://bugs.chromium.org/p/chromium/issues/detail?id=1135070 (the OP is
> building with Clang).

AFAICT, all the builds in which this error is showing up are clang builds.  I'm not sure which toolchain version chromium project uses but I'm guessing it's not clang-10 or above.
Comment 19 Maciej S. Szmigiero 2020-10-26 22:55:31 UTC
Also hitting crashes in ~ServiceWorkerRegistrationObjectHost() with www-client/chromium-87.0.4280.20 and sys-devel/gcc-10.2.0.

Now rebuilding with the patch from comment 13, will see whether the browser will be stable.
Comment 20 Stephan Hartmann (RETIRED) gentoo-dev 2020-10-28 09:29:06 UTC
(In reply to Peter Levine from comment #18)
> (In reply to Andrew Udvare from comment #17)
> > It would appear this patch fixes the issue. Been using the browser for quite
> > some time with no issues (very refreshing).
> > 
> > This patch might only fix for those building with GCC and not what is posted
> > at Chromium bugs
> > https://bugs.chromium.org/p/chromium/issues/detail?id=1135070 (the OP is
> > building with Clang).
> 
> AFAICT, all the builds in which this error is showing up are clang builds. 
> I'm not sure which toolchain version chromium project uses but I'm guessing
> it's not clang-10 or above.

Thanks for working on this. I was bit busy last days and try to catch up again. Can you make a git formatted patch and add SBO to it? I want to include it in next beta/dev channel bumps. Do you take care of landing the patch upstream?

BTW:
Upstream uses clang git master. For bug reports I try to use clang as well, because it avoids discussions about using unsupported GCC. For this and the previous ServiceWorker crash it doesn't matter if you use GCC or clang. The problem here seems to be a slightly different behavior of libstdc++.
Comment 21 Andrew Udvare 2020-10-28 10:45:00 UTC
So should/will the ebuild go back to forcing Clang by default just in case?
Comment 22 Stephan Hartmann (RETIRED) gentoo-dev 2020-10-28 13:08:13 UTC
(In reply to Andrew Udvare from comment #21)
> So should/will the ebuild go back to forcing Clang by default just in case?

No, as long as we are able to build with GCC.
Comment 23 Maciej S. Szmigiero 2020-10-28 14:58:57 UTC
(In reply to Maciej S. Szmigiero from comment #19)
> Also hitting crashes in ~ServiceWorkerRegistrationObjectHost() with
> www-client/chromium-87.0.4280.20 and sys-devel/gcc-10.2.0.
> 
> Now rebuilding with the patch from comment 13, will see whether the browser
> will be stable.

The browser hasn't crashed yet for me after two days of usage so I guess the above patch fixed this issue (previously it would crash after 2-3 hours of browsing).

Also, looking at that patch description it is a real use-after-free bug in the code, so it should be patched anyway.

Please mark this bug report as CONFIRMED and include the aforementioned patch in www-client/chromium ebuild.
Comment 24 Alexey Shvetsov archtester gentoo-dev 2020-10-28 16:49:04 UTC
I have same  problem with 87.0.4280.27

gcc --version
gcc (Gentoo 10.2.0-r2 p3) 10.2.0


clang --version
clang version 11.0.0
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/lib/llvm/11/bin
Comment 25 Andrew Udvare 2020-10-28 18:34:24 UTC
(In reply to Maciej S. Szmigiero from comment #23)
> (In reply to Maciej S. Szmigiero from comment #19)
> > Also hitting crashes in ~ServiceWorkerRegistrationObjectHost() with
> > www-client/chromium-87.0.4280.20 and sys-devel/gcc-10.2.0.
> > 
> > Now rebuilding with the patch from comment 13, will see whether the browser
> > will be stable.
> 
> The browser hasn't crashed yet for me after two days of usage so I guess the
> above patch fixed this issue (previously it would crash after 2-3 hours of
> browsing).
> 
> Also, looking at that patch description it is a real use-after-free bug in
> the code, so it should be patched anyway.
> 
> Please mark this bug report as CONFIRMED and include the aforementioned
> patch in www-client/chromium ebuild.

Please test with www-client/chromium-87.0.4280.27

I am testing this now.
Comment 26 Mike Gilbert gentoo-dev 2020-10-28 19:15:39 UTC
Any patches(s) should be sent upstream, and we can backport from there. Thanks.
Comment 27 Peter Levine 2020-10-28 21:43:55 UTC
(In reply to Stephan Hartmann from comment #20)
> (In reply to Peter Levine from comment #18)
> > (In reply to Andrew Udvare from comment #17)
> > > It would appear this patch fixes the issue. Been using the browser for quite
> > > some time with no issues (very refreshing).
> > > 
> > > This patch might only fix for those building with GCC and not what is posted
> > > at Chromium bugs
> > > https://bugs.chromium.org/p/chromium/issues/detail?id=1135070 (the OP is
> > > building with Clang).
> > 
> > AFAICT, all the builds in which this error is showing up are clang builds. 
> > I'm not sure which toolchain version chromium project uses but I'm guessing
> > it's not clang-10 or above.
> 
> Thanks for working on this. I was bit busy last days and try to catch up
> again. Can you make a git formatted patch and add SBO to it? I want to
> include it in next beta/dev channel bumps. Do you take care of landing the
> patch upstream?
> 
> BTW:
> Upstream uses clang git master. For bug reports I try to use clang as well,
> because it avoids discussions about using unsupported GCC. For this and the
> previous ServiceWorker crash it doesn't matter if you use GCC or clang. The
> problem here seems to be a slightly different behavior of libstdc++.

I could do that in the next day or two.

SBO?
Comment 28 Jan Baklo 2020-10-29 07:41:34 UTC
Version 87.0.4280.27 also crashes randomly. At the same time, one oddity was noticed, it almost does not fall in the period from 00:00 to 16:00 UTC, but often begins to fall from 16:00 to 00:00 UTC. The time ranges specified approximately.
Comment 29 Andrew Udvare 2020-10-29 09:39:41 UTC
(In reply to Jan Baklo from comment #28)
> Version 87.0.4280.27 also crashes randomly. At the same time, one oddity was
> noticed, it almost does not fall in the period from 00:00 to 16:00 UTC, but
> often begins to fall from 16:00 to 00:00 UTC. The time ranges specified
> approximately.

Version 87.0.4280.27 works with the patch. I have not had a crash all day and I've left the browser open on sites that use WebWorkers for many hours.

Also sorry but I am a bit sceptical that it has anything to do with the time.
Comment 30 Stephan Hartmann (RETIRED) gentoo-dev 2020-10-29 10:16:08 UTC
(In reply to Peter Levine from comment #27)
> (In reply to Stephan Hartmann from comment #20)
> > (In reply to Peter Levine from comment #18)
> > > (In reply to Andrew Udvare from comment #17)
> > > > It would appear this patch fixes the issue. Been using the browser for quite
> > > > some time with no issues (very refreshing).
> > > > 
> > > > This patch might only fix for those building with GCC and not what is posted
> > > > at Chromium bugs
> > > > https://bugs.chromium.org/p/chromium/issues/detail?id=1135070 (the OP is
> > > > building with Clang).
> > > 
> > > AFAICT, all the builds in which this error is showing up are clang builds. 
> > > I'm not sure which toolchain version chromium project uses but I'm guessing
> > > it's not clang-10 or above.
> > 
> > Thanks for working on this. I was bit busy last days and try to catch up
> > again. Can you make a git formatted patch and add SBO to it? I want to
> > include it in next beta/dev channel bumps. Do you take care of landing the
> > patch upstream?
> > 
> > BTW:
> > Upstream uses clang git master. For bug reports I try to use clang as well,
> > because it avoids discussions about using unsupported GCC. For this and the
> > previous ServiceWorker crash it doesn't matter if you use GCC or clang. The
> > problem here seems to be a slightly different behavior of libstdc++.
> 
> I could do that in the next day or two.
> 
> SBO?

Typo: SOB = Signed-Off-By
Comment 31 Jan Baklo 2020-10-29 11:46:47 UTC
(In reply to Andrew Udvare from comment #29)
> (In reply to Jan Baklo from comment #28)
> > Version 87.0.4280.27 also crashes randomly. At the same time, one oddity was
> > noticed, it almost does not fall in the period from 00:00 to 16:00 UTC, but
> > often begins to fall from 16:00 to 00:00 UTC. The time ranges specified
> > approximately.
> 
> Version 87.0.4280.27 works with the patch. I have not had a crash all day
> and I've left the browser open on sites that use WebWorkers for many hours.
> 
> Also sorry but I am a bit sceptical that it has anything to do with the time.

I'm not trying to lie, this is just my observation. Between 01:00 and 15:00 UTC, the browser hardly crashes. But before 01:00 and after 15:00 it starts to crash without any characteristic behavior in the script that can be reproduced. At the same time, I consistently use it in the same way at different times, without any additional deviations, opening other sites or using something more than when it works stably. And again, the first few builds of the 86th version had approximately the same behavior. Maybe the whole point is that up to 20 inactive tabs open for me, but they don't reload after starting the browser, but I don't think that this affects the crashes, since other users probably don't have many open tabs.
Comment 32 Maciej S. Szmigiero 2020-10-30 01:05:34 UTC
www-client/chromium-87.0.4280.27 with sys-devel/gcc-10.2.0 looks fine with the patch from comment 13, which in turn seems to be based on https://chromium-review.googlesource.com/c/chromium/src/+/2094496
Comment 33 Jan Baklo 2020-10-30 05:58:37 UTC
www-client/chromium-87.0.4280.27 the crash has now occurred outside of the previously noted time range when falls are more frequent.

Received signal 11 SEGV_MAPERR ffffc21a74511cf7
#0 0x5628d58a9169 base::debug::CollectStackTrace()
#1 0x5628d57fcb16 base::debug::StackTrace::StackTrace()
#2 0x5628d58a8bab base::debug::(anonymous namespace)::StackDumpSignalHandler()
#3 0x7f660f47c9b0 (/lib64/libpthread-2.32.so+0x129af)
#4 0x5628d346e545 content::ServiceWorkerRegistrationObjectHost::~ServiceWorkerRegistrationObjectHost()
#5 0x5628d346e5c2 content::ServiceWorkerRegistrationObjectHost::~ServiceWorkerRegistrationObjectHost()
#6 0x5628d3403e2b std::_Rb_tree<>::_M_erase()
#7 0x5628d33fc758 content::ServiceWorkerContainerHost::~ServiceWorkerContainerHost()
#8 0x5628d33fc912 content::ServiceWorkerContainerHost::~ServiceWorkerContainerHost()
#9 0x5628d343f2e6 content::ServiceWorkerHost::~ServiceWorkerHost()
#10 0x5628d34b60ec content::ServiceWorkerVersion::~ServiceWorkerVersion()
#11 0x5628d34b6392 content::ServiceWorkerVersion::~ServiceWorkerVersion()
#12 0x5628d346c276 content::ServiceWorkerRegistration::~ServiceWorkerRegistration()
#13 0x5628d346c2f2 content::ServiceWorkerRegistration::~ServiceWorkerRegistration()
#14 0x5628d346e5a1 content::ServiceWorkerRegistrationObjectHost::~ServiceWorkerRegistrationObjectHost()
#15 0x5628d346e5c2 content::ServiceWorkerRegistrationObjectHost::~ServiceWorkerRegistrationObjectHost()
#16 0x5628d3403e2b std::_Rb_tree<>::_M_erase()
#17 0x5628d33fc04a content::ServiceWorkerContainerHost::RemoveServiceWorkerRegistrationObjectHost()
#18 0x5628d34727a7 mojo::ReceiverSetBase<>::Entry::OnDisconnect()
#19 0x5628d6049c4f mojo::InterfaceEndpointClient::NotifyError()
#20 0x5628d604e6ca mojo::internal::MultiplexRouter::ProcessNotifyErrorTask()
#21 0x5628d604fe33 mojo::internal::MultiplexRouter::ProcessTasks()
#22 0x5628d6052c62 mojo::internal::MultiplexRouter::OnPipeConnectionError()
#23 0x5628d60480a0 mojo::Connector::HandleError()
#24 0x5628d606b5e6 mojo::SimpleWatcher::OnHandleReady()
#25 0x5628d5869092 base::TaskAnnotator::RunTask()
#26 0x5628d587e94d base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::DoWorkImpl()
#27 0x5628d587ecee base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::DoWork()
#28 0x5628d58173da base::MessagePumpGlib::Run()
#29 0x5628d587dc73 base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::Run()
#30 0x5628d58468ec base::RunLoop::Run()
#31 0x5628d5d1c5b9 ChromeBrowserMainParts::MainMessageLoopRun()
#32 0x5628d2ee4071 content::BrowserMainLoop::RunMainMessageLoopParts()
#33 0x5628d2ee6435 content::BrowserMainRunnerImpl::Run()
#34 0x5628d2ee0ec9 content::BrowserMain()
#35 0x5628d55fbda0 content::ContentMainRunnerImpl::Run()
#36 0x5628d55f9208 content::RunContentProcess()
#37 0x5628d55f9962 content::ContentMain()
#38 0x5628d18444a5 ChromeMain
#39 0x7f660b55be2a __libc_start_main
#40 0x5628d18442ea _start
  r8: 0000000000004000  r9: 0000000000000018 r10: 00003de7375bc780 r11: 00007f660b6c1a40
 r12: 00003de739f96540 r13: 00003de744085d58 r14: 0000000000000000 r15: 00003de744085d60
  di: 00003de739419470  si: 00003de739f96548  bp: 00007ffd188d7ec0  bx: 00003de739f96540
  dx: 00003de742b5d3a0  ax: ffffc21a74511cef  cx: 0000000000000000  sp: 00007ffd188d7eb0
  ip: 00005628d346e545 efl: 0000000000010202 cgf: 002b000000000033 erf: 0000000000000005
 trp: 000000000000000e msk: 0000000000000000 cr2: ffffc21a74511cf7
[end of stack trace]
Calling _exit(1). Core file will not be generated.
Comment 34 Larry the Git Cow gentoo-dev 2020-10-30 19:57:59 UTC
The bug has been closed via the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=491122faf23d00adaf1c297a7604878f9a4ce783

commit 491122faf23d00adaf1c297a7604878f9a4ce783
Author:     Stephan Hartmann <sultan@gentoo.org>
AuthorDate: 2020-10-30 19:56:45 +0000
Commit:     Stephan Hartmann <sultan@gentoo.org>
CommitDate: 2020-10-30 19:57:08 +0000

    www-client/chromium: beta channel bump to 87.0.4280.40
    
    Closes: https://bugs.gentoo.org/750038
    Package-Manager: Portage-3.0.8, Repoman-3.0.2
    Signed-off-by: Stephan Hartmann <sultan@gentoo.org>

 www-client/chromium/Manifest                                          | 4 ++--
 .../{chromium-87.0.4280.27.ebuild => chromium-87.0.4280.40.ebuild}    | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)