Bug #88135 Use of uninitialised value of size 8 at (item_timefunc.cc:398)
Submitted: 18 Oct 2017 7:10 Modified: 19 Oct 2017 0:58
Reporter: yghmgl yang Email Updates:
Status: Duplicate Impact on me:
None 
Category:MySQL Server Severity:S3 (Non-critical)
Version:5.6.37 OS:Any
Assigned to: CPU Architecture:Any
Tags: debug valgrind-build

[18 Oct 2017 7:10] yghmgl yang
Description:
==111571== Use of uninitialised value of size 8
==111571==    at 0x6FF225: extract_date_time(st_date_time_format*, char const*, unsigned int, st_mysql_time*, enum_mysql_timestamp_type, char const**, char const*) (item_timefunc.cc:398)
==111571==    by 0x708089: Item_func_str_to_date::val_datetime(st_mysql_time*, unsigned int) (item_timefunc.cc:3252)
==111571==    by 0x700A12: Item_temporal_hybrid_func::val_decimal(my_decimal*) (item_timefunc.cc:854)
==111571==    by 0x65C1CC: Item::val_int_from_decimal() (item.cc:469)
==111571==    by 0x709627: Item_temporal_hybrid_func::val_int() (item_timefunc.h:560)
==111571==    by 0x9B5C61: mysql_do(THD*, List<Item>&) (sql_do.cc:34)
==111571==    by 0x7EB0D5: mysql_execute_command(THD*) (sql_parse.cc:2718)
==111571==    by 0x7F528B: mysql_parse(THD*, char*, unsigned int, Parser_state*) (sql_parse.cc:6489)
==111571==    by 0x7E8005: dispatch_command(enum_server_command, THD*, char*, unsigned int) (sql_parse.cc:1377)
==111571==    by 0x7E7037: do_command(THD*) (sql_parse.cc:1040)
==111571==    by 0x1E90BB67: threadpool_process_request(THD*) (threadpool_common.cc:321)
==111571==    by 0x1E90EA37: handle_event(connection_t*) (threadpool_unix.cc:1611)
==111571==    by 0x1E90EC94: worker_main(void*) (threadpool_unix.cc:1664)
==111571==    by 0xB99FDC: pfs_spawn_thread (pfs.cc:1860)
==111571==    by 0x5043DC4: start_thread (in /usr/lib64/libpthread-2.17.so)
==111571==    by 0x61AC21C: clone (in /usr/lib64/libc-2.17.so)
==111571==  Uninitialised value was created by a stack allocation
==111571==    at 0x707EA3: Item_func_str_to_date::val_datetime(st_mysql_time*, unsigned int) (item_timefunc.cc:3235)
==111571==
==111571==
==111571== HEAP SUMMARY:
==111571==     in use at exit: 387,159,863 bytes in 1,091 blocks
==111571==   total heap usage: 506,038 allocs, 504,947 frees, 796,451,899 bytes allocated
==111571==
==111571== LEAK SUMMARY:
==111571==    definitely lost: 0 bytes in 0 blocks
==111571==    indirectly lost: 0 bytes in 0 blocks
==111571==      possibly lost: 0 bytes in 0 blocks
==111571==    still reachable: 135 bytes in 1 blocks
==111571==         suppressed: 387,159,728 bytes in 1,090 blocks
==111571== Rerun with --leak-check=full to see details of leaked memory
==111571==
==111571== For counts of detected and suppressed errors, rerun with: -v
==111571== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

How to repeat:
pquery is random execute sql statement, so it hard to find which statement cause this issue,but it happened every day in my daily test.
[18 Oct 2017 13:53] MySQL Verification Team
Hi!

Thank you for your report.

I must say that this looks to me rather like a bug in the valgrind. If we take a peak in the code, we can see that everything is fine:

********************************************************************************************

      /* Conversion specifiers that match classes of characters */
      case '.':
        while (my_ispunct(cs, *val) && val != val_end)
          val++;
        break;
      case '@':
        while (my_isalpha(cs, *val) && val != val_end)
          val++;
        break;
      case '#':
        while (my_isdigit(cs, *val) && val != val_end)        /* offending line */
          val++;
        break;
      default:
        goto err;

********************************************************************************************

First of all, my_isdigit() is a macro that does not introduce any variables of its own. Second, CHARSET pointer `cs` is initialized at the very start of the same function, while the character pointer `val` is fully initialized in the calling function, which is val_datetime().

That is first proof. Now to the second one ...

If you look at the code in all other `case`s, you will notice that those all use the same variables in the very similar and even identical fashion.

And there are no errors for those cases ???? 

This makes this error a bug in valgrind.
[18 Oct 2017 13:55] MySQL Verification Team
One last note.

We use Valgrind regularly for all our builds and we can differentiate with valid reports from the invalid ones.
[18 Oct 2017 16:25] MySQL Verification Team
This bug is a duplicate of the internal bug, that is fixed in 5.7.

It will not be fixed in 5.6 as it does not pop-up there in the testsuite.
[19 Oct 2017 0:58] yghmgl yang
This bug is a duplicate of the internal bug, that is fixed in 5.7.

It will not be fixed in 5.6 as it does not pop-up there in the testsuite.

>>>
HI,Sinisa 

thanks for your analysis, can you tell me the bug # that is fixed in 5.7.
[19 Oct 2017 11:19] MySQL Verification Team
Hi!

As I wrote, this is an internal bugs , accessible only by Oracle employees and customers.

Are you sure that you have access to it ??