From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13384 invoked by alias); 28 Jul 2009 16:55:53 -0000 Received: (qmail 13375 invoked by uid 22791); 28 Jul 2009 16:55:52 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from ey-out-1920.google.com (HELO ey-out-1920.google.com) (74.125.78.149) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 28 Jul 2009 16:55:43 +0000 Received: by ey-out-1920.google.com with SMTP id 5so48536eyb.24 for ; Tue, 28 Jul 2009 09:55:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.53.199 with SMTP id g49mr2007669wec.49.1248800140129; Tue, 28 Jul 2009 09:55:40 -0700 (PDT) In-Reply-To: <8ac60eac0907280642h4700d7d5m95204a6e201281da@mail.gmail.com> References: <8ac60eac0907272358n7cd27407va0a9982ea4d466bc@mail.gmail.com> <8ac60eac0907280642h4700d7d5m95204a6e201281da@mail.gmail.com> Date: Tue, 28 Jul 2009 16:55:00 -0000 Message-ID: Subject: Re: Trying to spot memory corruption with core dump From: Pavel Shevaev To: Paul Pluzhnikov Cc: gdb@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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/msg00221.txt.bz2 > 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. Unfortunately, I can't afford it :( > Is the application multithreaded? Yes. And yes, I tried using helgrind as well and it discovered nothing... > Does it process a "random" event source? Well, it uses async handlers of boost::asio which in my case used as a nice demultiplexing wrapper around epoll > 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'. Thanks for the MALLOC_CHECK_ tip! I'm going to stress test my app using it... > 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. Oh, no, nothing like that is used. P.S. thanks again for being helpful, I've been trying to spot this memory corruption for a week, I think I'm gradually going mad, so, _any_ help is highly appreciated -- Best regards, Pavel