Re: [ECOS] eth_recv out of MBUFs

[John Mills <johnmills at speakeasy dot net>]

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