This is the zlib faq http://www.zlib.net/zlib_faq.html#faq36

 Valgrind (or some similar memory access checker) says that deflate is
performing a conditional jump that depends on an uninitialized value.
Isn't that a bug?

No. That is intentional for performance reasons, and the output of
deflate is not affected. This only started showing up recently since
zlib 1.2.x uses malloc() by default for allocations, whereas earlier
versions used calloc(), which zeros out the allocated memory.

Here is my suppression for it:

{
   zlib / http://www.zlib.net/zlib_faq.html#faq36
   Memcheck:Cond
   fun:longest_match
   fun:deflate_slow
   fun:MOZ_Z_deflate
}


On Sat, Dec 20, 2008 at 2:20 AM, Erik Kay <[email protected]> wrote:
>
> Yes, this is a known (benign) error.  See buganizer 1063732.  There
> are a number of these in the purify filters that you guys should look at to
> avoid duplicate effort.
>
> Erik
>
>
> On Fri, Dec 19, 2008 at 5:16 PM, Dan Kegel <[email protected]> wrote:
>>
>> I just ran into this today (using valgrind-3.4.0.SVN for its nifty
>> track-origins option):
>>
>> $ valgrind --track-origins=yes Hammer/net_unittests
>> --gtest_filter=GZipUnitTest.DecodeDeflate
>>
>> [ RUN      ] GZipUnitTest.DecodeDeflate
>> Conditional jump or move depends on uninitialised value(s)
>>   at longest_match (deflate.c:1121)
>>   by deflate_slow (deflate.c:1595)
>>   by MOZ_Z_deflate (deflate.c:790)
>>   by (anonymous namespace)::GZipUnitTest::CompressAll((anonymous
>> namespace)::EncodeMode, char const*, int, char*, int*)
>> (gzip_filter_unittest.cc:142)
>>   by (anonymous namespace)::GZipUnitTest::SetUp()
>> (gzip_filter_unittest.cc:75)
>>   by testing::Test::Run() (gtest.cc:1829)
>>   by testing::internal::TestInfoImpl::Run() (gtest.cc:1999)
>>   by testing::internal::TestInfoImpl::RunTest(testing::TestInfo*)
>> (gtest-internal-inl.h:574)
>>   by void testing::internal::List<testing::TestInfo*>::ForEach<void
>> (*)(testing::TestInfo*)>(void (*)(testing::TestInfo*)) const
>> (gtest-internal-inl.h:335)
>>   by testing::TestCase::Run() (gtest.cc:2094)
>>   by testing::TestCase::RunTestCase(testing::TestCase*)
>> (gtest-internal-inl.h:687)
>>   by void testing::internal::List<testing::TestCase*>::ForEach<void
>> (*)(testing::TestCase*)>(void (*)(testing::TestCase*)) const
>> (gtest-internal-inl.h:335)
>>  Uninitialised value was created by a heap allocation
>>   at malloc (vg_replace_malloc.c:207)
>>   by MOZ_Z_zcalloc (zutil.c:306)
>>   by MOZ_Z_deflateInit2_ (deflate.c:287)
>>   by MOZ_Z_deflateInit_ (deflate.c:210)
>>   by (anonymous namespace)::GZipUnitTest::CompressAll((anonymous
>> namespace)::EncodeMode, char const*, int, char*, int*)
>> (gzip_filter_unittest.cc:120)
>>   by (anonymous namespace)::GZipUnitTest::SetUp() 
>> (gzip_filter_unittest.cc:75)
>>   by testing::Test::Run() (gtest.cc:1829)
>>   by testing::internal::TestInfoImpl::Run() (gtest.cc:1999)
>>   by testing::internal::TestInfoImpl::RunTest(testing::TestInfo*)
>> (gtest-internal-inl.h:574)
>>   by void testing::internal::List<testing::TestInfo*>::ForEach<void
>> (*)(testing::TestInfo*)>(void (*)(testing::TestInfo*)) const
>> (gtest-internal-inl.h:335)
>>   by testing::TestCase::Run() (gtest.cc:2094)
>>   by testing::TestCase::RunTestCase(testing::TestCase*)
>> (gtest-internal-inl.h:687)
>>
>> [       OK ] GZipUnitTest.DecodeDeflate
>>
>> (Strange that zcalloc calls malloc instead of calloc on 32 bit
>> machines.  I wonder what the thinking there was?)
>>
>> >
>>
>
> >
>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to