639317 - Syscall param write(buf) points to uninitialised byte(s) at nsDiskCacheMap::FlushRecords(int)

Status: RESOLVED WONTFIX

(Core :: Networking, defect)

Description

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Attachment: stdout output

I'm not sure how serious this is, but off a Mozmill fuzz test run in Valgrind off m-c changeset e56ecd8b3a68, after it ends, the Mozmill window and the browser window are closed. Immediately after the latter, this error gets hit (see the attachment.)

This isn't immediately reproducible, though.

.mozconfig:

. $topsrcdir/browser/config/mozconfig
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/valg-obj-ff-dbg-64-mc
mk_add_options MOZ_MAKE_FLAGS="-s -j6"
ac_add_options --enable-debug
ac_add_options --enable-optimize="-O"
#ac_add_options --enable-tests

ac_add_options --disable-jemalloc
ac_add_options --enable-valgrind

ac_add_options --with-ccache

Comment 2

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Bug 378517 may be related.

Comment 3

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

The assert in Valgrind in the log is Assertion 'tid != 0' failed, and may be http://bugs.kde.org/show_bug.cgi?id=267612

Comment 4

[Robert Sayre]

oh nice, I've seen this intermittently for *years*, but never figured out a test case.

Comment 5

[Julian Seward [:jseward]]

This is the most common kind of false positive from Memcheck now.
Happens when a struct is written to a socket or file descriptor (or is
otherwise "shipped off the premises") and the struct contains
alignment holes which are uninitialised.  Problem is there is no way
(afaik) in general to Memcheck to know which uninitialised sections
correspond to alignment holes and are therefore harmless, so it
complains about any uninitialised-ness it sees.

A kludgearound is to zero out the buffer at the point of allocation
(iow, calloc it), and then if there are still complaints, be
concerned, since that would mean the data itself contained
uninitialised stuff.  That's a bit difficult here though because the
buffer is allocated by realloc, not malloc.

Comment 6

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

(In reply to comment #5)
> A kludgearound is to zero out the buffer at the point of allocation
> (iow, calloc it), and then if there are still complaints, be
> concerned, since that would mean the data itself contained
> uninitialised stuff.  That's a bit difficult here though because the
> buffer is allocated by realloc, not malloc.

So can this bug be morphed into something useful for Mozilla folks or is this still regarded as a false positive?

Comment 8

[Julian Seward [:jseward]]

(In reply to comment #6)
> So can this bug be morphed into something useful for Mozilla folks or is this
> still regarded as a false positive?

It's _probably_ a false positive.  The way to tell for sure is to memset-0
the underlying block at it's reallocation point (the error msg tells you
where that is).  If the error still appears, then it's real.

Comment 9

[Patrick McManus [:mcmanus]]

whole new cache code