public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: David Chandler <chandler@grammatech.com>
To: root@chaos.analogic.com
Cc: linux-kernel@vger.kernel.org
Subject: Re: Bug Report: Dereferencing a bad pointer
Date: Thu, 08 Nov 2001 16:57:26 -0500	[thread overview]
Message-ID: <3BEAFFC6.EAC56763@grammatech.com> (raw)
In-Reply-To: <Pine.LNX.3.95.1011108162912.239A-100000@chaos.analogic.com>

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

-- 

_____
David L. Chandler.                              GrammaTech, Inc.
mailto:chandler@grammatech.com         http://www.grammatech.com


"Richard B. Johnson" wrote:
> 
> On Thu, 8 Nov 2001, David Chandler wrote:
> 
> > Dick,
> >
> > You're right that the one-liner below may not necessarily produce a seg
> > fault, but shouldn't it terminate normally if it doesn't?  After all,
> > the program just *reads*.  Hanging does not seem to be an option!
> >
> You may want to see if any deliberate seg-fault actually gets
> delivered. Try to read *(0).  If that works (seg-faults), then
> there may be a problem with some boundary condition on paging.
> 
> I can't duplicate the problem here. You can also try to trace
> the code execution to see if it falls into some user-space loop.
> 
> 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.

  reply	other threads:[~2001-11-08 21:57 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-11-07 23:23 Bug Report: Dereferencing a bad pointer David Chandler
2001-11-07 23:40 ` Benjamin LaHaise
2001-11-08 15:29   ` David Chandler
2001-11-08 16:02     ` Richard B. Johnson
2001-11-08 17:17       ` David Chandler
2001-11-08 21:32         ` Richard B. Johnson
2001-11-08 21:57           ` David Chandler [this message]
2001-11-08 22:39             ` Brian Gerst
2001-11-08 23:15               ` David Chandler
2001-11-09 13:33             ` Richard B. Johnson
2001-11-08 17:53       ` Tahar
2001-11-08 16:27     ` Benjamin LaHaise
2001-11-08 18:02       ` Alan Cox

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=3BEAFFC6.EAC56763@grammatech.com \
    --to=chandler@grammatech.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=root@chaos.analogic.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