[
https://issues.apache.org/jira/browse/THRIFT-3086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14485101#comment-14485101
]
James E. King, III commented on THRIFT-3086:
--------------------------------------------
Coverity catches things other analysis tools will not; I recently ran coverity
on the libc sources because I am looking for a file descriptor misuse issue and
it found all sorts of resource leaks, use after free, etc.. over 250 high
severity and 500 total issues in all - because Coverity examines everything
together and checks all the possible combinations of branch execution. I
haven't seen tools like cppcheck get anywhere near that, and valgrind only
checks what executes, not the potential error cases. So I would highly
recommend we try and get a recent Coverity Scan on the codebase and then keep
it refreshed regularly. I'm trying to get the glibc maintainers to do the same
on the latest glibc to improve the quality of something practically everything
uses.
On valgrind memcheck, you will need to limit it to the C++ library, as the
glib/gobject implementation in c_glib/ is practically untestable with a memory
checker. I tried for a day to get rid of the issues by setting G_DEBUG and
other flags to force it to use malloc rather than the built-in slice allocator
but I could not; there is no global function I could find that would shutdown
and garbage collect everything before exiting, so there were always a ton of
leaks.
> C++ Valgrind Error Cleanup
> --------------------------
>
> Key: THRIFT-3086
> URL: https://issues.apache.org/jira/browse/THRIFT-3086
> Project: Thrift
> Issue Type: Bug
> Components: C++ - Library
> Affects Versions: 0.9.2
> Reporter: James E. King, III
> Assignee: Roger Meier
> Priority: Minor
> Fix For: 0.9.3
>
>
> valgrind identified a few issues in the C++ library:
> 1. In TFileTransport, inconsistent use of malloc then delete[]
> 2. In ZLibTest, leaking allocations
> 3. In RecursiveTest, leaking allocation
> These are minor, but a clean valgrind run is a happy valgrind run.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
