Forum Discussion

chicks's avatar
chicks
Regular Contributor
8 years ago

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 !

 

 

 

 

 

 

19 Replies

Sort By
  • chicks's avatar
    chicks
    Regular Contributor
    8 years ago

    This was actually happening in 11.2 version of TestExecute. 

     

    I updated to 12.10.590 and it is continuing.

    • tristaanogre's avatar
      tristaanogre
      Esteemed Contributor
      8 years ago

      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's avatar
        chicks
        Regular Contributor
        8 years ago

        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

  • chicks's avatar
    chicks
    Regular Contributor
    8 years ago

    I saw this again yesterday on my shiny new physical box with everything (memory, processor, etc.) maxed out.

     

    Within a period of an hour "all" scripts started failing, with the same error  a test complete log was not being produced.

    ERROR: 'TestCompleteLogs\index.htm' doesn't match anything: 'TestCompleteLogs' exists but not 'TestCompleteLogs\index.htm'

    .  I investigated and determined that not all scripts were failing, but just the scripts attempting to access the QA.xlsx file.

    However,  at the same time these scripts were failing on one box,  they were working on another box.  (using subversion to update the xlsx file before running the test) with the same QA.xlsx file

     

    After some tinkering with the excel file,  the scripts magically started working when run against the QA.xlsx excel sheet.

     

    My theory at this point is that due to some combination of the box environment and the excel spread sheet  the DDT Ace driver is hitting some kind of error which Test Execute does not handle properly (e.g. catching exception or whatever).  At that point,   TestExecute just gracelessly crashes.

     

    • AlexKaras's avatar
      AlexKaras
      Champion Level 3
      8 years ago

      Hi Curt,

       

      Have you reported this to Support (https://support.smartbear.com/message/?prod=TestComplete) referencing this thread?

      There is a chance that they will provide you with some internal build of TestExecute with additional debug logging enabled or something like this that will make it possible for you to provide them with crush dump\log for further investigation...

      • chicks's avatar
        chicks
        Regular Contributor
        8 years ago

        Thanks Alex.  I have been working on this with smartbear support for several months and we have not determined any helpful information.   However,  I will add this latest information and your suggestion and see whether they have anything.

         

        Regards,  Curt

  • osaid_ahmad's avatar
    osaid_ahmad
    Contributor
    8 years ago

    Hi,

     

    I am not sure if it make sense to you but i had the same problem with TE and even with TC. Try clearing unnecessary logs, free up some memory, and most importantly reduce the no of tests that run in the suite.

     

    I also raised the tickets sent dumps but unfortunately the problem was not solved. Only thing that helped is reducing the number of tests that run in one go. 

     

    Regards

    Osaid

    • tristaanogre's avatar
      tristaanogre
      Esteemed Contributor
      8 years ago

      Question: Are you making sure that you call DDT.CloseDriver on your Excel driver before you create another instance? I know for CSV files there's a maximum number of connections that you can have open before DDT.CSVDriver starts returning errors about being unable to open another connection.

       

      If you're consistently having problems with opening a LOT of Excel connections, that would be where I'd start checking... basically, a rule of thumb is that, for every DDT.ExcelDriver call, you should have a corresponding DDT.CloseDriver call to close the Driver object when you're done using it.  Something like:

      function MyTestCase() {
    var xcelDriver;
    xcelDriver = DDT.ExcelDriver('C:\\MyDocs\\MyXcel.xlsx', 'TestSheet', true);
    
    //do some stuff

    DDT.CloseDriver(xcelDriver.Name);
}
      • chicks's avatar
        chicks
        Regular Contributor
        8 years ago

        Hey Robert,

         

        I noticed with the latest set of crashes that it was  failing instantly.  The first thing my scripts do is use the DDT driver to fetch some global information.  Prior to that TestExecute would crash after proceeding to the actual separate tests.  I conclude from that that the DDT (ACE) driver did not like the combination of spreadsheet / environment.  

         

        Short Version:  It looks like it crashed on the initial opening of the ddt.exceldriver before I had any chances to close it or open more drivers....

         

        Regards, , Curt

    • chicks's avatar
      chicks
      Regular Contributor
      8 years ago

      Thanks Osaid.  One theory I had was that either my test suite or my spreadsheet had reached some kind of limit after 5 years.

      I just counted for the first time,   and I have about 91 tabs in my spreadsheet.   At one point when TestExecute was crashing I rolled back the spreadsheet 6 months to see if that made any difference and it did not.  

       

      With the latest set of crashes,  it was crashing instantly,  previously I could see that it would run for some period and then crash.