Bug 1160068

Same version 79.0.3945.88-2.1 (openSUSE Build) (64-bit) on Tumbleweed.

Also have this issue as well, if the browser startup happens when Chromecast (one of the original versions, but up-to-date firmware-wise) is powered up (even though on a different subnet/IP range, but still routable to).

If one turns off the respective TV powering the Chromecast, browser startup works fine (albeit the restore of open tabs seems to be affected). Yet if the Chromecast is turned back on (even if not in direct use) while the browser is running, it crashes within the startup period of Chromecast.

CLI startup while Chromecast is on ...
failed to open /usr/lib64/dri/hybrid_drv_video.so
Not using hybrid_drv_video.so
[4001316:4001316:0109/082242.555657:ERROR:sandbox_linux.cc(372)] InitializeSandbox() called with multiple threads in process gpu-process.
[4001316:4001316:0109/082243.113906:ERROR:buffer_manager.cc(488)] [.DisplayCompositor]GL ERROR :GL_INVALID_OPERATION : glBufferData: <- error from previous GL command
[4001319:4001326:0109/082243.125683:ERROR:nss_util.cc(283)] After loading Root Certs, loaded==false: NSS error code: -8018
[4001362:1:0109/082249.139763:ERROR:child_process_sandbox_support_impl_linux.cc(79)] FontService unique font name matching request did not receive a response.
Received signal 11 SEGV_MAPERR 000000000001
#0 0x55d96baecc46 base::debug::StackTrace::StackTrace()
#1 0x55d96ba9f896 base::debug::(anonymous namespace)::StackDumpSignalHandler()
#2 0x55d96ba9fe9e base::debug::(anonymous namespace)::StackDumpSignalHandler()
#3 0x7ff8fe94d2d0 <unknown>
#4 0x7ff8faed66b6 __GI___strlen_sse2
#5 0x55d96a11e324 cast_channel::KeepAliveDelegate::OnMessage()
#6 0x55d96a1407df cast_channel::CastTransportImpl::OnReadResult()
#7 0x55d96a0bfbb6 base::internal::Invoker<>::RunOnce()
#8 0x55d96a0cd361 cast_channel::MojoDataPump::ReceiveMore()
#9 0x55d96a0bfa66 base::internal::Invoker<>::Run()
#10 0x55d96b92cdb7 mojo::SimpleWatcher::OnHandleReady()
#11 0x55d96b907201 base::internal::Invoker<>::RunOnce()
#12 0x55d96bb5cec9 base::TaskAnnotator::RunTask()
#13 0x55d96baca0bd base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::DoWorkImpl()
#14 0x55d96bacf7a7 base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::DoSomeWork()
#15 0x55d96baca5f0 base::MessagePumpLibevent::Run()
#16 0x55d96bacc19d base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::Run()
#17 0x55d96bb417eb base::RunLoop::Run()
#18 0x55d96d87d450 content::BrowserProcessSubThread::IOThreadRun()
#19 0x55d96d87d49c content::BrowserProcessSubThread::Run()
#20 0x55d96bac6c5a base::Thread::ThreadMain()
#21 0x55d96bab8a38 base::(anonymous namespace)::ThreadFunc()
#22 0x7ff8fe941f2a start_thread
#23 0x7ff8faf374af __GI___clone
  r8: 000000000000ff80  r9: 00007ff8f251fba8 r10: 00007ff8f251fba0 r11: 00007ff8fafcc120
 r12: 000039f419b724b0 r13: 000039f41ca30820 r14: 0000000000000001 r15: 000039f419ec8420
  di: 0000000000000001  si: 000055d96ed34147  bp: 00007ff8f251fe10  bx: 000039f41cd4e870
  dx: 00000000000000e9  ax: 0000000000000001  cx: 0000000000000001  sp: 00007ff8f251fdd8
  ip: 00007ff8faed66b6 efl: 0000000000010293 cgf: 002b000000000033 erf: 0000000000000004
 trp: 000000000000000e msk: 0000000000000000 cr2: 0000000000000001
[end of stack trace]
Calling _exit(1). Core file will not be generated.

Confirming workaround, disconnecting chromecast allows chromium to start correctly on my Tumbleweed workstations.

Issue was not affecting google-chrome browser, vivaldi (based on chromium) or chromium running on other distributions, but affected all versions of chromium available in the tumbleweed repositories (official and community) on my machines.

