From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5369 invoked by alias); 19 Jul 2010 01:55:51 -0000 Received: (qmail 5361 invoked by uid 22791); 19 Jul 2010 01:55:50 -0000 X-SWARE-Spam-Status: No, hits=2.8 required=5.0 tests=AWL,BAYES_40,BOTNET,RDNS_DYNAMIC,SPF_SOFTFAIL,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from dsl027-162-100.atl1.dsl.speakeasy.net (HELO otter.localdomain) (216.27.162.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 19 Jul 2010 01:55:41 +0000 Received: from otter.localdomain (localhost [127.0.0.1]) by otter.localdomain (8.14.1/8.14.1) with ESMTP id o6J1tfaO030374; Sun, 18 Jul 2010 21:55:41 -0400 Received: from localhost (jmills@localhost) by otter.localdomain (8.14.1/8.14.1/Submit) with ESMTP id o6J1tevF030371; Sun, 18 Jul 2010 21:55:41 -0400 Date: Mon, 19 Jul 2010 01:55:00 -0000 From: John Mills Reply-To: John Mills To: ecos cc: Ross Younger In-Reply-To: <4C436D16.5040608@ecoscentric.com> Message-ID: References: <4C436D16.5040608@ecoscentric.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Subject: Re: [ECOS] eth_recv out of MBUFs X-SW-Source: 2010-07/txt/msg00033.txt.bz2 All - I was not able to use 'valgrind' successfully on a multithreaded eCos application, but for another reason: We combine a number of packages from other sources and parties and these contained so many questionable coding structures that valgrind gave up the job in a flurry of sarcastic comments. We were confident that our leaks were in our own code and not those third-party items because we have a long history of stable performance with those components. There were also some new pieces we had not written so we couldn't be 100% sure where our problems were arising. Since dynamic allocation and freeing are centralized, we used the "smart macro" approach and hooked a simple memory monitor that way. Indeed the problems were in code I had written. (Big surprise!) - John Mills On Sun, 18 Jul 2010, Ross Younger wrote: > John Mills wrote: >> 4. Use a free ('valgrind') or commercial code analyzer to track memory >> allocation (another "learning opportunity"!). > > valgrind is a wonderful idea in general, but very Linux-specific at the > moment. I wondered about valgrinding an eCos app running on the synth target > the other month; I got as far as determining that it seems to Just Work for a > simple single-threaded eCos configuration, but as soon as you bring in the > scheduler the threading model - which doesn't use ordinary Linux threads - > causes valgrind to get very very confused. > I found myself staring at the valgrind code, wondering how much effort it > would be to teach valgrind how to notice the synth spawning threads (at the > moment it does so by intercepting the clone syscall) but haven't had time to > actually try as yet... -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss