From: Helge Hafting <helgehaf@idb.hist.no>
To: Nikita Danilov <Nikita@Namesys.COM>
Cc: linux-kernel@vger.kernel.org
Subject: Re: kernel size, kcore fun
Date: Wed, 10 Oct 2001 11:10:30 +0200 [thread overview]
Message-ID: <3BC41086.6EB2056D@idb.hist.no> (raw)
In-Reply-To: <163112682879.20011009161634@port.imtp.ilyichevsk.odessa.ua> <15298.64405.809099.635670@beta.reiserfs.com>
Nikita Danilov wrote:
> Haha, I got several pieces of your mail message while doing this.
> (/proc/kcore is unique file, because grep of *any* string on it would
> succeeded).
I tried
strings /proc/kcore | grep any_weird_string_tsst_testtesttest
I expected it to hit a few times - the command line buffer,
the parameter to grep - but I got 7 screenfulls.
Then I understood - this hits the xterm scrollback buffer
too, which makes for some nice recursion.
Doing the same with output to a file hits the cache and
got some repetitions out of that. And then there's
internal buffers of strings and grep.
This reminded me of the commodore 64 game "fort apocalypse",
where your fly a helicopter around in caves. I patched the
machine code once so I could fly through walls. The game simply
loads memory into screen memory depending on coordinates.
So I got an interesting look at how code and state variables
look when interpreted as "terrain". I could identify
the variables holding x and y coordinates by looking at how
they changed when I moved in the two directions.
Then I came upon a very weird area, where everything
moved around in big jumps, changing in weird ways. After a while,
I figured out that I was looking at screen memory, having it
reloaded into itself with a different mapping. Crazy.
Finally - being able to press the fire button and fire
upon pieces of code and variables is the ultimate in
madman debugging and single-click crashes. :-)
Helge Hafting
next prev parent reply other threads:[~2001-10-10 9:11 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-10-09 14:16 kernel size VDA
2001-10-09 13:26 ` [solid]
2001-10-09 13:28 ` Nikita Danilov
2001-10-10 9:10 ` Helge Hafting [this message]
2001-10-09 14:16 ` Richard B. Johnson
2001-10-09 14:43 ` Ingo Oeser
2001-10-09 14:52 ` Richard B. Johnson
2001-10-09 15:43 ` Horst von Brand
2001-10-09 15:53 ` Richard B. Johnson
2001-10-10 1:29 ` Keith Owens
2001-10-10 13:00 ` Richard B. Johnson
2001-10-10 14:47 ` vda
2001-10-11 12:41 ` vda
2001-10-10 1:30 ` Kenneth Johansson
2001-10-09 15:55 ` Jakub Jelinek
2001-10-10 1:27 ` Keith Owens
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=3BC41086.6EB2056D@idb.hist.no \
--to=helgehaf@idb.hist.no \
--cc=Nikita@Namesys.COM \
--cc=linux-kernel@vger.kernel.org \
/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