View Full Version : Hang-up Calling Child Scripts
snapjeff
03-16-2012, 04:33 PM
I am having an inconsistent hang-up issue calling a child script from a master script. The child script always finishes with no errors, but the master (calling) script sits and waits for completion. At this point, there are two instances of VisBuildPro.exe running, but only one with a UI (the calling script) with neither using any CPU. I am calling the child script in the "Match build context" mode. The master script is in the GUI mode.
I tried adding a wait of varying lengths at the end of the child scripts, but it did not solve the problem.
I am using Visual Build Pro 7.7a, on a build machine running Win XP w/SP3 and I am accessing it via Remote Desktop.
kinook
03-16-2012, 04:38 PM
http://www.kinook.com/Forum/showthread.php?t=3892
snapjeff
03-16-2012, 04:42 PM
Thanks for the quick reply. I'll give some of those a try.
Jeff
snapjeff
03-20-2012, 12:18 PM
I tried the following from that thread:
- I called the child scripts as a console app (made the problem worse)
- Added the /mta option (no change)
- Set the affinity to 1 (no change)
Since the problem was on a Win XP machine with 512 MB RAM, I tried the scripts on a Win 7 machine with 4GB RAM. The hang-up still occurred. However, I was able to get some additional information with Win 7 that is shown below.
Problem Event Name: APPCRASH
Application Name: VisBuildPro.exe
Application Version: 7.7.1.1
Application Timestamp: 4e0a3b95
Fault Module Name: ScriptSn.20110620173350.dll_unloaded
Fault Module Version: 0.0.0.0
Fault Module Timestamp: 4d2ce466
Exception Code: c0000005
Exception Offset: 69db5262
OS Version: 6.1.7600.2.0.0.256.48
Locale ID: 1033
Additional Information 1: 0a9e
Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
Additional Information 3: 0a9e
Additional Information 4: 0a9e372d3b4ad19135b953a78882e789
Since the Win 7 machine has 4GB of RAM, I doubt that is the problem. As mentioned in the first post, the child script does not hang at any particular step. It finishes completely, but never seems to exit.
kinook
03-20-2012, 06:18 PM
It doesn't sound like a hang, more like the build completes but the process doesn't go away for some reason (not something we've seen before). Did the problem just start occurring recently, and any ideas what might have changed when it started?
One possible workaround would be to configure the step that calls the child build to terminate after some amount of time (longer than what the build would normally take).
http://www.kinook.com/VisBuildPro/Manual/stepfailure.htm
Please send the .bld files, details on how they are launched (scheduled task, manual launch, etc.) and any other info from http://www.kinook.com/Forum/showthread.php?threadid=3044 that could help us reproduce the problem. Thanks.
snapjeff
03-21-2012, 01:04 PM
Nothing has really changed. I am in the process of developing the scripts and now that I started to do some heavier-duty testing, I have been seeing this issue.
I decided to start simplifying things and got down to a 'master' script that loops 20 times calling a dummy child script (the child script does only a 2 second wait). I have not had any success in completing 20 iterations of the loop yet. Those files are attached.
EDIT: The simplified test scripts work fine on the WinXP machine.
The About/Install Info:
Visual Build Professional 7.7a
Registered to: xxxxxxxxxxxxxxxxx (2-computer license)
Windows Version: 6.1.7600.0.0
Install path: C:\Program Files\VisBuildPro7
HideConsole.exe version 1.0.0.0
SftPrintPreview_IX86_U_20.dll version 2.03
VisBuildCmd.exe version 7.7.1.1
VisBuildPro.exe version 7.7.1.1
VisBuildAct.dll version 7.7.1.1
VisBuildCore.dll version 7.7.1.1
VisBuildDotNET.dll version 7.7.0.3
VisBuildExt.dll version 7.7.1.1
VisBuildMisc.dll version 7.7.1.1
VisBuildMS.dll version 7.7.1.1
VisBuildMS2.dll version 7.7.1.0
VisBuildNet.dll version 7.7.1.1
VisBuildSvr.dll version 7.7.1.1
VisBuildSvr.Interop.dll version 1.0.0.0
VisBuildVCS.dll version 7.7.1.1
kinook
03-21-2012, 05:10 PM
In our tests, the scripts always complete as expected (tested on Win XP SP3 and Win7 x64, via Remote Desktop).
snapjeff
03-22-2012, 04:02 PM
I started removing parameters passed to the child script (I continued to use the dummy child script that does only a 2 second Wait) and found that by not passing the global script file to the child script, the child script will always return.
Thinking that perhaps the parameter ordering was an issue, I put the /script switch in the additional options and it behaves the same as if I added the global script file 'normally'.
I have created my own global macros, scripts and subroutine steps files that are not stored in the configuration files path, but I am supplying the full path for these files in the options tab of the VisBuildPro action.
Any ideas?
Jeff
kinook
03-22-2012, 04:29 PM
Can you ZIP and send the global scripts file that you are using to support@kinook.com? Thanks.
snapjeff
03-22-2012, 05:44 PM
File sent.
kinook
03-22-2012, 05:56 PM
I put the scripts file in the same path as Test.bld, modified Test.bld as attached, built, and it completed as expected.
snapjeff
03-23-2012, 11:46 AM
Still no joy :(
I used your Test.bld (which is for VBP8, so I installed the eval of VBP8), I still have the child script not returning.
What I did do to get the child script to return was to reduce the global script file down to this:
<?xml version='1.0' encoding='utf-8'?>
<scripts version='7'>
<script language='VBScript'></script>
</scripts>
If I put anything between the <script language='VBScript'> and the </script>, the child script will not return. I even tried to save the script file as UTF-8 with no difference.
BTW...I am testing this on the actual build machine using WinXP.
Jeff
kinook
03-23-2012, 02:26 PM
That is an odd one. It worked fine on Win XP SP3 in our tests (also tried with a much larger scripts file). Is the build machine running on Windows installed on a physical hardware, or in a virtual machine, and if so, what kind? Is there any way you could provide us with a VM that reproduces the problem, or give us access to the problem machine?
vBulletin® v3.8.11, Copyright ©2000-2024, vBulletin Solutions Inc.