Let me see if there is sone timeout setting that could cause this behavior.

Few questions that coukd help give answer.
If you run the same command but with ut_documentation_reporter, how long does it take to complete?
When running with -p commznd, what do you provide as an argument?

-p=schemaname.PACKAGENAME
Works ok as I said, runs in 3 hrs and generates a 770Mb output file.

I will run your suggested command there now and report back ut_documentation_reporter

ut_documentation_reporter runs in about 30 minutes (I should have known this as we use this in a jenkins pipeline)

@jgebal Any ideas?

This is actually a bug in utPLSQL.

utPLSQL reporters use output-buffer mechanism (table)
For each invoked reporter, the buffer gets populated with data as the main utPLSQL test execution session executed the tests.

When starting a utPLSQl-cli run, the cli starts several sessions for reporters (I think it is one for each reporter + 1 for the main utPLSQL run session).
Each of the reporter sessions is waiting for data to arrive in the buffer table and when it arrives it is instantly consumed (read and deleted) by the reported and data is provided from reporter to an output file.

To prevent situations where a DB may have uncountable amounts of ghost sessions in situations where main session dies or something goes terribly wrong and no data is sent to the reporters, the report consumer session has a timeout of 4 hours.

That timeout is reset each time the reporter session receives some data from the main session.

The problem is, that for coverage, no data is produced until after the test run is finished and coverage data is collected and processed.

I think we need to rewrite the mechanism of synchronization between sessions to be time-independent.

@varianjv - sorry for coming back to this so late.