search

van-smith / OPBM

Open Productivity Benchmark
1 stars 0 forks source link

Official Run immediately fails while trying to unstall 7zip during cleanup step #66

Closed van-smith closed 13 years ago

van-smith commented 13 years ago

Trial Run behaves identically.

I deleted the opbm output directory, but this did not fix the problem.

The atom to install 7zip works. Official Run will pass this step if 7zip is installed.

ghost commented 13 years ago

Click Gather Debug Info and put on Z: drive.

If same thing happens on trial run, #66 should be renamed "7zip uninstall failure".

van-smith commented 13 years ago

The failures are occurring during the initial cleanup. The 7zip uninstall atom seems to work fine.

ghost commented 13 years ago

I need to see the Gather Debug Info output from this failure. The one you submitted for #67 had an abnormal termination from clicking stop on the HUD.

Please try to get in the habit of collecting the Gather Debug Info xml file when failures occur. They're the only tool I have to debug problems on remote SUTs. If other things are run in-between the failure and the Gather Debug Info link being clicked, the data will be invalid and lost. It needs to be run immediately after the failure. You can ZIP up the debug info xml file as well, so it will save faster on the Z: drive. A debug info file could be over 1MB in size for an official run with even some successful atoms run.

van-smith commented 13 years ago

As I reported for #67, OPBM was stalled so my only option was to press Stop.

I attempted to run an Official Run on another system and the failure reproduced. I copied that file to Z.

ghost commented 13 years ago

You can press stop. You can even reboot. The only thing that will cause debug info to be lost is if you do another run, as the manifest.xml file is overwritten each time a new run (of any kind, trial, official, or single atoms, molecules, scenarios or suites) is initiated, or if you go in and modify settings, scripts, etc., before clicking the Gather Debug Info link. That link takes a snapshot of what's happening.

Maybe it should be set to automatically gather the debug info upon a failure. That way it doesn't rely upon the user to do it manually.

ghost commented 13 years ago

Fixed by reversion to prior 7-Zip installer and un-installer script.

van-smith commented 13 years ago

This problem still exists after a pull just a few minutes ago. The debug info is on Z.

The failure also reproduced after deleting all of the opbm temp files and directories.

ghost commented 13 years ago

Code was erroneously checking any stop condition (such as a failure when stop-on-failure is set to true), rather than just a user-clicked-stop condition.

ghost commented 13 years ago

Additional fix required. Still had regression 7zipcommon.au3 code, and needed to override the stop-if-failure condition with the user-clicked-stop condition when the user explicitly clicks stop.

van-smith commented 13 years ago
  1. Failure occurred after the pull. Restarter window was visible with "Install 7zip" visible. Debug file is on Z.
  2. Deleted temp files and reran. Harness tried to uninstall 7zip and then rebooted SUT. Failure appears to be identical to 1. Debug file is on Z.
ghost commented 13 years ago

The auto-reboot on 7-zip uninstaller is because it was set to passive mode, which makes assumptions based on choices/needs, and will auto-reboot if needed. A more recent push has corrected that condition and has the uninstaller working as before, with dialog boxes and navigation.

van-smith commented 13 years ago
  1. Deleted OPBM temp files and reran Official Run after a pull at 8:40PM. The GUI 7zip uninstaller was visible. Additionally, Adobe Reader uninstaller ran. However, the system is stalled at the Chrome uninstaller (Chrome is installed). The Chrome uninstaller eventually timed out and the system appears to be in a retry loop. I will let the system run for 10 more minutes to see if a failure will be trapped and the run aborted.
ghost commented 13 years ago

If Chrome is continuing to fail on uninstall, I do not know how to fix it. I have it calling the start programs lnk file, specifically terminating the task within and even spawning a Microsoft utility called taskkill.exe (designed to kill non-responsive tasks) if it is running in memory. Beyond that, I do not know what to do.

van-smith commented 13 years ago

Chrome was never uninstalled, but the harness went on to Opera. The Chrome link is still on the desktop.

The system has rebooted and is installing 7zip.

ghost commented 13 years ago

The system will not fail on failed attempts to execute "startup" scripts (scripts that are not part of the actual run, but are the ones run before the run begins), but will proceed onward to the regular run. It retries the specified number of times, and regardless of the stop-on-failure setting, even if it fails it will continue to the next startup script, and eventually to the real run scripts.

This ignore-failures condition is only true for the startup scripts (spinup, atomOnSpinup, atomBeforeRun) and cleanup scripts (atomAfterRun and atomOnFailure).

van-smith commented 13 years ago

The harness installed 7zip and Adobe Reader but failed on Chrome. The debug file is on Z.

I attempted to uninstall Chrome through the Uninstall link, but nothing occurred after clicking it. I also tried to uninstall Chrome through the Control Panel, but the behavior from the link reproduced.

Chrome also will not launch.

This is the first time this behavior has manifested; manual uninstall of Chrome might now not be possible without explicit file deletion and registry editing.

I will investigate more in about an hour.

van-smith commented 13 years ago

It appears that this bug is fixed, but I have now encountered bug #2. Will continue debugging in that issue.

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).