From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 98890 invoked by alias); 9 Apr 2015 12:08:12 -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 98638 invoked by uid 48); 9 Apr 2015 12:08:08 -0000 From: "jvdelisle at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/65089] FAIL: gfortran.dg/io_real_boz(2|_[45]).f90 when tested with -fsanitize=address Date: Thu, 09 Apr 2015 12:08:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: fortran X-Bugzilla-Version: 5.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: jvdelisle at gcc dot gnu.org X-Bugzilla-Status: NEW 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: 2015-04/txt/msg00677.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65089 --- Comment #11 from Jerry DeLisle --- (In reply to Jakub Jelinek from comment #9) > (In reply to Jerry DeLisle from comment #8) > > True, fortran strings are not generally NULL terminated. However, for > > internal representation between Frontend and library we try to do so for > > safety. Evidently missed one or don't have it in this case. Still odd that > > my manual, so to speak, 'for' loop is finding a NULL and counting the > > correct length. I will do some more digging, probably something "obvious". > > Just not seeing it yet. > > Has libgfortran been compiled with -fsanitize=address, or just the testcase? > If the for loop is in the library that has not been instrumented, it is > obvious why it doesn't trigger, while if you call strlen there and it is > emitted as a library call, then it is intercepted by libasan and thus is > instrumented. And the global variable (string literal) strlen is called on > resides in the executable and is instrumented there. Thanks for this explanation, it makes perfect sense. Also, I have located the problem. When we do internal string I/O (using a string instead of an actual file) we bypass format string caching and skip creation of the null terminated version of the format string. I am working on a patch. format_cache_ok = !is_internal_unit (dtp); --- snip --- if (format_cache_ok) { char *fmt_string = xmalloc (dtp->format_len + 1); memcpy (fmt_string, dtp->format, dtp->format_len); dtp->format = fmt_string; dtp->format[dtp->format_len] = '\0'; }