more about proc

[Marcus Brinkmann]

Hi,

First, what I described earlier as a memory leak in fork handling doesn't seem
to be a real leak, rather the hash tables (esp pidhash) seem to grow more
quickly than necessary.  I am still investigating this.  With mtrace I could
verify that no memory is actually leaked (the trick is to call mtrace in
some rpc that is called after startup, and not in main, which will crash
proc).

Now to the tough issue.  Igor and me were able to reproduce the crash in a
gdb session and investigate the stack.  We see a similar bad pattern:

0x1224ea0:      0x01000100      0x01000100      0x00000100      0x01000100
0x1224eb0:      0x01000100      0x01000100      0x01000100      0x00000000
0x1224ec0:      0x01000100      0x01000100      0x01000100      0x00000100
0x1224ed0:      0x01000100      0x01000100      0x01000100      0x01000100
0x1224ee0:      0x00000100      0x01000100      0x01000100      0x01000100
0x1224ef0:      0x01000100      0x01000100      0x00000000      0x01000100
0x1224f00:      0x01000100      0x01000100      0x01000100      0x01000100
0x1224f10:      0x00000100      0x01000100      0x01000100      0x01000100
0x1224f20:      0x01000100      0x01000100      0x00000000      0x01000100
0x1224f30:      0x01000100      0x01000100      0x00000100      0x01000100
0x1224f40:      0x01000100      0x01000100      0x01000100      0x01000100
0x1224f50:      0x00000100      0x01000100      0x01000100      0x01000100
0x1224f60:      0x01000100      0x00000100      0x01000100      0x01000100
0x1224f70:      0x01000100      0x00000100      0x01000000      0x01000000
0x1224f80:      0x01000100      0x01000000      0x01000100      0x00000100
0x1224f90:      0x01000000      0x01000100      0x00000100      0x01000100
0x1224fa0:      0x01000100      0x01000100      0x01000000      0x01000000

Read as half words, the above is a pattern of 0x0100 and 0x0000.  Read as
bytes, it is ia pattern of 0x01 and 0x00 with every odd byte being 0x00.
This is the "Hey, I was here and scribbled over the stack!" signature by
the bad guy.  I know this for several reasons:

1. I set breakpoints in gdb, and when hitting one breakpoint, the program
got a BAD ACCESS immediately.  This was because the stack was corrupted of
this function, but a part of the backtrace worked (in fact, frame #0 was
intact!).  After frame #0, the above pattern was, and then probably more
frames (didn't check).

2. I investigated the other threads.  Two were just waiting for an RPC.
But thread #1 was actually sitting on a condition in S_proc_wait().
This thread also had the above pattern in its stack memory, but in a part
that was not in use.

3. In thread #1, I could see small parts of the above pattern within the
intact frames.  I assume that this is because the pattern was scribbled in
that part, and later the stack grow and wrote over the destructive pattern
itself.

The question is: How can we identify who writes the above patterns in these
areas?  How can we catch a corruption as early as possible?  The above
pattern is not a common one.  In fact, I have not seen it somewhere else
(for example, not in the hash tables).

Thanks,
Marcus






-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann              GNU    http://www.gnu.org    marcus@gnu.org
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de