http://bugzilla.opensuse.org/show_bug.cgi?id=1160068 http://bugzilla.opensuse.org/show_bug.cgi?id=1160068#c1 Bryan Gartner <bryan.gartner@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bryan.gartner@suse.com --- Comment #1 from Bryan Gartner <bryan.gartner@suse.com> --- 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. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1160068 http://bugzilla.opensuse.org/show_bug.cgi?id=1160068#c3 --- Comment #3 from Michael Pujos <pujos.michael@gmail.com> --- The hint was "cast_channel" mentioned in the stack trace. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1160068 http://bugzilla.opensuse.org/show_bug.cgi?id=1160068#c5 --- Comment #5 from David Herman <mesamoo115@centurylink.net> --- 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 -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1160068 http://bugzilla.opensuse.org/show_bug.cgi?id=1160068#c6 Stephan Kulow <coolo@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |coolo@suse.com --- Comment #6 from Stephan Kulow <coolo@suse.com> --- as I can't unplug my chromecast as it's built into the a/v receiver - any chromium side workarounds? :( -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1160068 http://bugzilla.opensuse.org/show_bug.cgi?id=1160068#c8 --- Comment #8 from Stephan Kulow <coolo@suse.com> --- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833477 suggested -disable-features=EnableCastDiscovery - which does the trick. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1160068 http://bugzilla.opensuse.org/show_bug.cgi?id=1160068#c10 --- Comment #10 from Tomáš Chvátal <tchvatal@suse.com> --- (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. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1160068 http://bugzilla.opensuse.org/show_bug.cgi?id=1160068#c14 Bryan Gartner <bryan.gartner@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED |--- --- Comment #14 from Bryan Gartner <bryan.gartner@suse.com> --- 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) -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1160068 http://bugzilla.opensuse.org/show_bug.cgi?id=1160068#c21 --- Comment #21 from Gabor Horvath <oshikore@gmail.com> --- 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 -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1160068 http://bugzilla.opensuse.org/show_bug.cgi?id=1160068#c23 --- Comment #23 from jean-christophe baptiste <jc@phocean.net> --- Confirming the workaround of blocking TCP ports 8008 and 8009, which I did with firewalld instead. Not ideal though. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1160068 http://bugzilla.opensuse.org/show_bug.cgi?id=1160068#c25 --- Comment #25 from jean-christophe baptiste <jc@phocean.net> --- (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. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1160068 http://bugzilla.opensuse.org/show_bug.cgi?id=1160068#c27 --- Comment #27 from jean-christophe baptiste <jc@phocean.net> --- (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. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1160068 http://bugzilla.opensuse.org/show_bug.cgi?id=1160068#c29 --- Comment #29 from Dario Faggioli <dfaggioli@suse.com> --- (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. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1160068 http://bugzilla.opensuse.org/show_bug.cgi?id=1160068#c31 --- Comment #31 from jean-christophe baptiste <jc@phocean.net> --- Is it only me or the latest update fixed this? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1160068 http://bugzilla.opensuse.org/show_bug.cgi?id=1160068#c33 --- Comment #33 from Ferdinando Vivacqua <ferdinando.vivacqua@gmail.com> --- I confirm the 85.0.4183.102 release still has the problem -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1160068 http://bugzilla.opensuse.org/show_bug.cgi?id=1160068#c34 Thomas Rother <t.rother@netzwissen.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |t.rother@netzwissen.de --- Comment #34 from Thomas Rother <t.rother@netzwissen.de> --- 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. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1160068 http://bugzilla.opensuse.org/show_bug.cgi?id=1160068#c36 --- Comment #36 from Thomas Rother <t.rother@netzwissen.de> --- 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. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1160068 http://bugzilla.opensuse.org/show_bug.cgi?id=1160068#c38 --- Comment #38 from Thomas Rother <t.rother@netzwissen.de> --- (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 are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1160068 http://bugzilla.opensuse.org/show_bug.cgi?id=1160068#c40 --- Comment #40 from Ferdinando Vivacqua <ferdinando.vivacqua@gmail.com> --- If I'm not wrong, someone told it is a problem in opensuse build only... Right? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1160068 http://bugzilla.opensuse.org/show_bug.cgi?id=1160068#c42 --- Comment #42 from Ferdinando Vivacqua <ferdinando.vivacqua@gmail.com> --- 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 -- You are receiving this mail because: You are on the CC list for the bug.