Return-Path: Delivered-To: apmail-stdcxx-issues-archive@locus.apache.org Received: (qmail 22226 invoked from network); 12 Apr 2008 01:36:00 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 12 Apr 2008 01:36:00 -0000 Received: (qmail 82360 invoked by uid 500); 12 Apr 2008 01:36:00 -0000 Delivered-To: apmail-stdcxx-issues-archive@stdcxx.apache.org Received: (qmail 82337 invoked by uid 500); 12 Apr 2008 01:36:00 -0000 Mailing-List: contact issues-help@stdcxx.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@stdcxx.apache.org Delivered-To: mailing list issues@stdcxx.apache.org Received: (qmail 82328 invoked by uid 99); 12 Apr 2008 01:36:00 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 11 Apr 2008 18:36:00 -0700 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.140] (HELO brutus.apache.org) (140.211.11.140) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 12 Apr 2008 01:35:17 +0000 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id D2F8E234C0BE for ; Fri, 11 Apr 2008 18:33:04 -0700 (PDT) Message-ID: <1830928227.1207963984862.JavaMail.jira@brutus> Date: Fri, 11 Apr 2008 18:33:04 -0700 (PDT) From: "Travis Vitek (JIRA)" To: issues@stdcxx.apache.org Subject: [jira] Commented: (STDCXX-857) unexpected assertion from _rw_bufcat In-Reply-To: <1544142384.1207963744811.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/STDCXX-857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12588183#action_12588183 ] Travis Vitek commented on STDCXX-857: ------------------------------------- Internally the {{rw_asnprintf()}} routine will reallocate the destination buffer with a call to {{_rw_bufcat()}}. After the reallocation happens, we check some guard bytes to verify the buffer was not overflowed, and then we free it. There are two problems. First off, we don't ever write the guard bytes to the end of the input buffers provided by the user. This results in an unexpected assert. The second problem is that we don't track who owns the buffer, so we will end up calling {{free()}} on a pointer to stack data. My suggested fix is to add a flag to the Buffer struct in fmt_defs.h that indicates who owns the buffer. If, in {{_rw_bufcat()}}, we see that don't own the buffer, then we don't do bounds checking on it [because we have no idea what the contents were], and we won't attempt to free it. That seems pretty easy to handle. This simple fix does have one big drawback It may allow stack corruption because we aren't checking the buffer guard bytes after the first reallocation. The current code doesn't really do it, so it isn't really much of a loss, but it is something that I should mention. > unexpected assertion from _rw_bufcat > ------------------------------------ > > Key: STDCXX-857 > URL: https://issues.apache.org/jira/browse/STDCXX-857 > Project: C++ Standard Library > Issue Type: Bug > Components: Test Driver > Affects Versions: 4.2.1 > Reporter: Travis Vitek > Assignee: Travis Vitek > Fix For: 4.2.1 > > Original Estimate: 2h > Remaining Estimate: 2h > > Here is a testcase. > {noformat} > #include > #include > #include > int main (int argc, char* argv[]) > { > const char* s = 1 < argc ? argv [1] : "bug-zapper"; > char buffer [4]; > char *buf = buffer; > size_t bufsize = sizeof buffer; > rw_asnprintf (&buf, &bufsize, "%s", s); > if (buf != buffer) > free (buf); > return 0; > } > {noformat} -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.