linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Alexander Viro <viro@math.psu.edu>
To: Richard F Weber <rfweber@link.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>, linux-mm@kvack.org
Subject: Re: About reading /proc/*/mem
Date: Tue, 1 May 2001 13:14:17 -0400 (EDT)	[thread overview]
Message-ID: <Pine.GSO.4.21.0105011311060.9771-100000@weyl.math.psu.edu> (raw)
In-Reply-To: <3AEEEC48.80709@link.com>


On Tue, 1 May 2001, Richard F Weber wrote:

> The main thing I'm looking to do is examine data that's part of a 
> real-time process.  The process's execution can't be interrupted, 
> otherwise it makes debugging it inaccurate.  The applications is 
> certainly not looking to see every line of code get executed, but rather 
> have a real-time monitor of a symbol as it gets modified.  Now 
> viewing/selecting the symbol is done through a combination of nm's & a 
> console based util (hopefully GTK Based in the future).  Other 
> applications include recording this data to disk for later playback & 
> analysis.
> 
> Now the next logical step would be to create a debug module in the RT 
> system itself that dumps out the values we care about.  The problem with 
> this is we are looking at a lot of legacy code (done in fortran, C & 
> Ada) as well as tons of variables.  By peeking at the memory on the fly 
> we can dynamically decide which values are important for this run, 
> without having to record all possible data to the disk (which in itself 
> would be quite painful since disk accesses would make debugging again 
> difficult).

You want the data in each frame be taken at the same moment. Otherwise
you are going to see inconsistent data. I.e. tons of false warnings saying
that data corruption is going on when there's none.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

  reply	other threads:[~2001-05-01 17:14 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-05-01 13:33 Richard F Weber
2001-05-01 15:27 ` Eric W. Biederman
2001-05-01 16:35   ` Alexander Viro
2001-05-01 17:03     ` Richard F Weber
2001-05-01 17:14       ` Alexander Viro [this message]
2001-05-02 10:25     ` Stephen C. Tweedie
2001-05-02 11:39     ` Richard F Weber
2001-05-03 17:51       ` Richard F Weber
2001-05-01 16:53   ` Richard F Weber
2001-05-01 17:09     ` Alexander Viro
2001-05-01 17:29       ` Richard F Weber

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.GSO.4.21.0105011311060.9771-100000@weyl.math.psu.edu \
    --to=viro@math.psu.edu \
    --cc=ebiederm@xmission.com \
    --cc=linux-mm@kvack.org \
    --cc=rfweber@link.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox