Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Pavel Dvorkin, Вы писали:

S>Ну, я не знаю, умеют ли PVS-тулзы находить дефекты в проекте неизвестной заранее структуры, и не формальные нарушения паттернов типа "у вас там в метод может передаваться null".

Что значит неизвестной заранее структуры ? Ему скармливали код, а он искал в нем дефекты. Работал он ЕМНИМ на per- source file основе, поэтому ошибки, размытые между разными файлами, не находил.

S>Какой PVS сумеет найти проблему
S>

S>When a job reaches a terminal status, this block only clears fields and cancels the ticker, but it leaves the m.beats[jobID] entry allocated. Because every job that emits any event creates a heartbeatState (see the earlier m.beats[jobID] = state), the map grows monotonically and will retain one entry per completed job for the lifetime of the engine. Over time this becomes a memory leak and increases lock contention on m.mu. Consider deleting the map entry when the status is succeeded/failed (or when canceling) so completed jobs don’t accumulate.

S>?

Ну насколько я это понимаю, это можно сформулировать чуть короче. В этот Map добавляются элементы, а this block его не очищает, так что может дело закончиться heap overflow.

Для Java или C# это отловить действительно не так просто. Более того, это может быть неверно. Кто его, этот map знает, может на него еще какая-то ссылка есть извне (не лучшая практика, но и не запрещено), и когда job reaches a terminal status, этим map кто-то и займется совсем в другом месте, и там использует и очистит — через пару интерфейсов и несколько паттернов

Но PVS работал для C++, когда я с ним имел дело, а там все намного проще — есть у этого класса деструктор ("this block"), а в нем не вызывается delete или free для вложенного map. Классический memory leak. Такое он ловить умел.

https://pvs-studio.com/en/blog/posts/cpp/0543/