Skip to content

chromium from terminal sometimes hangs #3304

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
agizis opened this issue Oct 28, 2019 · 5 comments
Open

chromium from terminal sometimes hangs #3304

agizis opened this issue Oct 28, 2019 · 5 comments

Comments

@agizis
Copy link

agizis commented Oct 28, 2019

Is this the right place for my bug report?
Eben Upton told me to create it here, even though it’s “not really the appropriate repo, but it will do”

Describe the bug
Bad things happen using /usr/bin/xdg-open to open urls in Chromium. Sometimes it works fine, sometimes Chromium freezes up, sometimes the whole desktop environment freezes up tens of seconds. Once I had to pull the plug because after minutes it didn’t come back.

To reproduce
Open a terminal and run this command several times:
/usr/bin/xdg-open "https://support.speedify.com/"

Expected behaviour
If the browser’s not running, it should start on the URL, if it’s not it should quickly open another tab to that URL.

Actual behaviour
Most times it works, but sometimes, it takes a very long time and the browser or even the whole desktop freeze up while it’s waiting.

Here I ran it a couple times. See the large “ERROR:browser_process_sub_thread.cc(217)] Waited 678 ms for network service” type messages. Ive seen them go above 3000 and that’s when things get really hung up (for much longer than the 3 seconds you’d think from the message)

And sometimes when it has to launch chromium, it does, but the command never returns at all. I added some <> inline:

pi@raspberrypi:~ $ /usr/bin/xdg-open "https://support.speedify.com/"
 --disable-quic --enable-tcp-fast-open --ppapi-flash-path=/usr/lib/chromium-browser/libpepflashplayer.so --ppapi-flash-args=enable_stagevideo_auto=0 --ppapi-flash-version=
Opening in existing browser session.
[10190:10217:1028/110147.338737:ERROR:browser_process_sub_thread.cc(217)] Waited 678 ms for network service
pi@raspberrypi:~ $ /usr/bin/xdg-open "https://support.speedify.com/"
 --disable-quic --enable-tcp-fast-open --ppapi-flash-path=/usr/lib/chromium-browser/libpepflashplayer.so --ppapi-flash-args=enable_stagevideo_auto=0 --ppapi-flash-version=
Opening in existing browser session.
[10400:10427:1028/110209.251330:ERROR:browser_process_sub_thread.cc(217)] Waited 1020 ms for network service
pi@raspberrypi:~ $ /usr/bin/xdg-open "https://support.speedify.com/"
 --disable-quic --enable-tcp-fast-open --ppapi-flash-path=/usr/lib/chromium-browser/libpepflashplayer.so --ppapi-flash-args=enable_stagevideo_auto=0 --ppapi-flash-version=
Opening in existing browser session.
[10608:10635:1028/110220.586378:ERROR:browser_process_sub_thread.cc(217)] Waited 1324 ms for network service
<< COMMENT ADDED AFTER:  CHROMIUM CRASHES HERE >>
pi@raspberrypi:~ $ /usr/bin/xdg-open "https://support.speedify.com/"
 --disable-quic --enable-tcp-fast-open --ppapi-flash-path=/usr/lib/chromium-browser/libpepflashplayer.so --ppapi-flash-args=enable_stagevideo_auto=0 --ppapi-flash-version=
[10817:10962:1028/110252.280961:ERROR:object_proxy.cc(619)] Failed to call method: org.freedesktop.Notifications.GetCapabilities: object_path= /org/freedesktop/Notifications: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.Notifications was not provided by any .service files
[10866:10866:1028/110254.269346:ERROR:gl_surface_presentation_helper.cc(244)] GetVSyncParametersIfAvailable() failed for 1 times!
[10866:10866:1028/110254.277883:ERROR:gl_surface_presentation_helper.cc(244)] GetVSyncParametersIfAvailable() failed for 2 times!
^C[10817:10845:1028/110323.523693:ERROR:browser_process_sub_thread.cc(217)] Waited 15 this ms for network service
<< COMMENT ADDED AFTER: CHROMIUM LAUNCHED AND SHOWED URL, BUT  THIS COMMAND NEVER RETURNED.  WHEN I FINALLY HIT CTRL-C CHROMIUM WENT AWAY>>

