| Bug #36989 | valgrind warning in Item_func_compress::val_str | ||
|---|---|---|---|
| Submitted: | 26 May 2008 19:07 | Modified: | 26 Mar 2009 23:29 |
| Reporter: | Shane Bester (Platinum Quality Contributor) | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server: General | Severity: | S3 (Non-critical) |
| Version: | 5.0.66a,, 5.0.76, mysql-5.1.26-rc-linux-i686, 6.0.10-debug | OS: | Any |
| Assigned to: | Kristofer Pettersson | CPU Architecture: | Any |
| Tags: | compress | ||
[26 May 2008 19:07]
Shane Bester
[26 May 2008 19:09]
MySQL Verification Team
I should better try newer zlib also: [sbester@box1 6.0]$ rpm -qa|grep zlib zlib-1.2.3-3 zlib-devel-1.2.3-3
[31 Jul 2008 13:41]
MySQL Verification Team
finally setting as verified because the official 5.1.26-glibc23 binaries have the problems, and now we see a cause:
==949== Conditional jump or move depends on uninitialised value(s)
longest_match (deflate.c:1138)
deflate_slow (deflate.c:1595)
deflate (deflate.c:790)
compress2 (compress.c:49)
compress (compress.c:68)
Item_func_compress::val_str (sql_string.h:99)
Item::save_in_field (item.cc:4832)
fill_record (sql_base.cc:8041)
select_union::send_data( (sql_union.cc:60)
JOIN::exec (sql_select.cc:1671)
mysql_select
handle_select
line 1138 is this:
do {
} while (*++scan == *++match && *++scan == *++match &&
*++scan == *++match && *++scan == *++match &&
*++scan == *++match && *++scan == *++match &&
*++scan == *++match && *++scan == *++match &&
scan < strend);
==949== Conditional jump or move depends on uninitialised value(s)
longest_match (deflate.c:1121)
deflate_slow (deflate.c:1595)
deflate (deflate.c:790)
compress2 (compress.c:49)
compress (compress.c:68)
Item_func_compress::val_str (sql_string.h:99)
Item::save_in_field (item.cc:4832)
fill_record (sql_base.cc:8041)
select_union::send_data (sql_union.cc:60)
JOIN::exec (sql_select.cc:1671)
mysql_select
handle_select
line 1121 is this:
if (match[best_len] != scan_end ||
match[best_len-1] != scan_end1 ||
*match != *scan ||
*++match != scan[1]) continue;
I don't have a definite SELECT query that causes this, but it was triggered by
giving random length hex strings to the function, e.g SELECT COMPRESS(0x123131231213) ...
[22 Sep 2008 9:48]
MySQL Verification Team
Kristofer, let me know if you need a definite testcase for this or if the bug is obvious from the code?
[23 Sep 2008 6:03]
Kristofer Pettersson
ZLib is known to cause valgrind error messages because of certain optimizations. Issues with valgrid error messages are mentioned in ZLib FAQ: http://www.zlib.net/zlib_faq.html#faq36 Shane, did you measure this with the suppression file (valgrind.supp) ?
[26 Sep 2008 12:08]
Kristofer Pettersson
I'm going to claim that this is not a bug. I've had problems reproducing the valgrind error messages, but they do on the other hand match the error messages talked about on the zlib page. I also added a debug routine which traverse all elements in the string we send to compress in order to try to capture any broken arguments without any signs of trouble.
[14 Jan 2009 7:12]
MySQL Verification Team
Kristofer, I finally found a simple testcase for this. 5.0.76-debug bzr and 5.1.31-debug bzr gives valgrind warnings on FC9:
select compress(' 1B.UADuhByxQVXW70MY P2L;8v.alAzGJMpb.');
Can you check if it's still safe to ignore ?
[23 Feb 2009 11:22]
Rafal Somla
Bug#43105 is a duplicate of this one. Please update its status when this one is fixed.
[5 Mar 2009 11:54]
Kristofer Pettersson
From the zlib FAQ: 39. 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.
[5 Mar 2009 11:55]
Kristofer Pettersson
I haven't seen anything new which would indicate a bug. I think it safe to ignore.
[9 Mar 2009 10:19]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/68606 2768 Rafal Somla 2009-03-09 Bug #36989 - valgrind warning in Item_func_compress::val_str Adding valgrind suppression rule for "Conditional jump or move depends on uninitialised value(s)" warning generated by zlib code.
[9 Mar 2009 10:25]
Rafal Somla
Pushed into mysql-6.0-backup-merge tree. Note: it will end up in 6.0 only. Joro approved it by email: Georgi Kodinov wrote: > Hi Kristofer, > > On 09.03.2009, at 10:58, Rafal Somla wrote: > >> Hi Kristofer, >> >> We can not ignore this bug - it makes our PB trees red. See bugs >> 42409, 43105 and 43456. I proposed a patch, which will keep valgrind >> quiet by suppressing this warning. You can find it here >> <http://lists.mysql.com/commits/68007>. Could you push it as a fix for >> 36989 or, alternatively, approve it and then I'll push it to our tree. > > > We need to add a suppression. > > Best Regards, > Joro
[26 Mar 2009 12:34]
Bugs System
Pushed into 6.0.11-alpha (revid:alik@sun.com-20090326121822-pt84kzxxayzho4mn) (version source revid:rafal.somla@sun.com-20090309101751-34o7kwovd856swto) (merge vers: 6.0.11-alpha) (pib:6)
[26 Mar 2009 23:29]
Paul DuBois
Not really a bug, it's a change to get PB to stop complaining. No changelog entry needed.
[17 Feb 2010 18:47]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/100664 3102 Chuck Bell 2010-02-17 Bug #36989 - valgrind warning in Item_func_compress::val_str Adding valgrind suppression rule for "Conditional jump or move depends on uninitialised value(s)" warning generated by zlib code. original changeset: 2599.112.32 (mysql-6.0-backup)
