I'm currently working to maintain an existing PNaCl application for ChromeOS devices. Prior to Chrome 72, we were able to log to stdout and stderr and these logs would appear on the ChromeOS device inside the ui.LATEST file. Since our ChromeOS devices have upgraded to versions past Chrome 71 our logs do not appear any more. We've tried this on devices running both Intel and ARM chipsets with the same results. We are using Pepper 49 (the latest). Our development environments in Ubuntu are still outputting to the stdout and stderr.
Has there been a change in Chrome 72 to where stdout and stderr log to or how we log to the ui.LATEST file?
EDIT: We've tried a couple of other sites that we know log to the stdout and use PNaCl, namely this: https://gonativeclient.appspot.com/demo - this also does not log to the Chromebooks but does log in our development environments.
Related
When I want to inspect a page listed on chrome://inspect page on a remote Pixel 4 with OS version 11, I get a white page with just 'HTTP/1.1 404 Not Found' shown.
I uninstalled all updates from Android Chrome, went down to version 83, and remote debugging started working again.
I have the same problem with current versions of Chrome beta/dev/canary.
Is this only a problem on my device, or a general problem? Any way to get remote debugging working with Chrome 89?
Thanks,
Michael
It seems you can't get it working on Chrome 89 for now because this is a general problem. I got the same issue on Vivaldi 3.7 which runs Chromium 89. The only option for now is rolling back to previous working release.
We have a .NET program to run headless Chrome to snapshot web page to image, and here is the sample code:
class Program
{
static void Main(string[] args)
{
var p = Process.Start(
#"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe",
$#"--headless --screenshot=E:\test{DateTime.Now:HHmmss}.png --disable-gpu --window-size=320,568 http://www.microsoft.com");
p.WaitForExit();
}
}
The console application is scheduled in Windows Task Scheduler with "Run whether user is logged on or not" option. The program works fine for months but failed yesterday, we noticed the Chrome version is 73 now. Luckily we found a computer in which Chrome is still 72, so we tested the background scheduled task once, upgraded Chrome to 73 and tested it again, finally got the conclusion - Headless Chrome 72 can run in background, but Chrome 73 can't.
Does anybody find the same issue on Chrome 73?
[updated on 2019/6/23]
It's a bug of Chromium (bug 942023) and has been fixed on Chrome 74.0.3729.108.
For Chrome 73, you can use --disable-features=VizDisplayCompositor argument as a workaround.
Yes, we have the same issue here. We're running Chrome through Selenium WebDriver and after the update to Chrome 73 our background tasks no longer function correctly. Downgrading to Chrome 72 fixes the problem.
Our diagnostics logs show that when running Chrome 73 in headless mode that certain calls to the Chrome process seem to hang. For instance, resizing the browser or trying to take a screenshot via the WebDriver API. We tried a number of things to fix this including updating Selenium, WebDriver and chromedriver to the latest versions but all had identical behaviours.
There certainly seems to be an issue with running Chrome 73 in headless mode after the update.
I'm struggling with Android emulator version 26.0.0.0. The tools are managed by the Android Studio (2.3.1). All this running on Fedora FC25 with latest updates.
I can't seem to get the ARM emulator to have network access. Same works fine with x86/x64, but not arm (or arm64).
It looks like I ran to the end of my abilities to debug what's going on, and on where to continue digging.
On arm : no ability to resolve names, no ability to connect to the outside network. I'm running nc from adb shell to check the connectivity. On an arm emulator, I get timeout on host lookup when using host name, and no route to host when attempting to connect by IP. Browser application also can't connect. I run strace on the emulator and I don't even see attempts to connect to the DNS server.
On x86 : everything works. However I did have to add -dns-server option before it started working.
Debugging The most I did was running strace for both the emulators and examining the difference. AFAIU, there is an I/O thread that gets to make the requests, and it looks like it's not picking up the requests in arm case. Or the requests are not properly deposited. The thread seems to be OK otherwise, it iterates between polls and futex locks.
Of course, my whole point is to run ARM emulators (needed to debug certain ARM native code).
Debug outputs (I did remove multi-touch connection errors from the output):
arm
x86
Any pointers on where to dig, or what I may be doing wrong is greatly appreciated. I can post full trace files from running both as well.
update your Android emulator to v26.1.0, it will work fine.
I have set up the board according to the RX cpu example in eclipse, and everything seemed to be working fine till I wanted to get the example running on the board. When I click the option to hardware debug, I get an error saying "Error launching GDB server. Check installation".
Am I to re install eclipse, or the GCC toolchain for the RX cpu, or anything else?
I don't know anything about your specifics (that is Renesas or the RX62N). I do use eclipse for embedded work. Typically on a new platform I would make sure I can build and download a release version first. Once you have that working then see if you can get a Debug build and the debugger running. On the platforms I am used to, you have to put in hooks (typically just a single call) to enable the debugger. For exmple on the NetBurner the debugger can run over the serial port or Ethernet so the call has to specify which version you want to use. I know other platforms use JTAG debuggers etc, Typically a dev kit for the board comes with a manual that details how to get the debugger working. I doubt that you need to reinstall anything you just need to get the configuration set up correctly.
I tried to run the directx samples from ..\Windows Mobile 6 SDK\Samples\PocketPC\CPP\win32\directx\d3dm\tutorials on a Samsung Omnia and on the emulator and it doesn't work because of a deployment error.
I am using Microsoft Visual Studio 2008 and have installed Windows Mobile SDK Standard and Professional refresh.
The device is correctly plugged in and set up for active sync (I know this because other samples work, also a creating Win32 smart device application and running it works).
When I try to run a directx sample application it compiles without errors but the message:
" There were deployment errors, Continue? Yes/No" appears
If I manually copy the application from the debug folder to the device and run it from there, it works.
The same deployment error message appears if I try it on an emulator. Other applications are deploying successfully.
Is there any way to make the deployment work? Maybe there is an obscure option I need to set...
What I do is:
Connect the Mobile device to the PC,
Open Visual Studio 2008,
Open a directx sample project,
Click Run (in Debug or Release mode).
The problem with the deployment is that the file msvcr80.dll could not be found.
It was specified at the deployment options as an additional file "Project->Properties->Configuration Properties->Deployment" then "General->Additional files"
with the paths msvcr80.dll|$(BINDIR)\$(INSTRUCTIONSET)\|%CSIDL_WINDOWS%|0;
Removing it makes the deployment successful. I have only tested this on a Windows Mobile 6.1 device and with the D3DM reference driver on an WM6.1/WM6 emulator.
What I haven't figured out is where does $(BINDIR)\$(INSTRUCTIONSET) point to.
Also I don't know why msvcr80.dll is in the addition files if it is not actually needed.
Is there actually a msvcr80.dll compiled for Windows Mobile platform on an ARM cpu?
I was able to resolve this issue after doing some low-level Sysinternals Debugging. It was trying to deploy NETCFv35.Messages.EN.cab to the device and in my case it was deleted for some reason. Re-installing .NET CF fixed the issue for me. Wish VS 2008 said what file was missing instead of a generic message. Hope this helps you too.