System
Copy and paste the results of the raspinfo command in to this section. Alternatively, copy and paste a pastebin link, or add answers to the following questions:

  • Which model of Raspberry Pi? e.g. Pi3B+, PiZeroW
    4B

  • Which OS and version (cat /etc/rpi-issue)?
    Raspberry Pi reference 2019-09-26
    Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, 80d486687ea77d31fc3fc13cf3a2f8b464e129be, stage5

  • Which firmware version (vcgencmd version)?
    Sep 24 2019 17:34:30
    Copyright (c) 2012 Broadcom
    version cd3add54955f8fa065b414d8fc07c525e7ddffc8 (clean) (release) (start)

  • Which kernel version (uname -a)?
    Linux raspberrypi 4.19.75-v7l+ solved issue of mirroring screen after rotation. #1270 SMP Tue Sep 24 18:51:41 BST 2019 armv7l GNU/Linux

Logs
If applicable, add the relevant output from dmesg or similar.

Additional context
Add any other relevant context for the problem.

@XECDesign
Copy link
Contributor

The behaviour is the same if you use chromium-browser directly rather than through xdg-open, right?

Looking at xdg-open's documentation, I don't see it saying that it should launch the appropriate application and quit. Under some Desktop Environments, it will call an appropriate launcher that does this. But when running under LXDE, it falls through to "open_generic", which ends up just running the command within the shell script, so it won't return until the application it's calling exits.

If it's opening a local file, it will use pcmanfm, so you'll see different behaviour.

The rest might be one for John, although it's also likely to be just an upstream chromium issue.

@agizis
Copy link
Author

agizis commented Oct 29, 2019

Yes, you're right, it's exactly the same if I just call chromium-browser from the terminal. Nothing to do with xdg-open at all, sorry.

@agizis agizis changed the title xdg-open to chromium problems chromium from terminal sometimes hangs Oct 29, 2019
@agizis
Copy link
Author

agizis commented Oct 29, 2019

renamed ticket to not blame xdg-open.

@XECDesign
Copy link
Contributor

It's a bit hard to check whether it's related to our patches to chromium or if that's just how that particular version of chromium behaves. I'd need to build a stock version to compare against, which is a bit involved.

@BobDenny
Copy link

BobDenny commented Jan 14, 2020

Does this add any info to it? From an unprivileged (user pi) shell on the desktop. RPI 4B Buster with latest update/upgrade as of 12-Jan. The browser does open!! The gl_surface_presentation_helper.cc errors will repeat at intervals counting up as long as the browser is open.

pi@raspberrypi:/usr/lib/chromium-browser $ ./chromium-browser
[897:1124:0114/160721.272771:ERROR:object_proxy.cc(632)] Failed to call method: org.freedesktop.DBus.Properties.Get: object_path= /org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.UPower was not provided by any .service files
[897:1124:0114/160721.273772:ERROR:object_proxy.cc(632)] Failed to call method: org.freedesktop.UPower.GetDisplayDevice: object_path= /org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.UPower was not provided by any .service files
[897:1124:0114/160721.274390:ERROR:object_proxy.cc(632)] Failed to call method: org.freedesktop.UPower.EnumerateDevices: object_path= /org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.UPower was not provided by any .service files
[926:926:0114/160721.636098:ERROR:gl_surface_presentation_helper.cc(259)] GetVSyncParametersIfAvailable() failed for 1 times!
[1025:1:0114/160722.903096:ERROR:child_process_sandbox_support_impl_linux.cc(81)] FontService unique font name matching request did not receive a response.
[1025:1:0114/160722.908336:ERROR:child_process_sandbox_support_impl_linux.cc(81)] FontService unique font name matching request did not receive a response.
[897:1164:0114/160730.262201:ERROR:shared_change_processor.cc(196)] Passwords datatype error was encountered: Change processor disconnected.

I know this is really sleazy but by running a subshell with its stdout and stderr redirected, I was able to accomplish the desired result (opening a browser to get an OAuth PIN for input to a ReadLine in the terminal window.) C#/.NET Core

ProcessStartInfo pi = new ProcessStartInfo("bash", $"xdg-open {url}");
pi.RedirectStandardError = true;             // Hide the **** from the parent terminal
pi.RedirectStandardOutput = true;
Process.Start(pi);

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants