Bug 1330907

Summary:	Address sanitizer (asan) interferes with normal execution
Product:	[Fedora] Fedora	Reporter:	Dridi Boukelmoune <dridi.boukelmoune>
Component:	gcc	Assignee:	Jakub Jelinek <jakub>
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	23	CC:	davejohansen, jakub, jwakely, law, mpolacek
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-09-25 19:00:57 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Dridi Boukelmoune 2016-04-27 09:43:35 UTC

Description of problem:

I have successfully used asan (thanks!) with GCC on Fedora (and FWIW with clang on Ubuntu [1]) but I'm now hitting an alleged bug for which I haven't found the pattern yet.

Basically in a project [2] of mine I use a range of tools on top of the test suite but this time it looks like asan's gone rogue. Instead of pointing out issues it changes the results [3] of the test suite. The rest of the build matrix is doing fine and while some results [3] are completely corrupted, others [4] are only partially.

Version-Release number of selected component (if applicable):

gcc-5.3.1-6.fc23.x86_64
libasan-5.3.1-6.fc23.x86_64

How reproducible:

Consistently. It also happens on Ubuntu (Travis CI) [5] with clang 3.4.

Steps to Reproduce:
1. git clone https://github.com/Dridi/cashpack.git
2. cd cashpack
3. ./bootstrap --with-asan
4. make check

Actual results:

Failing tests showing garbage in the output.

Expected results:

Either a proper failure with an asan report as I have seen before [1] or no failure at all.

Additional info:

In order to reproduce this one you first need the packages from the regular build system, plus bc and vim-common. There's a working RPM spec [6] for Fedora in the project. I test the spec using copr.

According to git bisect, this failure was introduced by the commit 465aec2 and staring hard at it didn't help me find an issue on cashpack itself. There's a realloc dodgy call, my only lead, but the rest of the test matrix [7] doesn't do anything wrong. I wouldn't expect corrupted results.

I plan to do more debugging, because this failure is surprisingly consistent. I get the same results on my Fedora machine than on the Travis CI Ubuntu container with different tool chains.

[1] https://travis-ci.org/Dridi/cashpack/jobs/125384893#L484
[2] https://github.com/Dridi/cashpack
[3] https://travis-ci.org/Dridi/cashpack/jobs/126035558#L411-L417
[4] https://travis-ci.org/Dridi/cashpack/jobs/126035558#L444-L452
[5] https://travis-ci.org/Dridi/cashpack/jobs/126035558#L24-L27
[6] https://github.com/Dridi/cashpack/commit/465aec2
[7] https://travis-ci.org/Dridi/cashpack/builds/126035540

Comment 1 Dridi Boukelmoune 2016-04-27 10:48:12 UTC

Debugging went faster than expected. I followed my lead on the realloc and added msan support to the build system. And in the commit I mention I forgot a memset call, which was immediately reported by msan.

The fix [1] is straightforward and I'm no longer sure there's a bug in asan. My assumption is that asan initializes memory with a predefined pattern of some sort, which would explain identical results on very different tool chains.

I'll let you ack and close this ticket or keep it open if it happens to be a bug. I'm now convinced it's expected behavior and apologizes for the noise.

Dridi

[1] https://github.com/Dridi/cashpack/commit/a323533