Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 17 Feb 1999 08:12:01 +1100
From:      Peter Jeremy <peter.jeremy@auss2.alcatel.com.au>
To:        hackers@FreeBSD.ORG
Subject:   Re: vm_page_zero_fill
Message-ID:  <99Feb17.080111est.40356@border.alcanet.com.au>

next in thread | raw e-mail | index | archive | help
Kevin Day <toasty@home.dragondata.com> wrote:
> all code I've written expects
>malloc(), new, etc to have garbage in them, not be zeroed)

As it should, because malloc() does not guarantee the contents of the
returned memory :-).

By disabling vm_page_zero_fill, you are also making BSS uninitialised.
The C standard explicitly states that all uninitialised non-automatic
variables will contain zero/NULL.  Much C code relies on this -
including library code that you may be explicitly or implicitly using.

"John S. Dyson" <dyson@iquest.net> wrote:
>  The kernel could also set the vm behavior to trap with a special
>fault if a process reads a memory location without it being intialized
>by either a write, a pagein from disk or inheritance from a parent
>process.

This is something that would be wonderful for general debugging.
Unfortunately, I can't see how this could be made to work with
anything better than page-size granularity (without making the
performance abyssmal).  Consider the code:

	static int	foo[2];
	int		x, y;

	foo[0] = 10;
	x = foo[1];
	y = foo[0];

How can I get the reference to foo[1] to trap, without the later
reference to foo[0] trapping?  Page-boundary alignment of foo and/or
use of the i386 hardware breakpoint registers isn't allowed because it
won't generalise.  [The assignment to foo[0] is allowed to trap since
this is probably where the physical page is allocated].

perlsta <bright@cygnus.rush.net> wrote:
>Last suggestion, start compiling things with -Wall, find uninitialized
>variable references,

-Wall will only detect uninitialised automatic variables.  Finding
non-automatic variables that are read before being explicitly assigned
is far more difficult (because it requires flow analysis of the entire
program, not just a single function).

Peter
--
Peter Jeremy (VK2PJ)                    peter.jeremy@alcatel.com.au
Alcatel Australia Limited
41 Mandible St                          Phone: +61 2 9690 5019
ALEXANDRIA  NSW  2015                   Fax:   +61 2 9690 5982


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?99Feb17.080111est.40356>