Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Minor
-
Resolution: Fixed
-
Affects Version/s: 5.5.34, 10.0.7
-
Component/s: Storage Engine - TokuDB
-
Labels:
-
Environment:Arch Linux, gcc 4.8.2
Description
From the compilation log:
build/mariadb/src/mariadb-5.5.34/storage/tokudb/ft-index/ft/ft-ops.cc: In function 'ft_leaf_run_gc':
/build/mariadb/src/mariadb-5.5.34/storage/tokudb/ft-index/ft/ft-ops.cc:2261:26: error: 'leaf_entry' may be used uninitialized in this function [-Werror=maybe-uninitialized]
if (leaf_entry->type != LE_MVCC) {
^
/build/mariadb/src/mariadb-5.5.34/storage/tokudb/ft-index/ft/ft-ops.cc: In function 'ft_leaf_run_gc':
/build/mariadb/src/mariadb-5.5.34/storage/tokudb/ft-index/ft/ft-ops.cc:2261:26: error: 'leaf_entry' may be used uninitialized in this function [-Werror=maybe-uninitialized]
if (leaf_entry->type != LE_MVCC) {
^
As a temporary workaround I decided to disable TokuDB engine, but I want to re-enable it as soon as it possible.
Gliffy Diagrams
Attachments
Issue Links
Activity
- All
- Comments
- Work Log
- History
- Activity
- Transitions
This is tracked upstream here: https://github.com/Tokutek/ft-index/issues/109
I cannot reproduce this issue. Can you attach the CMakeCache.txt from when you found this problem?
Of course. I've pasted it here[1] and added as an attachment to the bug report.
Ok, I can reproduce if I run cmake with no options. Can you try configuring with "cmake -DBUILD_CONFIG=mysql_release"? That should work fine. I think this just has to do with our handling of the Release vs. RelWithDebInfo configurations, I'll update the upstream ticket.
Yes, apparently -DBUILD_CONFIG=Release is the culprit. Everything builds fine with mysql_release. Thank you.
In my opinion the problem should not be hidden with some compiler adjustments, instead why not try to fix the actual cause ? E.g. following will silence the compiler very effectively:
=== modified file 'storage/tokudb/ft-index/ft/ft-ops.cc'
--- storage/tokudb/ft-index/ft/ft-ops.cc 2013-10-04 20:49:53 +0000
+++ storage/tokudb/ft-index/ft/ft-ops.cc 2014-02-04 18:04:06 +0000
@@ -2330,7 +2330,7 @@
while (index < (num_leafentries_before = bn->data_buffer.omt_size())) {
void* keyp = NULL;
uint32_t keylen = 0;
- LEAFENTRY leaf_entry;
+ LEAFENTRY leaf_entry = 0;
bn->data_buffer.fetch_klpair(index, &leaf_entry, &keylen, &keyp);
assert_zero(r);
ft_basement_node_gc_once(
That doesn't fix anything, that just hides the problem a different way. If execution were to reach the warned line with your change, it would segfault. The right thing to do is to keep it uninitialized at declaration, and to demonstrate (with asserts) to the compiler that execution cannot reach that line without initializing that variable. This was due to a typo and has already been fixed upstream.
Sent from my iPhone
The upstream (TokuDB) bug was closed as fixed quite some time ago, in March. So, I'm closing this one as fixed too. 'Fix Version' values are bogus, the fix should have made to the trees long before 10.0.14 and 5.5.40.
Please comment if it didn't happen and the bug still exists.
-Werror should be moved to debug targets or removed from /storage/tokudb/ft-index/cmake_modules/TokuSetupCompiler.cmake
It is a great debug tool, but should not be in a release.