search

Quuxplusone / LLVMBugzillaTest

0 stars 0 forks source link

Bug (memory leak) detected with maxloop=4 is undetected for maxloop > 4 #29729

Open Quuxplusone opened 8 years ago

Quuxplusone commented 8 years ago
Bugzilla Link PR30756
Status NEW
Importance P normal
Reported by mishugj@gmail.com
Reported on 2016-10-21 03:23:50 -0700
Last modified on 2016-10-21 03:23:50 -0700
Version 3.9
Hardware PC Linux
CC llvm-bugs@lists.llvm.org
Fixed by commit(s)
Attachments test.c (4694 bytes, text/x-csrc)
Blocks
Blocked by
See also 
Created attachment 17472
C file with memory leak

When running static analyzer against attached file, if using default maxloop
(4), a bug is detected (with incorrect location in report), but if running on
the same file with maxloop greater then 4 (tested with 20, 10, 5), the bug is
not detected.

My syste details:
$ uname -a
Linux harlequin 3.16.7-ckt11 #2 Thu Aug 20 08:44:53 UTC 2015 i686 GNU/Linux
$ cat /etc/debian_version
8.6
$ apt-cache show clang-3.9 | grep Version
Version: 1:3.9~svn281634-1~exp1

Bug reproduction:
$ cat Makefile
.PHONY: clean

test.o: test.c
    $(CC) -O1 -c $^

clean:
    @rm -rf test.o
$ make clean && scan-build-3.9 -maxloop 4 make
scan-build: Using '/usr/lib/llvm-3.9/bin/clang' for static analysis
/usr/share/clang/scan-build-3.9/bin/../libexec/ccc-analyzer -O1 -c test.c
test.c:172:5: warning: Potential leak of memory pointed to by 'recycle_map'
    entries_free(entries);
    ^~~~~~~~~~~~
1 warning generated.
scan-build: 1 bug found.
scan-build: Run 'scan-view /tmp/scan-build-2016-10-21-081646-1919-1' to examine
bug reports.
$ make clean && scan-build-3.9 -maxloop 5 make
scan-build: Using '/usr/lib/llvm-3.9/bin/clang' for static analysis
/usr/share/clang/scan-build-3.9/bin/../libexec/ccc-analyzer -O1 -c test.c
scan-build: Removing directory '/tmp/scan-build-2016-10-21-081719-1936-1'
because it contains no reports.
scan-build: No bugs found.

My expectation is that by increasing maximum loop count, the static analyzer
would try harder in finding bugs (at the cost of more memory & time). It would
also be expected that a possible bug detected with an lower loop limit be
invalidated when having a bigger loop limit (which would allow for more
analysis to prune suspects as unlikely). Yet, the bug reported above at maximum
loop 4 is a REAL bug (there IS a memory leak), so no amount of maximum loop
increasing should make clang static analyzer discard it (if it was already able
to detect it with maxloop 4).

Also, notice that the reporting when the bug is detected (maxloop 4) is
unexpected -- the memory leak is in indeed recycle_map but the location of the
error is wrong.

Note: The test file is as minimized as possible (for me). I removed most
standard headers (except <assert.h>) to reduce system dependence in triggering
this bug. I've tried to remove some more seemingly unrelated functionality but
doing so failed to reproduce the bug.
Quuxplusone commented 8 years ago

Attached test.c (4694 bytes, text/x-csrc): C file with memory leak