Bug 378293

Summary:	False Negative on memory leak
Product:	[Developer tools] valgrind	Reporter:	Darshit Shah <darnir>
Component:	memcheck	Assignee:	Philippe Waroquiers <philippe.waroquiers>
Status:	RESOLVED NOT A BUG
Severity:	normal	CC:	darnir, ivosh, philippe.waroquiers
Priority:	NOR
Version First Reported In:	3.12 SVN
Target Milestone:	---
Platform:	Arch Linux
OS:	Linux
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:

Description Darshit Shah 2017-03-30 23:23:47 UTC

Recently, we started using GCC's Memory and Leak sanitizers to look for possible memory leaks. While investigating one of them, we realized that valgrind does not report the said memory leak.

While working on the test suite for GNU Wget 2.0, we found the above false negative. The issue is strightforward, there is a C struct with a `const char *` member which is originally pointing to a stack-allocated string. Later, that pointer points to a heap allocated object, which is then replaced with another object causing a leak.

I would love to help you debug this issue and create a minimal example / dig into valgrind, but as of now I have no idea where to start. Here is the very simple patch I used to fix the issue:
https://github.com/darnir/wget2/commit/864c3ed549c83ffe92d846c7212632a9a89e7417
The leak happens in the file called `tests/libtest.c` at line 656 in `wget_test_start_server()`. If there is any other information I can provide / debug, do let me know.

Comment 1 Ivo Raisr 2017-03-31 05:12:04 UTC

Thank you for the report.

Please start with providing a simple reproducer.
File tests/test-metalink.c has around 300 lines and file tests/libtest.c almost 1000 lines. If you can squash it down to lets say 50-100, then it would great!

Comment 2 Philippe Waroquiers 2017-04-04 18:53:22 UTC

Yes, a small reproducer would be nice.

Alternatively, you could use gdb + vgdb and investigate
why valgrind believes the leaked memory is still reachable, using the
monitor commands
   leak_check
   block_list
   who_points_at

Comment 3 Philippe Waroquiers 2017-04-19 20:28:50 UTC

(In reply to Darshit Shah from comment #0)
> I would love to help you debug this issue and create a minimal example / dig
> into valgrind, but as of now I have no idea where to start. 
...
> If there is any other information I can provide
> / debug, do let me know.

Any news/feedback following suggestions in comment 2 and comment 3 ?
Thanks

Comment 4 Darshit Shah 2017-05-02 21:23:19 UTC

Hi

Sorry for the delayed response. While trying to create a minimum working example for the bug, I realised that the issue was in how we were using valgrind and not in valgrind itself. The leak was indeed there, but the original memory was allocated by a part of the program which wasn't run under valgrind. 

Sorry for the noise!