Re: Bogus reports from coverage.postgresql.org
От | Stephen Frost |
---|---|
Тема | Re: Bogus reports from coverage.postgresql.org |
Дата | |
Msg-id | 20180313170105.GC2416@tamriel.snowman.net обсуждение исходный текст |
Ответ на | Re: Bogus reports from coverage.postgresql.org (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Bogus reports from coverage.postgresql.org
Re: Bogus reports from coverage.postgresql.org |
Список | pgsql-www |
Greetings, * Tom Lane (tgl@sss.pgh.pa.us) wrote: > Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes: > > I tried it on Debian stable with gcc 6.3.0 and couldn't reproduce it. > > cc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516 > > Oh ... *that's* interesting. Are we sure this is the version in use > on coverage.postgresql.org? Yes, it's the same, but this isn't a gcov issue, I don't think. > Also, I just finished searching in vain for any plausibly-matching > bug at https://gcc.gnu.org/bugzilla/. I did find a few reports > suggesting that gcov could misbehave with nondefault build options > such as LTO. And "gcov -a" has also had issues. So maybe we ought > to have a look at exactly what coverage.postgresql.org's build > recipe is. Running gcov on the box itself in the source dir shows the same results which you got: --- -: 487: } #####: 488: break; -: 489: } -: 490: -: 491: /* can't get here */ #####: 492: elog(ERROR, "predicate_classify returned a bogus value"); -: 493: return false; -: 494:} --- Which seems to indicate that this actually is some kind of lcov bug. That makes more sense too since lcov is 1.13 on coverage.p.o, but you used 1.10 and said you didn't see an issue. Not sure if you have access to 1.13 easily, but if so, could be useful to see if you're seeing the same behavior under 1.13 where the gcov output is correct but lcov output isn't. Thanks! Stephen
Вложения
В списке pgsql-www по дате отправления: