van-smith / OPBM

Open Productivity Benchmark
1 stars 0 forks source link

Google Chrome does not launch / does not uninstall #2

Closed van-smith closed 12 years ago

van-smith commented 13 years ago

Immediately after Google Chrome is installed, OPBM tries to launch Chrome, but it never appears.

We waited many minutes, but the script did not time out.

This occurred on the Llano system which had a freshly installed environment.

It also uses 64-bit Java.

ghost commented 13 years ago

Van,

I believe any new-install-related issues will be fixed by the full implementation of the registry key modification that should be completed by the end of next week.

-----Original Message----- From: van-smith [mailto:reply@reply.github.com] Sent: Thursday, August 18, 2011 5:56 PM To: rick@canalabs.com Subject: [OPBM] Google Chrome does not launch (#2)

Immediately after Google Chrome is installed, OPBM tries to launch Chrome, but it never appears.

We waited many minutes, but the script did not time out.

This occurred on the Llano system which had a freshly installed environment.

It also uses 64-bit Java.

Reply to this email directly or view it on GitHub: https://github.com/van-smith/OPBM/issues/2

van-smith commented 13 years ago

Chrome launched properly manually.

The script reran without issue.

van-smith commented 13 years ago

accidentally hit the close button

van-smith commented 13 years ago

Intel Atom SUT stalled while launching Chrome. Attempt to manually launch Chrome before aborting the benchmark failed with no visual feedback. After halting the benchmark, Chrome launched normally.

ghost commented 13 years ago

This seems to be an issue with Google Chrome. We could modify the code to look for any Google Chrome running processes and terminate them before trying to re-launch it, or add some kind of auto-retry logic to the script to do the same before reporting a failure since Chrome is not always launching for whatever reason.

-----Original Message----- From: van-smith [mailto:reply@reply.github.com] Sent: Friday, August 19, 2011 7:13 AM To: rick@canalabs.com Subject: Re: [OPBM] Google Chrome does not launch (#2)

Intel Atom SUT stalled while launching Chrome. Attempt to manually launch Chrome before aborting the benchmark failed with no visual feedback.

Reply to this email directly or view it on GitHub: https://github.com/van-smith/OPBM/issues/2#issuecomment-1850402

van-smith commented 13 years ago

Why wouldn't Chrome launch manually while the scripts were running, but would launch once the scripts were aborted?

Also, there apparently is no timeout on this operation. OPBM sat for many minutes waiting from Chrome before I finally aborted testing.

ghost commented 13 years ago

Without the ability to reproduce the problem here, these options leap to mind as the only differences:

Possibly because the script is passing a command-line parameter (of our OPBM HTML splash screen). Or because the script is launching Google Chrome with internal privilege settings different than those handled by Windows itself from double-clicking the icon.

-----Original Message----- From: van-smith [mailto:reply@reply.github.com] Sent: Friday, August 19, 2011 7:26 AM To: rick@canalabs.com Subject: Re: [OPBM] Google Chrome does not launch (#2)

Why wouldn't Chrome launch manually while the scripts were running, but would launch once the scripts were aborted?

Also, there apparently is no timeout on this operation. OPBM sat for many minutes waiting from Chrome before I finally aborted testing.

Reply to this email directly or view it on GitHub: https://github.com/van-smith/OPBM/issues/2#issuecomment-1850490

ghost commented 13 years ago

Van,

I've done some checking online with Google searches and this appears to be a long known or oft-reported issue with Chrome. Some users suggest deleting the contents of the user folder fixes it. Others have reported deleting only "Sync Data" and that fixes it. It appears to be the result of a failed SQLite query in Chrome at startup.

On the machine that fails in Chrome, try deleting: C:\Users\username\AppData\Local\Google\Chrome\User Data

If that fixes it, we can add that logic to a SetChromeToKnownState() function at startup.

-----Original Message----- From: van-smith [mailto:reply@reply.github.com] Sent: Friday, August 19, 2011 7:26 AM To: rick@canalabs.com Subject: Re: [OPBM] Google Chrome does not launch (#2)

Why wouldn't Chrome launch manually while the scripts were running, but would launch once the scripts were aborted?

Also, there apparently is no timeout on this operation. OPBM sat for many minutes waiting from Chrome before I finally aborted testing.

Reply to this email directly or view it on GitHub: https://github.com/van-smith/OPBM/issues/2#issuecomment-1850490

ghost commented 13 years ago

Van,

Or, as we are currently copying the contents of our "safe user data" settings into that directory at startup, figure out which part is causing it to fail (if it is), and then replace that.

Is there a way I can remote into that machine from here? If not, can you Ghost the HD image and FedEx it to me?

-----Original Message----- From: van-smith [mailto:reply@reply.github.com] Sent: Friday, August 19, 2011 7:38 AM To: rick@canalabs.com Subject: Re: [OPBM] Google Chrome does not launch (#2)

Van,

I've done some checking online with Google searches and this appears to be a long known or oft-reported issue with Chrome. Some users suggest deleting the contents of the user folder fixes it. Others have reported deleting only "Sync Data" and that fixes it. It appears to be the result of a failed SQLite query in Chrome at startup.

On the machine that fails in Chrome, try deleting: C:\Users\username\AppData\Local\Google\Chrome\User Data

If that fixes it, we can add that logic to a SetChromeToKnownState() function at startup.

-----Original Message----- From: van-smith [mailto:reply@reply.github.com] Sent: Friday, August 19, 2011 7:26 AM To: rick@canalabs.com Subject: Re: [OPBM] Google Chrome does not launch (#2)

Why wouldn't Chrome launch manually while the scripts were running, but would launch once the scripts were aborted?

Also, there apparently is no timeout on this operation. OPBM sat for many minutes waiting from Chrome before I finally aborted testing.

Reply to this email directly or view it on GitHub: https://github.com/van-smith/OPBM/issues/2#issuecomment-1850490

ghost commented 13 years ago

It would continue to fail while the script was running if some condition of its launch caused the process to hang. The second attempted instance would see there is already a first instance running, and abort, or send it a message to say "Hey, the user clicked on the icon again, add a new tab" or however Chrome behaves when attempting to launch multiple instances.

The scripts automatically terminate previously non-existent processes that weren't running before the script began. So any "hung" chrome.exe instances would be force-closed upon termination, allowing the Chrome icon to be clicked afterward to have it launch without issue.

That's my best guess.

van-smith commented 13 years ago

In both failure instances, the issue does not reproduce on rerun. This might be the result of manually opening Chrome successfully after the failure.

van-smith commented 13 years ago

Proposed fix: The script would halt indefinitely waiting for Chrome to launch. A timeout should be added here so that the script can rerun 5x. Be sure to close/kill Chrome in between attempts. This approach will probably fix this problem because opening and closing Chrome manually before rerunning the script appeared to fix the problem here.

ghost commented 13 years ago

This proposed fix was implemented yesterday for today's testing.

van-smith commented 13 years ago

This fix apparently works because we have not seen the failure here today.

ghost commented 13 years ago

This fix has not been applied.

ghost commented 13 years ago

Pushed code for a potential fix. It looks for chrome.exe processes before, during and after normal install / uninstall operations, and before and after normal browser operations. It will fall back to taskkill.exe /f if AutoIt is unable to close the process automatically. KillProcessByName() in opbmCommon.au3, and support in the chrome common and named scripts.

van-smith commented 13 years ago

Using the latest build, the harness stalled while trying to uninstall Chrome. After several minutes, the Result Viewer appeared displaying unrelated results.

I ran the Chrome uninstall link under the Start Menu and Chrome was uninstalled without issue. Again, perhaps you should try to directly call this link.

ghost commented 13 years ago

It appears that Chrome is updating itself behind-the-scenes to a different version. The uninstall link on the default install is the path I'm using. It points to each user's version of: "C:\Users\rick\AppData\Local\Google\Chrome\Application\12.0.742.122\Installer\setup.exe --uninstall"

It appears Chrome is updating itself so the new uninstaller is: "C:\Users\rick\AppData\Local\Google\Chrome\Application\13.0.782.220\Installer\setup.exe --uninstall"

That feature needs to be disabled. Researching.

ghost commented 13 years ago

Chrome was auto-updating silently in the background. This had not been an issue previously because there was nothing to update to. And this "feature" is a very common complaint on the Google Chrome forums.

I found a page with instructions on how to disable it (http://www.technixupdate.com/disable-automatic-update-google-chrome/). It involves setting a registry key. This fix has been applied to this release (https://github.com/van-smith/OPBM/commit/a6af78e118887283becc7dc24492b3e757867eaa).

If this does not work, other methods involve deleting or remaining the GoogleUpdate.exe utility in the equivalent of the C:\Users\rick\AppData\Local\Google\Update\ directory, or (with admin privileges) to remove the four task scheduler events Chrome inserts for its auto-update requests.

ghost commented 13 years ago

Observed update behavior after install despite using the registry key. It appears that the previous task scheduler and previous google update code must be removed completely and manually, otherwise previous installs will have the update schedulers hanging around out there.

Delete google files in c:\windows\tasks. Uninstall chrome manually if need be. Delete c:\users\username\AppData\Local\Google\Updater\ directory.

Am continuing to test.

ghost commented 13 years ago

Found a separate registry key setting here: http://dev.chromium.org/administrators/turning-off-auto-updates

Uses HKLM\SOFTWARE\Policies\Google\Update\AutoUpdateCheckPeriodMinutes set to REG_SZ "0".

van-smith commented 13 years ago

Why wouldn't launching this always work for uninstalls?

"C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Google Chrome\Uninstall Google Chrome.lnk"

And this for launching Chrome:

"C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Google Chrome\Google Chrome.lnk"

ghost commented 13 years ago

It's a non-standard way to run applications as the user can alter their start menu. But beyond that there is the more pressing, real issue of Chrome auto-updating itself and changing its path after an install. This needs to be addressed, because what's happening behind-the-scenes, as you know, is that Chrome is using CPU time and network bandwidth and memory resources during the course of an official run benchmark to update itself. This will happen at whatever time it happens, and will affect scores randomly during the run.

The links we have to the executables are valid and work, so long as Chrome doesn't update itself. Using the direct path is the same as what we're using for all of the Office apps, for example, rather than using "C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Microsoft Office\Microsoft Access 2010.lnk", etc.

van-smith commented 13 years ago

Rick, it is the expected way for the user to run the applications and the chance that this path will be changed by the user is small. If the links are not found, then we can fall back to your current methods.

Implement this as the default method for uninstalls as well as launches for Chrome. The autoupdate feature is trivial at the moment and can be addressed later.

Chrome has been causing failures for months and this might correct those problems. I made this suggestion weeks ago and we need to try it.

van-smith commented 13 years ago

Rick, has this shortcut fix for Chrome been implemented? If not, it needs to be first priority today. As I've mentioned before this bug has been top priority for weeks; it is a show stopper and cannot be around on the 9.19 deliverable date.

FYI, I have been aware for several weeks what is causing the issue, which is why I have been suggesting the shortcut solution to you. Google seems to always update the shortcuts properly, so they should always be safe to call, even when the root problem is later addressed.

ghost commented 13 years ago

Van, I'm asking the question below for one reason: to my knowledge the last fix I pushed out solved both problems (not un-installing, and a cessation of auto-updates). I believe the reason Chrome was not exiting previously was because it was running the auto-update code and that prevented it from being politely shutdown, and that the reason it was not uninstalling was because the auto-update changed the version which changed the path. This last fix I pushed out should have addressed both issues. So I ask the question regarding the last fix:

Are you seeing Chrome failures in the version you're testing right now?

van-smith commented 13 years ago

The Brazos system has not passed at all because of the Chrome failure and I have made several runs.

When did you do the push to fix this issue? The code I was using was from yesterday morning.

van-smith commented 13 years ago

And again, I have never had a problem uninstalling Chrome using the shortcut.

van-smith commented 13 years ago

I did another pull and will try with the new code.

ghost commented 13 years ago

It was in the 7:56am commit.

ghost commented 13 years ago

There may be residual auto-update features hanging around out there. Try this on any machine that failed:

Delete google files in c:\windows\tasks. Uninstall chrome manually if need be to get it initially uninstalled before re-running the harness. Delete c:\users\username\AppData\Local\Google\Updater\ directory.

van-smith commented 13 years ago

Chrome failure occurred again with the new code, this time during the installation step (the previous failure was during uninstall). I took the following actions:

I then tried to rerun an Official Run, but then encountered a different "Shut Down Windows" dialog than before. The HUD reported "FinalScript" after "Attempting to Launch 7-zip uninstaller..."

Also, the HUD remains partially obscured by the task bar and I had to reposition it to read the last message.

van-smith commented 13 years ago

The shutdown dialog appeared at least twice while the harness stalled at this location. It progressed to the Chrome uninstall and then presented the shutdown dialog again.

van-smith commented 13 years ago

I have waited at least seven minutes and the "Shut Down Windows" dialog is still up. The last HUD message is "Chrome is not installed."

ghost commented 13 years ago

Shutdown will occur within 30 seconds. If it doesn't occur by then, it was never scheduled or did not successfully run. Do you have the ability for me to see what's happening by a Mikogo session on that computer?

ghost commented 13 years ago

I'm attempting to update the Chrome launcher paths, but I do not have either of these shortcuts on my computer: "C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Google Chrome\Uninstall Google Chrome.lnk" "C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Google Chrome\Google Chrome.lnk"

My shortcuts were installed to my account under: "C:\Users\rick\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Google Chrome"

How do you want me to handle this?

van-smith commented 13 years ago

I'm terminating the test, after waiting about 30 minutes, by clicking the Stop button.

The "Shut Down Windows" dialog disappeared and then reappeared. HUD reports "Attempting to stop, please wait..."

This remained up for several minutes, so I rebooted the system, killing the harness.

ghost commented 13 years ago

If the shutdown dialog appears, OPBM has scheduled a reboot within one minute. If it doesn't reboot in that time, something went wrong. You should never have to wait more than about 6 minutes for anything in the scripts to complete (when it should be in a shutdown state, or exiting, or waiting for something, and not doing large amounts of work like the File I/O script), or more than about 15 seconds for anything in OPBM to complete.

van-smith commented 13 years ago

This is not the normal shutdown dialog that had been showing up previously. Additionally, it appeared and disappeared many times.

I am attempting another Official Run on that system.

van-smith commented 13 years ago

On this attempt, the normal shutdown dialog has appeared and the system is rebooting...

van-smith commented 13 years ago

Try in descending order:

1 -

C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Google Chrome\Uninstall Google Chrome.lnk" "C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Google Chrome\Google Chrome.lnk"

2 - "C:\Users\rick\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Google Chrome"

3 - Existing method

ghost commented 13 years ago

Descending order means 3, 2, 1? Or visually from top to bottom 1, 2, 3?

van-smith commented 13 years ago

Sorry, try 1, then fallback to 2 and then 3.

van-smith commented 13 years ago

After the two failures with the new OPBM files -- including the very bizarre behavior on the second attempt -- the third Official Run attempt appears to be executing properly on the Brazos system.

ghost commented 13 years ago

Sounds like there was something odd left in the system state after uninstalling the Google Chrome stuff and not rebooting. It shouldn't be an issue moving forward though. I'm testing the current version on my SUTs. I'll get the chrome URL change made soon.

van-smith commented 13 years ago

I agree, but we need to find a way to automatically avoid/overcome these issues involving stale installations.

ghost commented 13 years ago

We need a watchdog, an external process that's launched by OPBM at startup, and remains so long as it is running, which we send simple commands to monitor, and if anything goes haywire, to restart the harness, or notify the user and let them decide to wait, force-terminate, restart, etc.

How is the testing going? I am not having any issue on two SUTs, both 64-bit running JVM 1.7. The third SUT has a bad hard drive image today and needs re-installed. Note: This bad hard drive image is due to something that happened between the last time the system was shut down and this time when it was turned on, and is NOT due to an issue with the harness. LOL! :-)

van-smith commented 13 years ago

This bug still exists as discussed in bug #66. Will continue debugging in this issue.

van-smith commented 13 years ago

Attempted to run on a SUT (Llano) that did not have Chrome installed. The Official Run failed on the Chrome JavaScript tests. Debug file copied to Z.

Failures are occurring with both install and uninstall.

ghost commented 13 years ago

I am unable to replicate any of the Chrome failures on my dev machine or two SUTs.

The Chrome install process is as follows:

1) Launch/run Chrome installer 2) Wait for it to complete 3) Close auto-launched Chrome browser window 4) Copy default browser data files (from C:\cana\vs2010\opbm_dll\opbm\BrowserData\Chrome\, though they are embedded into the resource file and extracted from the opbm.dll at runtime--Note: these files were copied from a fresh install of Chrome after running it, bypassing any user dialog windows, going into settings and turning off features the user would turn off during a normal install and first run, then exiting).

The problem may be caused by the default browser data files, though I do not see anything of user-specific code in there (such as a "c:\users\rick..." directory).