Euphoria Ticket #957: Unable to open coverage database!

sample from latest eutest output not using -verbose

bunch of test output 
 
t_eutest summary: 
  5 tests run, 5 passed, 0 failed, 100% success 
error opening ..\tests\test.edb 
Unable to open coverage database! 
translating t_eutest.e: 
 
bunch more tests.  
 
interpreting t_include_subdir.e: 
error opening ..\tests\test.edb 
Unable to open coverage database! 
translating t_include_subdir.e: 
 
bunch more tests without problems 
 
happens every so often for as long as I have been running tests, doesn't happen on the same tests or every time. should there be a more aggressive access to database test?

why is eutest not retrying the database access? why is eutest continuing? isn't that going to cause false results? missing coverage? seems wrong any way you look at it.

the test report is generated but I am not seeing any coverage just zeros. does eutest just give up and ignore writing to coverage after an error?

I don't recall anyone else mentioning a similar problem, but I've seen it many time going back years.

could it just be my under-powered system? some kind of concurrent access problem? many other things going on at the same time without problems.

Details

Type: Bug Report Severity: Normal Category: Unit Tests
Assigned To: unknown Status: New Reported Release: 4.0 dev
Fixed in SVN #: View VCS: none Milestone: 4.1.0

1. Comment by jimcbrown Mar 08, 2016

Coverage is an optional feature and the inability to run it is harmless and should not affect the outcome of the test (except, of course, when you are testing coverage itself!), the concept was just to see how much of the code was covered during a run.

It's odd that coverage would be failing intermittently that way, however. I hadn't seen that happen before. This is on an 98SE machine still?

2. Comment by ne1uno Mar 08, 2016

Xp single core.

all euphoria and build directories and gcc are on a fast internal hardrive now, before a week ago, I was running gcc from an external USB drive, which was slower but had no real impact on the test or the data base error. I also ran browsers and portable programs from external drives w/o problems.

I do get the eutest html test report ok, and this:

Test results summary: 
    FAIL: t_abadcase.e 
    FAIL: translated t_abadcase-translated.exe 
    FAIL: t_bundled.e 
    FAIL: t_callc.e 
    FAIL: translated t_callc-translated.exe 
    FAIL: t_declasgn_wrning.e 
    FAIL: t_warning.e 
    FAIL: t_c_overflow_sbni.e 
    FAIL: t_c_overflow_sci1.e 
    FAIL: t_c_overflow_sci2.e 
    FAIL: t_c_overflow_sci3.e 
    FAIL: t_c_overflow_sci4.e 
    FAIL: t_c_overflow_sdnf.e 
    FAIL: t_c_overflow_sdni.e 
    FAIL: t_c_overflow_shni.e 
    FAIL: t_c_overflow_soni.e 
    FAIL: t_c_underflow_sci.e 
    FAIL: t_c_underflow_sdn.e 
Files (run: 277) (failed: 18) (94% success) 
the coverage tests have just finished now: some 5 hours after starting the tests.. though, they are on a low priority, so not really a problem but could be a cause.

notice there isn't any failure for those two tests it couldn't save the results for! t_include_subdir.e and t_eutest aren't listed in the report at all.

it's both the coverage and the test edb that errors at the same test output. there is already pretty high coverage, though nowhere near 100 percent except on a few files. what remains are some really difficult to reproduce test cases and of course, any new code in the stdlib could fall through the cracks.

not sure how much coverage work has been done on the eu interpreter or translator. I think the gcc coverage option Matt put into makefile only works on linux.

3. Comment by ne1uno Mar 08, 2016

I think one problem is, eutest is switching to tests/eutest and tests/include_subdirs which is why it isn't finding the test.db and coverage.db? eutest should maybe also switch the path to the databse or wait till it returns to tests,

I spoke too soon, the eutest html output was truncated.

</tr>unittest.log could not parse: 
"{\r\n  \"failed\",\r\n  \"Can call and things are passed correctly for ten argument functions\",\r\n  1.12589993095027e+015,\r\n  1.#INF,\r\n  0.0309999999999988\r\n}\r\n" 
this may or may not be related to the database error. maybe the error output caused a silent error in the report generator?

the coverage problem I am seeing could also be something I am not setting up properly in eutest run from a bat file. though everything worked fine till sometime last early year. just getting around to nailing down why.

msys can't run the tests because of all the windows path names in the makefile and assumptions in the tests. I am now working on a slimmed down tests dir so the test run doesn't take so long. nothing has changed that much in eutest or coverage options.

4. Comment by SDPringle Mar 09, 2016

The problem is that malformed number '1.#INF'. Eutest generates this in the log and when it makes the html it dies.

Search



Quick Links

User menu

Not signed in.

Misc Menu