Flaky coverage report - wrongly reported uncovered lines when PL/SQL profiler reports 0 for total_time #1125

As descirbed by oracle - the code coverage should only point on "total_occur". But this is - honestly - not true.

UtPlSqlv3 is pointing to total_occur and total_time is plsql_profiler_data - which is fine, but leads to wrong outputs im some cases.

e.g.

1. code is something like:
2. If (a='####Ä
3. and B=89735983475
4. and c= '9i38u4509834')
5. then
   ...
6. end_if;

What we get:
line 3 & 4 are not "covered" because of limitation in plsql_profiler and engine swapping
This means - in raw data you'll see in plslq_profiler_data the following

line 3: 0 0 0 0 (total_occur, total_time, min_time_max_time)
line 4: 0 0 0 0
....

everything is 0 - looks like - the code was never hit. But that's not true - the code was hit - we all know it must be hit.

If i run the same code 100 times - i have ~50% a "hit" - sometimes the reports show total_time > 0 and total_occur always = 0.
So - the reporter marks row 3 & 4 sometimes yellow, sometimes red.

I took a peak into the code and checked the rows in dbmspcc_blocks, too.
And here you'll have at least one hit - one block is hit.

I suggest to check this table, too.

I modified the package: UT_COVERAGE_HELPER_PROFILER (line 56-->)
at:
function proftab_results(a_object_owner varchar2, a_object_name varchar2, a_coverage_id integer) return t_proftab_rows is
l_coverage_rows t_proftab_rows;
begin
select
d.line#,
case when sum(d.total_occur) = 0 and (sum(d.total_time) >0 or sum(bb.covered) > 0) then 1
else sum(d.total_occur)
end total_occur
bulk collect into l_coverage_rows
from plsql_profiler_units u
join plsql_profiler_data d
on u.runid = d.runid
and u.unit_number = d.unit_number
left join dbmspcc_units bu
on bu.name = u.unit_name and bu.run_id = u.runid
left join dbmspcc_blocks bb
on bu.run_id = bb.run_id and d.line# = bb.line and bb.covered = 1 and bu.object_id = bb.object_id
where u.runid = a_coverage_id
and u.unit_owner = a_object_owner
and u.unit_name = a_object_name
and u.unit_type in ('PACKAGE BODY', 'TYPE BODY', 'PROCEDURE', 'FUNCTION', 'TRIGGER')
group by d.line#;

return l_coverage_rows;

end;

Please verify my assumtion - but this seems to take care about these kind of "hits", too.