Что-то здесь не так.

Что мешает проверять исходники с виндовой рабочей станции?

Судя по твоему посту, ты просто не понял ничего из постов от PVS. В большей части случаев там выявлялись места, приводящие к самому мерзкому типу ошибок - не воспроизводимым, проявляющимся лишь время от времени.

Суть статического анализа, не в том, чтобы прискакать на единороге перед релизом и найти два фатальных бага. Суть статического анализа в регулярном использовании и нахождении многих ошибок на самом раннем этапе. Зачем долго и мучиться отлаживаться, если можно найти многие ошибки сразу. Да не все ошибки, но многие. Это экономия сил и времени разработчика. Пример: https://habrahabr.ru/post/198836/

И ещё на тему, что программы и так работают: http://www.viva64.com/ru/b/0336/

Мой пример: боролся я однажды с интересным багом при инициализации дополнительных ядер процессора AMD Merlin Falcon в прошивке. Нулевое ядро там назвают BSP (BootStrap Processor), а остальные - AP (Application Processor), так вот, инициализация очередного AP иногда зависала на ровном месте в ~0.1% случаев (а т.к. процесс работы прошивки до этого времени детерминирован, то в таких зависаниях чаще всего виновато оборудование или код, который его неправильно использует).
Зависающая прошивка - это show stopper, т.е. пока это не починим, дальше разрабатывать нет смысла. Я просидел две недели в попытках понять, что не так, и пошел пробовать статические анализаторы, которые давали попробовать (AMI использует CppCheck для своего кода, но он совсем слабый по сравнению с любыми коммерческими анализаторами).
В итоге PVS-Studio нашла переменную в структуре, у которой был пропущен аттрибут volatile, а в коде было что-то вроде такого:
// Prepare CPU context structure
...
apStructPtr->InSync = 0;
...
// Send context to AP
...
// Wait for AP sync
while(apStructPtr->InSync) {
// Still waiting
}

Т.к. ни apStructPtr, ни InSync не были помечены как volatile, то компилятор просто выбрасывал цикл, т.к. он не влияет на наблюдаемое поведение и аналогичен while(0), в результате получалась гонка между внутренними процессами в CPU и продолжением исполнения, и выигрывали её чаще всего внутренние процессы, т.е. все работало почти всегда. Но потом стало больше ядер, вышли новые процессоры и более долгой синхронизацией, и все сломалось.
А PVS-Studio сразу сообщила, что вот тут место подозрительное, проверьте. Проверил, добавил volatile, баг исчез. Вот так и помогает, вполне реально.

Лучику света наверное не пристало выдавать коменты "пришлось сделать под линукс". Это больше похоже на темную проприетарную ...

У них свои тулзы.

Оно не только может, но и проверяет периодически, что недвусмысленно видно в git log.

П.С. Есть тут хоть кто-то, кто знает кого-то кто купил данный продукт? Во сколько он обошёлся и окупилось ли его использование?

Не пробовали соответствующее предупреждение в его начало писать?  Примерно как:

---
# WARNING!  DO NOT READ THIS WITH YOUR EYES!
# This file contains raw redundant data for plog-converter utility, please use it.
---

И, соответственно, в конце выдачи софтины, которая генерирует этот файл -- тоже предупреждать, мол, теперь пропустите через фильтр.

> В следующей версии, мы планируем изменить изначального формат лога,
> чтобы было понятно, что это некий бинарный формат и он не предназначен для просмотра.
> Это должно подсказать программисту, что с этим файлом надо ещё что-то сделать и он,
> продолжив чтение документации, будет узнавать про plog-converter.

У нас Алексей Смирнов -- самый страшный тестер: он умеет очень убедительно "включить блондинку", хитро ухмыляясь и тыкая в самое больное место, куда тыкать НЕЛЬЗЯ! :]

Не пробовали такой подход?  Ну, не делать то, что знаете (сами, "из документации"), а сделать ровно наоборот и прикинуть, как можно было наиболее разумным способом "подсказать" на месте?

Документация -- это хорошо, но её же читают только когда ничего не работает, и то не все...