From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18813 invoked by alias); 28 Jul 2009 13:43:18 -0000 Received: (qmail 18796 invoked by uid 22791); 28 Jul 2009 13:43:17 -0000 X-SWARE-Spam-Status: No, hits=-1.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_35,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.33.17) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 28 Jul 2009 13:43:07 +0000 Received: from zps75.corp.google.com (zps75.corp.google.com [172.25.146.75]) by smtp-out.google.com with ESMTP id n6SDh2FU003598 for ; Tue, 28 Jul 2009 14:43:03 +0100 Received: from qw-out-2122.google.com (qwb9.prod.google.com [10.241.193.73]) by zps75.corp.google.com with ESMTP id n6SDh0UH018610 for ; Tue, 28 Jul 2009 06:43:00 -0700 Received: by qw-out-2122.google.com with SMTP id 9so12288qwb.21 for ; Tue, 28 Jul 2009 06:42:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.96.6 with SMTP id f6mr1971904qcn.81.1248788579887; Tue, 28 Jul 2009 06:42:59 -0700 (PDT) In-Reply-To: References: <8ac60eac0907272358n7cd27407va0a9982ea4d466bc@mail.gmail.com> Date: Tue, 28 Jul 2009 13:43:00 -0000 Message-ID: <8ac60eac0907280642h4700d7d5m95204a6e201281da@mail.gmail.com> Subject: Re: Trying to spot memory corruption with core dump From: Paul Pluzhnikov To: Pavel Shevaev Cc: gdb@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-System-Of-Record: true X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2009-07/txt/msg00219.txt.bz2 On Tue, Jul 28, 2009 at 12:11 AM, Pavel Shevaev wrote: >> On Linux/ix86 and x86_64, nothing beats Valgrind (for finding heap corruption). > > Oh, forgot to mention this on the very first post. I'm using linux > x86_64 and I'm aware of Valgrind and I even tried it....the problem is > it doesn't detect any memory corruption at all and what's even more > amazing my application doesn't seg.fault under Valgrind even after > running the whole day :( With typical VG slow-downs (50x to 100x), you need to run it longer: 3 hours without VG => 50*3/24.0 == 1 week under VG. > I think it's because Valgrind slows down the > application considerably and some how the rare edge case when memory > corruption occurs simply doesn't happen. Is the application multithreaded? Does it process a "random" event source? VG could change timing and make bugs hide; that's not unheard of. You could try setting MALLOC_CHECK_=2 in the environment (see 'info libc'), or linking the application with '-lmcheck'. Finally, does your application handle async signals? If so, does signal handler call anything async-signal unsafe? That is one common source of "random" heap corruption. Cheers, -- Paul Pluzhnikov