Closed Bug 629209 Opened 13 years ago Closed 11 years ago

"Conditional jump or move depends on uninitialised value(s) at 0x51E5C5D: fill_window (in /builds/moz2_slave/valgrind-linux/build/objdir/toolkit/library/libxul.so)" during valgrind-linux run

Categories

(Core :: General, defect)

x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: cjones, Unassigned)

References

()

Details

(Keywords: sec-high)

http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1296072906.1296078989.22064.gz

localhost.localdomain - - [26/Jan/2011 13:53:42] "GET /js-input/access-binary-trees.html HTTP/1.1" 200 -
==23516== Thread 19:
==23516== Conditional jump or move depends on uninitialised value(s)
==23516==    at 0x51E5C5D: fill_window (in /builds/moz2_slave/valgrind-linux/build/objdir/toolkit/library/libxul.so)
{
   <insert a suppression name here>
   Memcheck:Cond
   fun:fill_window
}


We have two copies of zlib in the tree.  I'm not sure if this bug affects just one or both.
NSS is not part of libxul.so.
Assignee: nobody → nobody
Component: Libraries → ImageLib
Product: NSS → Core
QA Contact: libraries → imagelib
Chris, do you have the full call stack of the valgrind error?
Is 'deflate' or 'MOZ_Z_deflate' in the call stack?

I wonder if this is the well-known conditional jump that
depends on an uninitialized value in zlib's deflate function.
But zlib FAQ 36 says that error was fixed in zlib 1.2.4, and
we're using zlib 1.2.5:
http://www.zlib.net/zlib_faq.html#faq36
http://mxr.mozilla.org/mozilla-central/source/modules/zlib/src/zlib.h#40
(In reply to comment #1)
> NSS is not part of libxul.so.

Ah yes!  Thanks.

(In reply to comment #2)
> Chris, do you have the full call stack of the valgrind error?
> Is 'deflate' or 'MOZ_Z_deflate' in the call stack?

Sadly no, all I have is the tinderbox log from comment 0.  I haven't tried to reproduce this locally.

> I wonder if this is the well-known conditional jump that
> depends on an uninitialized value in zlib's deflate function.
> But zlib FAQ 36 says that error was fixed in zlib 1.2.4, and
> we're using zlib 1.2.5:
> http://www.zlib.net/zlib_faq.html#faq36
> http://mxr.mozilla.org/mozilla-central/source/modules/zlib/src/zlib.h#40

Hmm, interesting.  Probably a bug in our code then.  Thanks for the link.
Joe, anything we should do here? Do we know this is actually ImageLib?
Assignee: nobody → ashuk
Component: ImageLib → Java APIs for DOM
QA Contact: imagelib → dom-apis
Whoever's bug it is, "Java APIs for DOM" seems unlikely.
Assignee: ashuk → nobody
Component: Java APIs for DOM → ImageLib
QA Contact: dom-apis → imagelib
I just saw what I think is this bug in a valgrind run on Fedora 17 x86_64 with current trunk code:

==23103== Thread 23:
==23103== Conditional jump or move depends on uninitialised value(s)
==23103==    at 0x9354897: fill_window (deflate.c:1442)
==23103==    by 0x935509A: deflate_fast (deflate.c:1640)
==23103==    by 0x9353D15: MOZ_Z_deflate (deflate.c:901)
==23103==    by 0x860F981: nsDeflateConverter::OnDataAvailable(nsIRequest*, nsISupports*, nsIInputStream*, unsigned int, unsigned int) (nsDeflateConverter.cpp:128)
==23103==    by 0x861293B: nsZipDataStream::ProcessData(nsIRequest*, nsISupports*, char*, unsigned int, unsigned int) (nsZipDataStream.cpp:147)
==23103==    by 0x8612B68: nsZipDataStream::ReadStream(nsIInputStream*) (nsZipDataStream.cpp:175)
==23103==    by 0x861576E: nsZipWriter::AddEntryStream(nsACString_internal const&, long, int, nsIInputStream*, bool, unsigned int) (nsZipWriter.cpp:502)
==23103==    by 0x86153D1: nsZipWriter::AddEntryStream(nsACString_internal const&, long, int, nsIInputStream*, bool) (nsZipWriter.cpp:446)
==23103==    by 0x71BF2E8: mozilla::scache::CacheCloseHelper(nsACString_internal const&, nsAutoPtr<mozilla::scache::CacheEntry>&, void*) (StartupCache.cpp:400)
==23103==    by 0x71C1615: nsBaseHashtable<nsCStringHashKey, nsAutoPtr<mozilla::scache::CacheEntry>, mozilla::scache::CacheEntry*>::s_EnumStub(PLDHashTable*, PLDHashEntryHdr*, unsigned int, void*) (nsBaseHashtable.h:400)
==23103==    by 0x87C2F14: PL_DHashTableEnumerate (pldhash.cpp:715)
==23103==    by 0x71C1070: nsBaseHashtable<nsCStringHashKey, nsAutoPtr<mozilla::scache::CacheEntry>, mozilla::scache::CacheEntry*>::Enumerate(PLDHashOperator (*)(nsACString_internal const&, nsAutoPtr<mozilla::scache::CacheEntry>&, void*), void*) (nsBaseHashtable.h:223)
==23103==
Group: core-security
Keywords: sec-high
This doesn't seem like a gfx problem. I'm not sure who owns this code but we should find an owner.
Component: ImageLib → General
QA Contact: imagelib → general
(In reply to Josh Aas (Mozilla Corporation) from comment #6)
> I just saw what I think is this bug in a valgrind run on Fedora 17 x86_64
> with current trunk code: [..]

Can you rerun with --track-origins=yes, so we can see where the
uninitialised value came from?  There's an outside chance this could
help us distinguish between a real bug and the false positive
referenced in comment #2.
Josh, also a good idea would be to upgrade to a later version of Valgrind (3.8.1 as of now). There were some false positives in previous versions.
The original log link in comment 0 no longer works.

Our Valgrind version on tbpl was upgraded to 3.8.1 (bug 750856) and to a further special 3.8.1 tarball (bug 797573).

Looking at the stack in comment 6, it looks like bug 793607 - a similar bug that showed up on Valgrind tbpl runs (see meta bug 793882), which is now WFM.

Assuming WFM for this, and it looks like there was no additional information over the past months, and there seems to be nothing especially sensitive here, so opening up.
Group: core-security
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.