Bug #22232332: SAVING TEXT FIELD TO TEXT VARIABLE IN A

               PROCEDURE RESULTS IN GARBAGE BYTES

Issue:
-----
This problem occurs under the following conditions:

a) Stored procedure has a variable is declared as TEXT/BLOB.
b) Data is copied into the the variable using the
   SELECT...INTO syntax from a TEXT/BLOB column.

Data corruption can occur in such cases.

SOLUTION:
---------
The blob type does not allocate space for the string to be
stored. Instead it contains a pointer to the source string.
Since the source is deallocated immediately after the
select statement, this can cause data corruption.

As part of the fix for Bug #21143080, when the source was
part of the table's write-set, blob would allocate the
neccessary space. But this fix missed the possibility that,
as in the above case, the target might be a variable.

The fix will add the copy_blobs check that was removed by
the earlier fix.

sql/field_conv.cc

@@ -1,4 +1,4 @@
-/* Copyright (c) 2000, 2015, Oracle and/or its affiliates. All rights reserved.
+/* Copyright (c) 2000, 2016, Oracle and/or its affiliates. All rights reserved.
 
    This program is free software; you can redistribute it and/or modify
    it under the terms of the GNU General Public License as published by
@@ -826,7 +826,12 @@ int field_conv(Field *to,Field *from)
     Field_blob *blob=(Field_blob*) to;
     from->val_str(&blob->value);
 
-    if (!blob->value.is_alloced() && from->is_updatable())
+    /*
+      Copy value if copy_blobs is set, or source is part of the table's
+      writeset.
+    */
+    if (to->table->copy_blobs ||
+        (!blob->value.is_alloced() && from->is_updatable()))
       blob->value.copy();
 
     return blob->store(blob->value.ptr(),blob->value.length(),from->charset());