From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30218 invoked by alias); 27 Nov 2013 07:58:50 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 29717 invoked by uid 48); 27 Nov 2013 07:58:37 -0000 From: "kcc at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug sanitizer/59302] tsan: Unexpected mmap in InternalAllocator! Date: Wed, 27 Nov 2013 07:58:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: sanitizer X-Bugzilla-Version: 4.9.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: kcc at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2013-11/txt/msg02743.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59302 --- Comment #3 from Kostya Serebryany --- (In reply to Joost VandeVondele from comment #2) > (In reply to Kostya Serebryany from comment #1) > > This isn't expected to happen and so we did not write a better warning > > message. > > We may be able to fix it, but the underlying problem is in your tests: > > it has a race that tsan is trying to report and which is suppressed > > (probably because a similar races was reported before). > > > > How many race reports do you see before tsan crashes? > > Did you suppress any of those? > > yes, I have a suppression in place to workaround PR59194. As it is an atomic > update in a hot loop, it will be triggered millions of times. Suppressing a race that happens so many times is no good. Even if we fix the crash above (which I'd prefer not to; instead we should emit a more descriptive message and die; we'll do that) tsan will remain very slow. The right solution is of course to fix the code to not have that race. The next good solution is to annotate the function with __attribute__((no_sanitize_thread)) -- but I don't know if fortran has anything like this. The next somewhat good solution is to blacklist the function (https://code.google.com/p/thread-sanitizer/wiki/Flags?ts=1385538776&updated=Flags#Blacklist_Format) but that is not supported by GCC and will have to be implemented first.