TestExecute crashes with no log produced
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
TestExecute crashes with no log produced
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 !
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This was actually happening in 11.2 version of TestExecute.
I updated to 12.10.590 and it is continuing.
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Robert Martin
[Hall of Fame]
Please consider giving a Kudo if I write good stuff
----
Why automate? I do automated testing because there's only so much a human being can do and remain healthy. Sleep is a requirement. So, while people sleep, automation that I create does what I've described above in order to make sure that nothing gets past the final defense of the testing group.
I love good food, good books, good friends, and good fun.
Mysterious Gremlin Master
Vegas Thrill Rider
Extensions available
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Robert Martin
[Hall of Fame]
Please consider giving a Kudo if I write good stuff
----
Why automate? I do automated testing because there's only so much a human being can do and remain healthy. Sleep is a requirement. So, while people sleep, automation that I create does what I've described above in order to make sure that nothing gets past the final defense of the testing group.
I love good food, good books, good friends, and good fun.
Mysterious Gremlin Master
Vegas Thrill Rider
Extensions available
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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..
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Robert Martin
[Hall of Fame]
Please consider giving a Kudo if I write good stuff
----
Why automate? I do automated testing because there's only so much a human being can do and remain healthy. Sleep is a requirement. So, while people sleep, automation that I create does what I've described above in order to make sure that nothing gets past the final defense of the testing group.
I love good food, good books, good friends, and good fun.
Mysterious Gremlin Master
Vegas Thrill Rider
Extensions available
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Curt,
You may also check if silent.log file exists and contains something relevant: https://support.smartbear.com/viewarticle/81120/, \SilentMode paragraph.
/Alex [Community Champion]
____
[Community Champions] are not employed by SmartBear Software but
are just volunteers who have some experience with the tools by SmartBear Software
and a desire to help others. Posts made by [Community Champions]
may differ from the official policies of SmartBear Software and should be treated
as the own private opinion of their authors and under no circumstances as an
official answer from SmartBear Software.
The [Community Champion] signature is assigned on quarterly basis and is used with permission by SmartBear Software.
https://community.smartbear.com/t5/Community-Champions/About-the-Community-Champions-Program/gpm-p/252662
================================
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
