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)
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.
Updated•13 years ago
|
Comment 1•13 years ago
|
||
NSS is not part of libxul.so.
Assignee: nobody → nobody
Component: Libraries → ImageLib
Product: NSS → Core
QA Contact: libraries → imagelib
Comment 2•13 years ago
|
||
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
Reporter | ||
Comment 3•13 years ago
|
||
(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.
Comment 4•12 years ago
|
||
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
Comment 5•12 years ago
|
||
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==
This doesn't seem like a gfx problem. I'm not sure who owns this code but we should find an owner.
Comment 8•12 years ago
|
||
(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.
Comment 9•12 years ago
|
||
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.
Comment 10•11 years ago
|
||
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.
Description
•