question Michael and Bryan, how did you recognize the chromecast connection to this issue?

The hint was "cast_channel" mentioned in the stack trace.

> but affected all versions of chromium available in the tumbleweed repositories

Only v79. All flavors of them though.

Thanks Michael, I learned something. 
And yes Dmitry version 79 is a far more accurate than my statement.
The tumbleweed packges I tested were all 79(.0.3945xxx) releases, I think.
Thank you both

as I can't unplug my chromecast as it's built into the a/v receiver - any chromium side workarounds? :(

Apparently its only opensuse chromium builds which are affected. So you can download chrome or vivaldi. Or lock the version to 78 in the package manager, so it wont upgrade it.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833477 suggested 
-disable-features=EnableCastDiscovery - which does the trick.

(In reply to Stephan Kulow from comment #8)
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833477 suggested 
> -disable-features=EnableCastDiscovery - which does the trick.

Thanks Stephan ... confirming that startup arg does provide a viable workaround

(In reply to Bryan Gartner from comment #9)
> (In reply to Stephan Kulow from comment #8)
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833477 suggested 
> > -disable-features=EnableCastDiscovery - which does the trick.
> 
> Thanks Stephan ... confirming that startup arg does provide a viable
> workaround

I still didn't manage to crash my chromium even if I had my phone chromecasting to TV...

You can also run the package in debug mode to attach to gdb so you can get backtraces.

See the /etc/default/chromium and the /usr/bin/chromium script.

*** Bug 1162917 has been marked as a duplicate of this bug. ***

This is fixed by chromium-80 release.

Please reopen if it is still happening but to my best knowledge this should be fine now.

(In reply to Tomáš Chvátal from comment #12)
> This is fixed by chromium-80 release.
> 
> Please reopen if it is still happening but to my best knowledge this should
> be fine now.

Also validated the new version works for me w/o the respective FLAG ( -disable-features=EnableCastDiscovery ) workaround, many thanks!

Seems to be back again on TW with ...

chromium --version
Chromium 84.0.4147.125


failed to open /usr/lib64/dri/hybrid_drv_video.so
Not using hybrid_drv_video.so
[145931:145931:0815/162931.550533:ERROR:sandbox_linux.cc(374)] InitializeSandbox() called with multiple threads in process gpu-process.
[145934:145956:0815/162932.580279:ERROR:nss_util.cc(283)] After loading Root Certs, loaded==false: NSS error code: -8018
tcmalloc: large alloc 1983418368 bytes == 0xfc9ea56000 @  0x55b86e482174 0x55b86e482358 0x55b868d58220 0x55b868d7352a 0x55b86ddeccef 0x55b868da53a7 0x55b86a5f72bd 0x55b86a5f77c8 0x55b86a5f7be9 0x55b86a528386 0x55b866d25ef1 0x55b866d3447f 0x55b866b54256 0x55b868e3979c 0x55b868e7e487 0x55b868e76b30 0x55b868e7ab7d 0x55b868e33f89 0x55b866ef0524 0x55b866ef05ac 0x55b868e4300e 0x55b868e65ad3 0x7f5f7a08feaa
Received signal 11 SEGV_MAPERR 55b8e69d3490
#0 0x55b868d71931 base::debug::(anonymous namespace)::StackDumpSignalHandler()
#1 0x7f5f7a09b260 (/lib64/libpthread-2.31.so+0x1425f)
#2 0x7f5f7604a9d1 __memcpy_sse2_unaligned_erms
#3 0x55b86ddecd09 std::__cxx11::basic_string<>::_M_construct<>()
#4 0x55b868da53a7 base::Value::Value()
#5 0x55b86a5f72bd cast_channel::(anonymous namespace)::CreateKeepAliveMessage()
#6 0x55b86a5f77c8 cast_channel::CastSocketImpl::DoConnectCallback()
#7 0x55b86a5f7be9 cast_channel::CastSocketImpl::DoConnectLoop()
#8 0x55b86a528386 base::internal::Invoker<>::Run()
#9 0x55b866d25ef1 base::internal::CancelableCallbackImpl<>::ForwardRepeating<>()
#10 0x55b866d3447f base::internal::Invoker<>::Run()
#11 0x55b866b54256 base::internal::Invoker<>::RunOnce()
#12 0x55b868e3979c base::TaskAnnotator::RunTask()
#13 0x55b868e7e487 base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::DoWork()
#14 0x55b868e76b30 base::MessagePumpLibevent::Run()
#15 0x55b868e7ab7d base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::Run()
#16 0x55b868e33f89 base::RunLoop::Run()
#17 0x55b866ef0524 content::BrowserProcessSubThread::IOThreadRun()
#18 0x55b866ef05ac content::BrowserProcessSubThread::Run()
#19 0x55b868e4300e base::Thread::ThreadMain()
#20 0x55b868e65ad3 base::(anonymous namespace)::ThreadFunc()
#21 0x7f5f7a08feaa start_thread
#22 0x7f5f760a1aff __GI___clone
  r8: 0000000000000000  r9: 00007f5f6cb3fdb0 r10: 00007f5f6cb40600 r11: 0000000000000000
 r12: 0000000076388510 r13: 000055b87064af90 r14: 00007f5f6cb40780 r15: 00007f5f6cb40770
  di: 000000fc9ea56000  si: 000055b87064af90  bp: 00007f5f6cb406b0  bx: 00007f5f6cb406d0
  dx: 0000000076388510  ax: 000000fc9ea56000  cx: 00007f5f7a09a10f  sp: 00007f5f6cb40658
  ip: 00007f5f7604a9d1 efl: 0000000000010283 cgf: 002b000000000033 erf: 0000000000000004
 trp: 000000000000000e msk: 0000000000000000 cr2: 000055b8e69d3490
[end of stack trace]
Calling _exit(1). Core file will not be generated.
[145934:145955:0815/162935.878442:ERROR:broker_posix.cc(40)] Recvmsg error: Connection reset by peer (104)

*** Bug 1175307 has been marked as a duplicate of this bug. ***

*** Bug 1175459 has been marked as a duplicate of this bug. ***

It seems that the chromecast devices in the network (in my case it is a smart tv) causes Chromium crash, but the proposed workaround -disable-features=EnableCastDiscovery doesn't work for me. 
I confirm google chrome doesn't have any problem

With the last tumbleweed snapshot, chromium still has the bug

*** Bug 1175860 has been marked as a duplicate of this bug. ***

Google Home Mini also triggers the issue.

the "-disable-features=EnableCastDiscovery" switch did not help.

chromium-84.0.4147.135-3.1.x86_64 on TW 20200901

A workaround for the issue is filtering out TCP port 8008 and 8009 with netfilter locally:

-A INPUT -p tcp -m tcp --sport 8009 -j REJECT --reject-with icmp-port-unreachable
-A INPUT -p tcp -m tcp --dport 8009 -j REJECT --reject-with icmp-port-unreachable
-A INPUT -p tcp -m tcp --sport 8008 -j REJECT --reject-with icmp-port-unreachable
-A INPUT -p tcp -m tcp --dport 8008 -j REJECT --reject-with icmp-port-unreachable

Same issue, -disable-features=EnableCastDiscovery workaround not working.

Confirming the workaround of blocking TCP ports 8008 and 8009, which I did with firewalld instead. Not ideal though.

(In reply to jean-christophe baptiste from comment #23)
> Confirming the workaround of blocking TCP ports 8008 and 8009, which I did
> with firewalld instead. Not ideal though.

Hi, can you write here how to block these ports? Thanks in advance

(In reply to Ferdinando Vivacqua from comment #24)
> (In reply to jean-christophe baptiste from comment #23)
> > Confirming the workaround of blocking TCP ports 8008 and 8009, which I did
> > with firewalld instead. Not ideal though.
> 
> Hi, can you write here how to block these ports? Thanks in advance

Something like:

sudo firewall-cmd --permanent --add-rich-rule='rule family=tcp port port="8008" protocol="tcp" reject'
sudo firewall-cmd --permanent --add-rich-rule='rule family=tcp port port="8009" protocol="tcp" reject'

I suggest that you install "firewall-config" if you want to have a nice GUI for that stuff.

It doesn't work for me.
I fixed with iptables -A OUTPUT -p tcp --destination-port 8008 -j DROP
iptables -A OUTPUT -p tcp --destination-port 8009 -j DROP

(In reply to Ferdinando Vivacqua from comment #26)
> It doesn't work for me.
> I fixed with iptables -A OUTPUT -p tcp --destination-port 8008 -j DROP
> iptables -A OUTPUT -p tcp --destination-port 8009 -j DROP

It does and it's the right way to manage rules in the default settings. It's just that you have not reloaded firewalld (or rebooted). You should have searched a bit because it's not a help forum.

(In reply to jean-christophe baptiste from comment #27)
> (In reply to Ferdinando Vivacqua from comment #26)
> > It doesn't work for me.
> > I fixed with iptables -A OUTPUT -p tcp --destination-port 8008 -j DROP
> > iptables -A OUTPUT -p tcp --destination-port 8009 -j DROP
> 
> It does and it's the right way to manage rules in the default settings. It's
> just that you have not reloaded firewalld (or rebooted). You should have
> searched a bit because it's not a help forum.
>
Mmm... Interestingly, I did this:

# firewall-cmd --permanent --add-rich-rule='rule family=ipv4 port port="8009" protocol="tcp" reject'
success
# firewall-cmd --reload 
success
# firewall-cmd --list-all
home (active)
  target: default
  icmp-block-inversion: no
  interfaces: wlp58s0
  sources: 
  services: dhcpv6-client mdns samba-client ssh syncthing syncthing-gui
  ports: 
  protocols: 
  masquerade: no
  forward-ports: 
  source-ports: 
  icmp-blocks: 
  rich rules: 
	rule family="ipv4" port port="8009" protocol="tcp" reject

(note that there was a typo in your rule: "family=tcp" needs to be "family=ipv4", I think)

But I can still connect:

$ telnet portquiz.net 8008
Trying 52.47.209.216...
Connected to portquiz.net.
Escape character is '^]'.
^]

OTOH, this:

# firewall-cmd --permanent --direct --add-rule ipv4 filter OUTPUT 0 -p tcp -m tcp --dport=8008 -j DROP
success
# sudo firewall-cmd --reload 
success
# firewall-cmd --direct --get-all-rules
ipv4 filter OUTPUT 0 -p tcp -m tcp --dport=8008 -j DROP

Works for me:

$  telnet portquiz.net 8008
Trying 52.47.209.216...

(In reply to Dario Faggioli from comment #28)
> (In reply to jean-christophe baptiste from comment #27)
> > (In reply to Ferdinando Vivacqua from comment #26)
> > > It doesn't work for me.
> > > I fixed with iptables -A OUTPUT -p tcp --destination-port 8008 -j DROP
> > > iptables -A OUTPUT -p tcp --destination-port 8009 -j DROP
> > 
> > It does and it's the right way to manage rules in the default settings. It's
> > just that you have not reloaded firewalld (or rebooted). You should have
> > searched a bit because it's not a help forum.
> >
> Mmm... Interestingly, I did this:
> 
> # firewall-cmd --permanent --add-rich-rule='rule family=ipv4 port
> port="8009" protocol="tcp" reject'
> success
> # firewall-cmd --reload 
> success
> # firewall-cmd --list-all
> home (active)
>   target: default
>   icmp-block-inversion: no
>   interfaces: wlp58s0
>   sources: 
>   services: dhcpv6-client mdns samba-client ssh syncthing syncthing-gui
>   ports: 
>   protocols: 
>   masquerade: no
>   forward-ports: 
>   source-ports: 
>   icmp-blocks: 
>   rich rules: 
> 	rule family="ipv4" port port="8009" protocol="tcp" reject
> 
> (note that there was a typo in your rule: "family=tcp" needs to be
> "family=ipv4", I think)
> 
Err, and now there's a typo in mine :-)

I mixed the output of different tests! Trying again... This is what I have:

# firewall-cmd --list-all
home (active)
  target: default
  icmp-block-inversion: no
  interfaces: wlp58s0
  sources: 
  services: dhcpv6-client mdns samba-client ssh syncthing syncthing-gui
  ports: 
  protocols: 
  masquerade: no
  forward-ports: 
  source-ports: 
  icmp-blocks: 
  rich rules: 
	rule family="ipv4" port port="8009" protocol="tcp" reject
	rule family="ipv4" port port="8008" protocol="tcp" reject
# firewall-cmd --direct --get-all-rules 
ipv4 filter OUTPUT 0 -p tcp -m tcp --dport=8008 -j DROP
# firewall-cmd --reload 
success

So, there's a rich-rule for both ports 8008 and 8009, and a direct rule for 8008.

Now:

$ telnet portquiz.net 8008
Trying 52.47.209.216...
^C

$ telnet portquiz.net 8009
Trying 52.47.209.216...
Connected to portquiz.net.
Escape character is '^]'.
^]

I.e., I can't connect to 8008 (for which I have the direct rule in place), while I can happily connect to 8009 (for which I have only the rich rule).

If I remove the rich rule for 8008, leaving only the direct rule, I still can't connect. 

If I add a direct rule for 8009, I can't connect any longer.

So it looks like it's the direct rule that does the trick, while the rich rules are not really effective, in this case.

(In reply to Dario Faggioli from comment #29)
> (In reply to Dario Faggioli from comment #28)
> > (In reply to jean-christophe baptiste from comment #27)
> > > (In reply to Ferdinando Vivacqua from comment #26)
> > > > It doesn't work for me.
> > > > I fixed with iptables -A OUTPUT -p tcp --destination-port 8008 -j DROP
> > > > iptables -A OUTPUT -p tcp --destination-port 8009 -j DROP
> > > 
> > > It does and it's the right way to manage rules in the default settings. It's
> > > just that you have not reloaded firewalld (or rebooted). You should have
> > > searched a bit because it's not a help forum.
> > >
> > Mmm... Interestingly, I did this:
> > 
> > # firewall-cmd --permanent --add-rich-rule='rule family=ipv4 port
> > port="8009" protocol="tcp" reject'
> > success
> > # firewall-cmd --reload 
> > success
> > # firewall-cmd --list-all
> > home (active)
> >   target: default
> >   icmp-block-inversion: no
> >   interfaces: wlp58s0
> >   sources: 
> >   services: dhcpv6-client mdns samba-client ssh syncthing syncthing-gui
> >   ports: 
> >   protocols: 
> >   masquerade: no
> >   forward-ports: 
> >   source-ports: 
> >   icmp-blocks: 
> >   rich rules: 
> > 	rule family="ipv4" port port="8009" protocol="tcp" reject
> > 
> > (note that there was a typo in your rule: "family=tcp" needs to be
> > "family=ipv4", I think)
> > 
> Err, and now there's a typo in mine :-)
> 
> I mixed the output of different tests! Trying again... This is what I have:
> 
> # firewall-cmd --list-all
> home (active)
>   target: default
>   icmp-block-inversion: no
>   interfaces: wlp58s0
>   sources: 
>   services: dhcpv6-client mdns samba-client ssh syncthing syncthing-gui
>   ports: 
>   protocols: 
>   masquerade: no
>   forward-ports: 
>   source-ports: 
>   icmp-blocks: 
>   rich rules: 
> 	rule family="ipv4" port port="8009" protocol="tcp" reject
> 	rule family="ipv4" port port="8008" protocol="tcp" reject
> # firewall-cmd --direct --get-all-rules 
> ipv4 filter OUTPUT 0 -p tcp -m tcp --dport=8008 -j DROP
> # firewall-cmd --reload 
> success
> 
> So, there's a rich-rule for both ports 8008 and 8009, and a direct rule for
> 8008.
> 
> Now:
> 
> $ telnet portquiz.net 8008
> Trying 52.47.209.216...
> ^C
> 
> $ telnet portquiz.net 8009
> Trying 52.47.209.216...
> Connected to portquiz.net.
> Escape character is '^]'.
> ^]
> 
> I.e., I can't connect to 8008 (for which I have the direct rule in place),
> while I can happily connect to 8009 (for which I have only the rich rule).
> 
> If I remove the rich rule for 8008, leaving only the direct rule, I still
> can't connect. 
> 
> If I add a direct rule for 8009, I can't connect any longer.
> 
> So it looks like it's the direct rule that does the trick, while the rich
> rules are not really effective, in this case.

I confirm that this workaround works.
We will wait for a fixed Chromium build.

Is it only me or the latest update fixed this?

(In reply to jean-christophe baptiste from comment #31)
> Is it only me or the latest update fixed this?


No, I still have the problem, even with the last release

I confirm the 85.0.4183.102 release still has the problem

I have similar crashes as described with Chromium 85.0.4183.121, only seconds after launch:

thommie@locutus:~> chromium 
tcmalloc: large alloc 1252900864 bytes == 0x367c0bf21000 @  0x55d7b6855a74 0x55d7b6855b9b 0x55d7b0f01090 0x55d7b0f19f0a 0x55d7b6134edf 0x55d7b0f46077 0x55d7b28b18dd 0x55d7b28b1de8 0x55d7b28b2209 0x55d7b27df786 0x55d7aee1fdb1 0x55d7aee2a55f 0x55d7aeb601c6 0x55d7b0ff065c 0x55d7b103171f 0x55d7b1028f70 0x55d7b102ddcd 0x55d7b0fe5a09 0x55d7aeff4234 0x55d7aeff42bc 0x55d7b0fed1ee 0x55d7b1017af3 0x7f514e5d5eaa
Received signal 11 SEGV_MAPERR 55d803587eb0
#0 0x55d7b0f8e351 base::debug::(anonymous namespace)::StackDumpSignalHandler()
#1 0x7f514e5e1260 (/lib64/libpthread-2.31.so+0x1425f)
#2 0x7f514a85c3e0 __memmove_avx_unaligned_erms
#3 0x55d7b6134ef9 std::__cxx11::basic_string<>::_M_construct<>()
#4 0x55d7b0f46077 base::Value::Value()
#5 0x55d7b28b18dd cast_channel::(anonymous namespace)::CreateKeepAliveMessage()
#6 0x55d7b28b1de8 cast_channel::CastSocketImpl::DoConnectCallback()
#7 0x55d7b28b2209 cast_channel::CastSocketImpl::DoConnectLoop()
#8 0x55d7b27df786 base::internal::Invoker<>::Run()
#9 0x55d7aee1fdb1 base::internal::CancelableCallbackImpl<>::ForwardRepeating<>()
#10 0x55d7aee2a55f base::internal::Invoker<>::Run()
#11 0x55d7aeb601c6 base::internal::Invoker<>::RunOnce()
#12 0x55d7b0ff065c base::TaskAnnotator::RunTask()
#13 0x55d7b103171f base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::DoWork()
#14 0x55d7b1028f70 base::MessagePumpLibevent::Run()
#15 0x55d7b102ddcd base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::Run()
#16 0x55d7b0fe5a09 base::RunLoop::Run()
#17 0x55d7aeff4234 content::BrowserProcessSubThread::IOThreadRun()
#18 0x55d7aeff42bc content::BrowserProcessSubThread::Run()
#19 0x55d7b0fed1ee base::Thread::ThreadMain()
#20 0x55d7b1017af3 base::(anonymous namespace)::ThreadFunc()
#21 0x7f514e5d5eaa start_thread
#22 0x7f514a7f6aff __GI___clone
  r8: 0000000000000000  r9: 00007f5141026df0 r10: 00007f5141027540 r11: 0000000000000000
 r12: 000000004aadb500 r13: 000055d7b8aac9d0 r14: 00007f5141027740 r15: 00007f5141027730
  di: 0000367c0bf21000  si: 000055d7b8aac9d0  bp: 00007f5141027670  bx: 00007f5141027690
  dx: 000000004aadb500  ax: 0000367c0bf21000  cx: 00007f514e5e010f  sp: 00007f5141027618
  ip: 00007f514a85c3e0 efl: 0000000000010287 cgf: 002b000000000033 erf: 0000000000000004
 trp: 000000000000000e msk: 0000000000000000 cr2: 000055d803587eb0
[end of stack trace]
Calling _exit(1). Core file will not be generated.

The given firewalld commands gave me peace.

Hmmmm, ok, this may be a possible workaround, but, in general, a blocked port in the local network should NOT cause a crash of a browser... So a fix in the build is needed.

The bug is CONFIRMED - so noone disagrees. But there is little point in appending variants of the backtrace.

(In reply to Stephan Kulow from comment #37)
> The bug is CONFIRMED - so noone disagrees. But there is little point in
> appending variants of the backtrace.

you're right, sorry

You guys can also disable it in flags if I am not mistaken:

chrome://flags/#load-media-router-component-extension

But in general I see where it crashes but not why nor is there any commit from google addressing this in newer releases :(

If I'm not wrong, someone told it is a problem in opensuse build only... Right?

Concerning the flags until the build is fixed: I see instructions how to ENABLE the media-browser extension in https://peter.sh/experiments/chromium-command-line-switches/, but how can I DISABLE it upon launch? A short hint where to edit the user config in ~/.config/chromium/ would be nice ...

Hi,
with the current chromium release Version 86.0.4240.111 (openSUSE Build) (64-bit) the problem is solved. 
Did you Tomas apply a solution? If so can you share it?
thank you

confirming https://bugzilla.opensuse.org/show_bug.cgi?id=1160068#c42 from Ferdinando, the current RPM 86.0.4240.111 which was just updated today seems to fix the issue. Status resolved >> fixed