Re: Running BoundsChecker on 5.0.2

[Mike Pall <mikelu-0602@...>]

Hi,

Dario Accornero wrote:
> For instance, when calling lua_open() for the very first time, 
> BoundsChecker reports an uninitialized memory read in luaH_new (line 330 of 
> ltable):
> 
>    t->metatable = hvalue(defaultmeta(L));
> 
> Several similar errors are reported in luaK_posfix() (line 653 of lcode) 
> and other lines of the same module; in luaV_execute(), lines 496 and others 
> of lvm, BoundsChecker also reports some pointer arithmetic range errors.

None of these are errors. This is just copying uninitialized
memory. Either without using it or by overwriting it later with
valid data.

Modern memory checkers do validity bit propagation. They should
only report _uses_ of uninitialized data, not the mere act of
accessing or copying it. E.g. valgrind does this (but it's not
available for Windows). Maybe you need to turn on some option in
BoundsChecker?

See
  http://valgrind.org/docs/manual/mc-manual.html#mc-manual.value
for an explanation.

In the context of Lua this happens most often when nil stack slots
are copied (i.e. setnilvalue(o1) + setobj(o2, o1)). Here only the
tt (type) field is initialized, but the value field is not.
Copying the struct copies the uninitialized value field, too. This
is ok, because any use of o2 needs to check the type field first
and would never access the value field for a nil object.

AFAIK neither Lua 5.0 nor Lua 5.1 contain any errors of this kind
or valgrind would have caught them. Many people use it with the
Lua codebase on a regular basis (me too).

> Now, most of these problems might just be BoundsChecker's own fault, but 
> there are other, potentially more worrisome reports: a few dangling pointer 
> errors ("Pointer 0x..., allocated by realloc, has already been freed") 
> which might actually be real problems.

These should be investigated. But I guess you have to reduce the
number of false alarms first. Maybe you need a different tool or
just a newer version.

Bye,
     Mike