Forum Discussion
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.
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..
- tristaanogre8 years agoEsteemed Contributor
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.
- AlexKaras8 years agoChampion Level 3
Hi Curt,
You may also check if silent.log file exists and contains something relevant: https://support.smartbear.com/viewarticle/81120/, \SilentMode paragraph.
- chicks8 years agoRegular Contributor
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.
- chicks8 years agoRegular Contributor
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.
Related Content
- 12 years ago
- 8 years ago
- 10 months ago