Re: Bug Report: Dereferencing a bad pointer

[David Chandler <chandler@grammatech.com>]

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!

BTW, your example program produces very similar output for the 2.4 and
2.2 kernels to which I have access.  I apologize for any confusion my
original report created -- 0xc0000000 was chosen because of its relation
to the start of the stack frame, and indeed it has nothing
to do with the size of virtual address space.


David Chandler


"Richard B. Johnson" wrote:
> 
> > > On Wed, Nov 07, 2001 at 06:23:13PM -0500, David Chandler wrote:
> > > > The following one-line C program, when compiled by gcc 2.96 without
> > > > optimization, should produce a SIGSEGV segmentation fault (on a machine
> > > > with 3 or less gigabytes of virtual memory, at least):
> > > >
> > > >         int main() { int k  = *(int *)0xc0000000; }
> > > >
> 
> This may not necessarily produce a seg-fault! If this virtual
> address is mapped within the current process (.bss .stack, etc.),
> It's perfectly all right to write to it although you probably
> broke malloc() by doing it. The actual value of the number in
> the pointer depends upon PAGE_OFFSET and other kernel variables.
> If you change the kernel, this number may change. It has nothing
> to do with the size of virtual address space, really.


> 
> All this stuff you "own". You can write to most all of it because
> the kernel has allocated it for you. Whether or not 'const' is
> really read-only is "implementation dependent".
> 
> In your case, it looks as though you scribbled over the top of
> your user stack, in some harmless place.


> Cheers,
> Dick Johnson


-- 

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