From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23939 invoked by alias); 3 Oct 2014 10:31:53 -0000 Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org Received: (qmail 23928 invoked by uid 89); 3 Oct 2014 10:31:52 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.1 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mail2-relais-roc.national.inria.fr Received: from mail2-relais-roc.national.inria.fr (HELO mail2-relais-roc.national.inria.fr) (192.134.164.83) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (CAMELLIA256-SHA encrypted) ESMTPS; Fri, 03 Oct 2014 10:31:51 +0000 Received: from ip-189.net-81-220-143.rev.numericable.fr (HELO laptop-mg.local) ([81.220.143.189]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Oct 2014 12:31:47 +0200 Date: Fri, 03 Oct 2014 10:31:00 -0000 From: Marc Glisse Reply-To: gcc-help@gcc.gnu.org To: Jonathan Wakely cc: =?ISO-8859-15?Q?Henrik_Mannerstr=F6m?= , gcc-help Subject: Re: std::string clobbers memory when compiling without optimizations In-Reply-To: Message-ID: References: <542E5BF1.2070508@gmail.com> <542E75B9.9010504@gmail.com> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT X-SW-Source: 2014-10/txt/msg00017.txt.bz2 On Fri, 3 Oct 2014, Jonathan Wakely wrote: > On 3 October 2014 11:08, Henrik Mannerström wrote: >> Hi, >> >> On 10/03/2014 12:58 PM, Jonathan Wakely wrote: >>> Have you tried valgrind? Or compiling with GCC's -fstack-protector >>> option? I can't reproduce the problem, and I think it's pretty >>> unlikely std::string has that kind of bug without someone noticing >>> years ago. >> >> I'm not assuming that std::string has a bug (even though the title might >> suggest that), I'm just saying that the gdb watchpoint is triggered >> inside that function. I tried valgrind memcheck, but I'm no expert, so >> suggestions are welcome. Below is the output with stack-protector, what >> do you make out of it? Could it be my installation? >> >> - Henrik >> >> >> $ g++-4.9 -std=gnu++1y mvu.cc -o mvu >> $ ./mvu >> Correct diagonal: 1 1 1 >> Eigen::Matrix >> Incorrect diagonal: 1.81749e-316 1 1 >> $ g++-4.9 -std=gnu++1y -fstack-protector-all mvu.cc -o mvu >> $ ./mvu >> Correct diagonal: 1 1 1 >> Eigen::Matrix >> Incorrect diagonal: 1 2 3 > > I get the same "1 2 3" result using -fstack-protector-all and valgrind. > > My guess is that Sigma holds a dangling reference to some temporary > object that has gone out of scope, and the function call t2s > overwrites that stack memory, then when you return to main you go > through the dangling reference. > > Are you sure you're using the Eigen types correctly? He is using "auto" with an expression template library, so I'd say that it is unlikely he is using it correctly, indeed... -- Marc Glisse