没有合适的资源?快使用搜索试试~ 我知道了~
资源推荐
资源详情
资源评论
Purify:
Fast
Detection
of
Memory
Leaks
and
Access
Errors
Reed
Hastings
and
Bob Joyce
Pure Sofware
Inc.
Abstract
This
paper
describes
Purifyru,
a software
testing
and
quality
assurance
Ool
that
detects
memory
leaks and access
erors.
Purify
inserts
additional
checking
instructions directly
into the
object
code
produced
by
existing
compilers.
These
instructions
check every
memory
read and
write
performed
by
the
program-under-test and
detect several
types
of
access
errors,
such
as
reading
uninitialized
memory
or witing
to
freed
memory.
Purify
inserts checking
logic
into all of
the code
in
a
program, including third-party
and
vendor
object-code
libraries, and
verifies system
call
interfaces.
In addition,
Purify
tracks
memory
usage
and
identifies
individual
memory
leals using a
novel adaptation
of
garbage
collection
techniques.
Purify
produces
standard
executable
files compatible
with existing
debuggers,
and
currently
runs on
Sun
Microsystems'
SPARC
family
of
workstations.
Purify's
neafly-comprehensive
memory
access
checking
slows
the target
program
down
typically
by
less than a
facor of
three
and
has
resulted
in
significantly
more
reliable
software
for
several
development
goups.
L.
Introduction
A single
memory
access
error,
such as
reading
from
uninitialized
memory or
writing to
freed
memory can cause
a
progam to act unpredicAbly
or
even
crash.
Yet,
it is nearly
impossible
to eliminate
all such
errors
from a
non-trivial
progam
For one
thing, these
erors
may
produce
observable
effects
infrequently
and
intermittently.
Even
when
p-gru.r are tested
intensively
for extended
periods,
errors
can and
do escape
detection.
The
unique
combination
of
litco*stanos
required
for an
error to
occur and
for
its symptoms
lo becomc
visible
may
be
virtually
impossible to
create
in the development
or
test environment.
As
a
result,
proglammers
spend
much time
looking
for these
errors,
but
end-users
may experience
tlem
first.
[Miller90]
empirically
shows
the continuing
prevalence
of access errors
in
many
widely-used
Unix
Programs.
Even
when
a
memory
access
error triggers
an
observable
symptom,
the
error can take
days to
nack down
and
eliminate.
This
is
due
to the
frequently
delayed and
coincidental
connection
between
the cause,
typically
a
memory
comrption,
and
the symptom,
typically
a crash
upon
the
eventual
reading
of
invalid data.
Mennry
leaks,
rhat
is,
memory allocated
but
no longer accessible
to
the
program,
slow
program
execution
by
increasing
paging,
and
can cause
progams
to
run out
of
memory.
Memory
leaks
are
more
difficult
to detect than
illegal
memory
accesses.
Memory
leaks
occur
because
a block
of
memory
was not
freed, and
hence are errors
of
omission,
rather than
commission.
In
addition,
memory
leaks
rarely
produce
directly
observable
elrors,
but
instead
cumulatively
degrade
overall
performance.
USENIX
-Winter
'92
125
Purify: Fast Detection
of ...
Hastings,
Joyce
Once
found, memory leaks remain
challenging to fix. If memory is
freed
prematurely,
memory
access errors
can
result. Since access errors can
introduce
intermittent
problems,
memory
leak fixes
may require
lengthy
testing. Often,
complicated
memory
ownership
prolocols
are
required
!o administer
dynamic memory. Incorrectly
coded boundary
cases
can
lurk in
otherwise stable code for
years.
Both
memory leaks
and access errors are ffisy
!o
introduce into
a
program
but
hard
to eliminate. Without facilities for
detecting
memory
access errors,
it is risky
for
programmers
to attempt
to reclaim leaked memory
aggressively
because
that
may introduce
freed-memory
access enors with
unpredictable results.
Conversely,
without
feedback
on
memory leaks,
programmers
may waste memory
by
minimizing f ree
calls
in
order to avoid
freed-memory
access
errors.
A facility
that
reported
on both a
program's
memory
access errors and its memory
leaks
could
greatly
benefit
developers
by
improving
the robustness
and
performance
of their
prognms.
This
paper presents
Puri$,,
a tool that developers
and testers are using to find memory leaks
and access errors.
If
a
program
reads
or writes
freed
memory reads
or
writes
beyond an
array boundary,
or
reads from
uninitialized
memory
Purify
detects the error at the
point
of occurrence. In
addition, upon
demand, Purify
employs a
garbage
deteclor to
find
and
identify
existing memory leaks.
2.
Memory
Access Errors
Some
memory
access elrors
are detectable statically
(e.g.
assigning a
pointer
into
a short);
others are detectable
only
at run-time
(e.g.
writing
past
the
end
of a dynamic array);
and others are
detectable
only by a
programmer
(e.g.
storing
a
person's
age
in
the memory intended
to hold his heighQ.
Compilers and
tools such as
lint
find
statically-
detectable
errors. Purify finds
run-time-detectable
errors.
Errors detectable only at run-time
are challenging
to eliminate from
a
progmm.
Consider
ttre
following
example
Purify session,
running an application
that
is
using the Xll
Window System Release
4
(XllR4)
Intrinsics Toolkit
(Xt).
The
application is
called
my_prog,
and
has
been
prepared
by
Purify.
tutorial*
myjrog
-display
exodus:
0
Purify:
Dynamic
Error Checking
Enabled. Version
I.3.2.
(C)
1990,
1991 Pure
Software,
fnc. Patents
Pendinq.
.. .program
runs,
untiJ. the
user
cJ.oses
a vindow
whiTe
one of
jts
dja-
Togs is
stiJ1
up,. .
Purify:
Array
Bounds Violation:
Writing 88
bytes
past
the
end of
an array
at 0x4a7c88
(in
heap)
Error occurred
whi-Ie in:
bcopy
(bcopy.o;
pc
-
0x5d0c)
_XtDoPhase2Destroy
(Destroy.o,.
Iine
259)
XtDispatchEvent
(Event.o;
pc
=
0x33bfd8)
XtAppMainloop
(Event.o;
pc
:
0x33c48c)
XtMainloop
(Event.o;
pc
-
0x33c454)
mai-n
(1ci.o,'
11ne
445)
The
array is 160 bytes
long, and was
allocated
by ma11oc
call_ed
from:
XtMaIloc
(AIloc.o;
pc
:
0x32b7l-c)
XtReal-loc
(A1loc.o;
pc
=
0x32b754)
XtDestroywidget
(Destroy.
o; J-ine 2921
cl-ose_window
(i-nput
. o,'
line 642
)
maybe_close_window
(util.
o,' line
2003)
XtCallCallbacks
(Callback.o;
line
294)
L26
USENIX
-
Winter
'92
Hastings,
Joyce
Purify:
Fast Detection
of ...
The Purify eror
message
says that bcopy, called
from
_xtDoPhase2Destroy,
is
overwriting an array end, and
ttrat ttre target array
was allocated by
xtoestroywidget,lne292.
void
XtDestroyWidget
(widget)
Widget
widget;
{
292
app->destroy_list
:
(DestroyRec*)XtRealloc(
293
(char*)
app->destroy_Iist,
294
(unsigned)
sizeof
(DestroyRec)
*app->destroy_1ist_size)
;
;'
From
this
one can see
that the target
array is
a
destroy list,
an
internal
data
structure used as a
queue
of
pending
destroys by
the two-phase
Intrinsics
destroy
protocol.
In order
!o undentand
why the end of the array is
geuing
overwritten,
one
must
study
the caller of bcop%
_xtDoPhase2Destroy.
void
_XtDoPhase2Destroy
(appr
dispatch_level)
XtAppcontext
appt
int dispatch_level,'
253
inti=0;
254
DestroyRec*
dr
:
apP->destroy_1ist;
255
while
(i
<
app-)destroy_count)
{
256
if
(dr->dispatch_1eve1
>=
dispatch_Ievel)
{
257
Widgetw:dr-)widget;
258
if
(--app->destroy_count)
259
bcopy(
(char*) (dr+l)
'
(char*)dr'
250
apP->destroy_count*sizeof
(DestroyRec)
)
,'
267
xtPhase2Destroy(w);
262
l
else
{
263
i++,'
dr**;
)
l
)
Aided
by
the certain
knowledge that a
potentially
fatal
bug
lurks
here, one can see that the bcopy on
line
259 is
intended to delete
an
item in the destroy list
by copying the succeeding
items down
over the deleted one.
Unfortunately,
this
code only works
if
the
DestroyRec
being deleted
is
the
first
one on the
list, The
problem
is
that the
app->destroy_count
on
line 260
should be
app->destroy_count.
-
i.
As it is,
whatever
memory
is
beyond the desroy
list will
get
copied over
itself,
shifted
8 bytes
(the
sizc of one
DestroyRec)
down. The
resemblance to
reasonable data
would likely
confuse the
programmer
debugging the evennral core dump.
lvlany
people
find it
hard
to believe that such an obvious and
potentially
fatal
bug could
have
been
previously
undetected
in
code
as
mature and widely used as the XllR4 Xt Intrinsics.
Certainly
the code was extensively tested,
but
it
ook a
particular
set
of circumstances
(a
recursive
desroy) to exercise this bug, that
might not have
come
up
in
the
test suite.
Even
if
the bug
did come
up
in
the test
process,
the
memory comrpted may
not have
been
important
enough
to cause an easily
visible
symptom.
Consider
the testing
scenario
in more detail. Assume
optimistically that
the test team
has
the
resources
to ensure that
every basic block
is
exercised
by the test suite, and thus a
recursive
destroy
is
added
to the test suite to exercise
line
USENIX
-Winter'92
lz7
剩余11页未读,继续阅读
资源评论
- drfxiaoliuzi2018-08-08已经过时了的资源,现在已经用不了了
baidu_33414365
- 粉丝: 0
- 资源: 1
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功