Date: Sat, 11 Jan 2003 18:02:41 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Alexander Pohoyda <alexander.pohoyda@gmx.net> Cc: freebsd-hackers@freebsd.org Subject: Re: 5.0-RC2 panics on IBM ThinkPad 600. Message-ID: <3E20CCC1.C5D7525C@mindspring.com> References: <200301112232.h0BMWlGL004355@oak.pohoyda.family>
next in thread | previous in thread | raw e-mail | index | archive | help
Alexander Pohoyda wrote:
>
> Hackers, thank you for your quick response!
>
> I am having one more panic which happens quite often.
> Here is the message:
>
> Memory modified after free 0xc1bcfe00(508)
> panic: Most recently used by temp
>
> Debugger("panic")
> Stopped at Debugger+0x54: xchgl %ebx,in_Debugger.0
> db>
>
> Memory address is sometimes 0xc1bcae00.
> Any ideas? Volunteers to help me with debug? :-)
Write a stupid little program that uses the kernel options you
specified in your kernel build, and printf's the "sizeof()" for
all kernel structures, followed by the name of the structure.
I've personally written this program many times, but I do not
keep it up to date with regard to -current, because -current
does not sit still on interface contracts between different
programmers; keeping the program up to date would therefore be
a full time job.
Then pipe the output of this program to "sort -n", and redirect
that to a file. Run "more" on the file, and find out what is
508 bytes in size.
With this information in hand, examine all uses of the structure(s)
involved, to determine if there is an extra free occurring, or if
the contents of the structure are being accessed or modified after
the reference count on the structure goes to zero. If you have to,
add reference counting to the structure, as part of this.
One potential complication is that the memory manager, when it is
attempting to make this sort of thing possible, stomps on the front
of the structure (usually, first 3 words, if this is an i386 machine),
and will destroy the reference count, making it appear artificially
high (and non-zero) following an underflow following an overflow (as
I personally discovered with the ucred structures), and can otherwise
stomp on house-keeping elements within the structure, which should
actually remain unmodified following a free().
If this is the case, you will need to modify the order of elements
in the structure in question, to ensure that the freelist manager
and the debugging code does not stomp it.
This will find your error for you, since the error is not in the
code where it's being reported, it's in the code that had the memory
before it was being used by the code where it's being reported.
"Good luck, Mr. Phelps."
-- Terry
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E20CCC1.C5D7525C>