Re: Bug Report: Dereferencing a bad pointer

Richard B. Johnson (root@chaos.analogic.com)
Fri, 9 Nov 2001 08:33:14 -0500 (EST)


This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
Send mail to mime@docserver.cac.washington.edu for more info.

--1678434306-1644366103-1005312794=:3810
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Thu, 8 Nov 2001, David Chandler wrote:

> I get a seg fault on both 2.2 and 2.4 kernels by running the following
> one-line C program:
> int main() { int k = (int *)0x0; }
>
> Debugging the offender,
> int main() { int k = (int *)0xc0000000; }
> is not very informative: single-stepping over the sole command just
> hangs, and you have to press Control-C to interrupt gdb, at which point
> you can single-step right into the same problem again.
>
> When the program hangs, 'top' says that the CPU is fully utilized and
> the system is spending 80% of its time in the kernel and 20% in the
> offending process.
>
> Have you not been able to duplicate it on a 2.4 kernel on x86? If not,
> please tell me which 2.4 kernel correctly seg faults.
>
>
> David Chandler
>

Linux 2.4.1 seg-faults fine. Here is a test program that does not
use 'C' or the C runtime library. An assembly language program
is generated by this script. The first run just exits to the
Operating System using the Linux system call via interrupt 0x80.
The second run reads whatever is at virtual offset address 0xc000000
then attempts to exit to the OS. It checks to see if a core file
was generated (to see if it seg-faulted).

Try this out. If it properly seg-faults, you may have a 'C' compiler
that has optimized your offending line right out of existence!

If it doesn't work, you have truly discovered some problem with the
kernel version that doesn't work.

Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).

I was going to compile a list of innovations that could be
attributed to Microsoft. Once I realized that Ctrl-Alt-Del
was handled in the BIOS, I found that there aren't any.

--1678434306-1644366103-1005312794=:3810
Content-Type: TEXT/PLAIN; charset=US-ASCII; name="grok.sh"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.LNX.3.95.1011109083314.3810B@chaos.analogic.com>
Content-Description:

RklMRT0vdG1wL2dyb2sNCg0KY2F0IDw8RU9GID4ke0ZJTEV9LnMNCi5zZWN0
aW9uCS50ZXh0DQouZ2xvYmFsCV9zdGFydA0KLnR5cGUJX3N0YXJ0LEBmdW5j
dGlvbg0KDQpfc3RhcnQ6DQoJbW92bAlcJDB4YzAwMDAwMDAsICVlYngNCiMJ
bW92bAkoJWVieCksICVlYXgNCgltb3ZsCVwkMSwgJWVheA0KCXhvcmwJJWVi
eCwlZWJ4DQoJaW50CVwkMHg4MA0KRU9GDQphcyAtbyAke0ZJTEV9Lm8gJHtG
SUxFfS5zDQpsZCAtbyAke0ZJTEV9ICR7RklMRX0ubw0KY2htb2QgK3ggJHtG
SUxFfQ0KZWNobyAiVGhpcyBzaG91bGQgZXhlY3V0ZSBmaW5lIg0Kcm0gLWYg
Y29yZQ0KJHtGSUxFfQ0KaWYgWyAtZiBjb3JlIF0gOyB0aGVuDQogICBlY2hv
ICJGYWlsZWQiDQplbHNlDQogICBlY2hvICJPa2F5Ig0KZmkNCmNhdCA8PEVP
RiA+JHtGSUxFfS5zDQouc2VjdGlvbgkudGV4dA0KLmdsb2JhbAlfc3RhcnQN
Ci50eXBlCV9zdGFydCxAZnVuY3Rpb24NCg0KX3N0YXJ0Og0KCW1vdmwJXCQw
eGMwMDAwMDAwLCAlZWJ4DQoJbW92bAkoJWVieCksICVlYXgNCgltb3ZsCVwk
MSwgJWVheA0KCXhvcmwJJWVieCwlZWJ4DQoJaW50CVwkMHg4MA0KRU9GDQph
cyAtbyAke0ZJTEV9Lm8gJHtGSUxFfS5zDQpsZCAtbyAke0ZJTEV9ICR7RklM
RX0ubw0KY2htb2QgK3ggJHtGSUxFfQ0KZWNobyAiVGhpcyBzaG91bGQgc2Vn
LWZhdWx0Ig0KJHtGSUxFfQ0KaWYgWyAtZiBjb3JlIF0gOyB0aGVuDQogICBl
Y2hvICJPa2F5Ig0KZWxzZQ0KICAgZWNobyAiRmFpbGVkIg0KZmkNCnJtIC1m
IGNvcmUNCg0K
--1678434306-1644366103-1005312794=:3810--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/