Bug 1330907 - Address sanitizer (asan) interferes with normal execution
Summary: Address sanitizer (asan) interferes with normal execution
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: gcc
Version: 23
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-04-27 09:43 UTC by Dridi Boukelmoune
Modified: 2016-09-25 19:00 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-09-25 19:00:57 UTC
Type: Bug


Attachments (Terms of Use)

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


Note You need to log in before you can comment on or make changes to this bug.