This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
Re: eth_recv out of MBUFs
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