This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: OT: Strange sender address (was Re: profiler &memory leak detector)


On Mon, 2002-07-22 at 15:12, Tim Drury wrote:
> 
> In the email sent below, why does the From: line appear to be:
> 
> From: NavEcos <ecos2@c1830598-a.siliconmotorsports.com>
> 
> Which appears to be using my siliconmotorsports.com domain name
> with a strange subdomain and an invalid user id?  Did everyone else
> see this address or did they get something else munged to look like
> it came from their address?
> 

They've done something magic - for me that message said:
  From: NavEcos <ecos2@c1830598-a.chez-thomas.org>

> No other email from the ecos lists appears to have done this.  Did
> the listserv software do this, or did the poster do this?
> 
> -tim drury
> 
> On Monday 22 July 2002 05:05 pm, NavEcos wrote:
> > Doing it per task is a little more work, I don't see any way to
> > determine which task I am in when I'm in the __default_exception_vsr
> > routine (system tick interrupt - actually this is the interrupt
> > for everything I think for the i386).  I don't think it should be
> > hard to determine which task was executing when the interrupt
> > happened, but I hadn't planned on doing it.  I bet it can be
> > done with a global variables - does anybody know if this is true
> > or not, and if it's true - how ?
> >
> > As to doing it with another interrupt with a higher frequency,
> > I agree, but some embedded systems may not have a spare
> > timer, so I think a "fall back" should be the system tick.  What
> > would be ideal is an interrupt that has a bit of jitter with a
> > frequency higher than the system tick.  I am pretty sure that
> > vxWorks does it based off from the system tick, but I am not
> > 100% certain.
> >
> > My version also requires : Linux, and a network connection and
> > binutils (i.e. readelf and the sort command) since my version is
> > a HACK and makes use of external programs.
> >
> > Many thanks,
> > -Rich
> >
> > P.S. Does anybody know what is wrong with the ecos-devel list?
> > Everything I send there is returned as a fatal error.
> >
> > On Monday 22 July 2002 02:14 pm, benny wrote:
> > > I guess such tool (similar to VxWorks SPY) would be great.
> > > It actually works "per task" so after a while one can get a list of
> > > task CPU consumption. Just the timer needs to be with the higher
> > > resolution (some spare timer?)
> > > -Benny
> > >
> > > > -----Original Message-----
> > > > From: ecos-discuss-owner@sources.redhat.com
> > > > [mailto:ecos-discuss-owner@sources.redhat.com]On Behalf Of NavEcos
> > > > Sent: Monday, July 22, 2002 1:32 PM
> > > > To: ecos-discuss@sources.redhat.com
> > > > Subject: [ECOS] profiler & memory leak detector
> > > >
> > > >
> > > > Try as I may, I cannot post this to the ecos-devel list, although I am
> > > > signed up for it, so I'm going to post it here in the discussion list.
> > > >
> > > > Has or does anybody use vxWorks?
> > > >
> > > > If you have, you may have used their profiler.  I have a very simple
> > > > profiler that I can make available for the x86 PC target.  I would like
> > > > to know if there would be any interest in making such a beast
> > > > available in the
> > > > main tree?  It requires a modification in the kernel in vectors.S.
> > > > Basically, I just detect interrupts with vector 0x20 (the 10 msec
> > > > interrupt)
> > > > and record the last function the program was in when the periodic
> > > > system tick fired.  I know this has some problems, namely anything that
> > > > has a delay
> > > > is tied to the system tick, but for stressed systems it gives a pretty
> > > > accurate view of what functions you have to streamline.
> > > >
> > > > VxWorks also has a tool called memtool.  It just detects which
> > > > functions (and if memory serves tasks) allocate and dealloc memory and
> > > > in which heap.
> > > > This is useful for detecting memory leaks although not extremely
> > > > useful.  I
> > > > don't have a similar tool, but I can make one.
> > > >
> > > > Is there any interest in putting these into the main tree?
> > > > Putting in HOOKS
> > > > to do it is very easy, and I would like to do that if there is
> > > > any interest
> > > > in incorporating it into the main tree.
> > > >
> > > > The profiler is very architecture dependant so I need help making
> > > > that work
> > > > for other platforms than x86 PC.
> > > >
> > > > -Rich
> > > >
> > > >
> > > > --
> > > > Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
> > > > and search the list archive: http://sources.redhat.com/ml/ecos-discuss
> 
> 
> -- 
> Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
> and search the list archive: http://sources.redhat.com/ml/ecos-discuss



-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]