TestExecute crashes with no log produced

[chicks]

Again,  I have submitted a ticket on this but hope somebody else may have encountered this issue or have some advice and suggestions

.

The problem is that TestExecute starts running my script and then crashes at some point without producing any log.

This was originally happening every 10 days or so, but is now happening consistently on two different machines but not a third machine.    When it started happening consistently I was able to capture an error report, and SmartBear indicated that it was a problem with DDT.closedriver   I used a different excel driver and saw that test execution proceeded further before Test Execute crashed.  At that point,  I converted most of my code to use the different excel driver.  However,  the problem is still occurring.     

I am running test execute 11.3 using windows 7.   This is failing on two different machines one running 32 bit Excel and one running 64 bit Excel

Miscellaneous data:

0) 1 of 4 scripts in this project is running with no issues.  With 2 of them, I'm seeing this problem.  The third is ending early.

1) reinstalling excel on box  1 did not make any difference

2) reverting the spreadsheet (with subversion) to a version that worked earlier did not make any difference

3) I am seeing the problem on at least two different boxes , but apparently not a third

4) I am seeing the problem against multiple test environments,  i.e.  both our QA test environment and our Stagjng test environment

Any advice or questions very gratefully appreciated !

[chicks]

This was actually happening in 11.2 version of TestExecute. 

I updated to 12.10.590 and it is continuing.

[tristaanogre]

One thing of note... TestComplete is still a 32-bit application. So, if you are attempting to access Excel on a machine that has the 64-bit version of Excel on it, that COULD be your problem, or at least part of it.  

I do agree that it sounds like your DDT.ExcelDriver, perhaps with the close driver method.  Are you verifying that the driver you are attempting to close is non-null? That's one "hiccup" I ran into in the past using DDT, especially if I'm creating the driver across script units and so on.. it's easy to lose track and attempt to use or close a driver that may already be closed. Check your script calls and make sure that each CloseDriver call actually corresponds properly to an open driver... I've actually encapsulated such a check in a little wrapper extension I created that checks for the non-null existance of a driver before attempting the close.  I've attached it in case you want to try it.

[chicks]

Hi Robert,   After I changed drivers the problem still occurs.  Does that not mean that it is not the DDT driver?  Although I suppose it could be the same problem with the other excel driver as well.    The problem occurs on both a 32 bit OS and a 64 bit OS.

Thanks,  Curt

[tristaanogre]

It could still be the DDT driver. It sounds like you are "stepping" on a memory location that should not be stepped on... attempting to close a DDT driver that has already been de-allocated for some reason could easily do that.

If you can throw together a quick sample of what you are running into, perhaps not your full project, and toss it over this way, I can see if I can help debug.

[chicks]

I'd appreciate it but it does not seem to be happening everywhere just on 2 of 3 platforms here and not with all scripts.  Smartbear support has been unable to duplicate the issue. Though I can't tell if they have looked at the windows crash file I've sent them.....

I like the corrupted memory location theory as it seems as if the problem "built up" originally happening only 1 in 10 days and now happening consistently with some scripts.  So more of a "leaky tire" problem, then a "tire fell off" problem. 

I have restarted / rebooted the box but that does not seem to affect the issue.

Let me try to throw together  a general outline of what I'm' doing to see if you have any comments on the driver handling..

[tristaanogre]

More than happy to help out. These are the annoying parts of test automation, no matter what the tool... So, always glad to lend a hand.

[AlexKaras]

Hi Curt,

You may also check if silent.log file exists and contains something relevant: https://support.smartbear.com/viewarticle/81120/, \SilentMode paragraph.

[chicks]

Thanks Alex.  I'll double check the silent log file and report back if it says anything.  As part of smartbear's debug process I tried to capture the report generation file, but when it crashed no file was produced,  so the same thing may be happening with silent log. 

[chicks]

Here's an update:

1) our IS department created a brand new virtual machine.  At that point the test execute crash seemed to vanish, and I could see the jobs run to completion  

2)  We did the same 177 windows updates on the old physical 32 bit machine.  

3)  However,  I started getting a JVM heap error when my Hudson job tried to copy over the test log.  

C:\Users\hicksc\.hudson\jobs\QA - Event Interface\workspace>exit 0 
Archiving artifacts
FATAL: Java heap space
java.lang.OutOfMemoryError: Java heap space

There are numerous google references to this error with Hudson or Jenkins.  However I am not using any of the Maven or Ant build options in Hudson. So,  I used the Java Control Panel to increase the runtime parameters

-Xmx2048m  and that seemed to help.  However,  on the original physical 32 bit machine,  I can not increase the JVM size to too much so I am seeing the heap error frequently on the longer jobs.   On the new 64 bit virtual machine after updating to 64 bit java and increasing the JVM heap size to 1 gig -Xmx10240m   I have not seen the JVM heap crash (yet).

For some reason I am now getting the JVM heap space crash on some test execute jobs.

The virtual server with twice the minimum requirements for test execute and improved everything over the old 32 bit physical machine  is taking significantly longer to run each test.    I am seeing CPU processor use bump to almost 98 % when it is running.  This may be a known issue with running Test Execute on virtual machines since they do not have video cards.  Our IS department suspects that  TE may be hitting the CPU to compensate for the missing video card.