Description:
------------
We experienced some strange behaviour when using "INSERT INTO ... select
? ... union select ? ..."

Some bound variables have been inserted, but were truncated somewhere
within the strings.

We have created a simple test script which only selects and returns the
contents we bound. 
With "SELECT ? UNION SELECT ?" and 2 bound variables we can see, that
the contents of the variables are not the same when reading back from
db.

With the code below we even managed to get a segmentation fault.

Reproduce code:
---------------
<?php
$db = new mysqli($hostname, $username, $password, $dbname);

$foo = "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ";
$foo2 = "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ";
$stmt = $db->prepare("SELECT CAST('x' as CHAR) X UNION SELECT CAST(? AS
CHAR(20)) UNION SELECT CAST(? as CHAR(50))");
$stmt->bind_param("ss", $foo, $foo2);
$stmt->bind_result($bar);
$stmt->execute();
$stmt->fetch(); // first to fetch "foo"
echo("F1: $bar vs $foo (".strlen($bar)." vs. ".strlen($foo).")\n");
$stmt->fetch(); // second to fetch $foo
echo("F2: $bar vs $foo (".strlen($bar)." vs. ".strlen($foo).")\n");
$stmt->fetch(); // second to fetch casted $foo
echo("F3: $bar vs $foo2 (".strlen($bar)." vs. ".strlen($foo2).")\n");
$stmt->free_result();
?>

Expected result:
----------------
Returned variable $bar should contain contents of 'x', $foo, $foo2:

F1: x vs 0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ (1 vs. 36)
F2: 0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ vs
0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ (36 vs. 36)
F3: 0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ vs
0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ (36 vs. 36)

Actual result:
--------------
F1: x vs 0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ (1 vs. 36)
F2: 0123 vs 0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ (4 vs. 36)
Segmentation fault

With gdb:

F1: x vs 0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ (1 vs. 36)
F2: 0123 vs 0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ (4 vs. 36)
Program received signal SIGSEGV, Segmentation fault.
mysqli_stmt_fetch_libmysql (ht=0, return_value=0x86f9288,
return_value_ptr=0x0, this_ptr=0x86f8fb8, return_value_used=0) at
/usr/local/src/php5.3-200805151430/ext/mysqli/mysqli_api.c:837
837                             if (Z_TYPE_P(stmt->result.vars[i]) ==
IS_STRING) {
(gdb) where
#0  mysqli_stmt_fetch_libmysql (ht=0, return_value=0x86f9288,
return_value_ptr=0x0, this_ptr=0x86f8fb8, return_value_used=0) at
/usr/local/src/php5.3-200805151430/ext/mysqli/mysqli_api.c:837
#1  0x082e92bd in zend_do_fcall_common_helper_SPEC
(execute_data=0x8729f38) at
/usr/local/src/php5.3-200805151430/Zend/zend_vm_execute.h:194
#2  0x082daa77 in execute (op_array=0x86f843c) at
/usr/local/src/php5.3-200805151430/Zend/zend_vm_execute.h:96
#3  0x082ba797 in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /usr/local/src/php5.3-200805151430/Zend/zend.c:1195
#4  0x0826ad8c in php_execute_script (primary_file=0xbfd034f4) at
/usr/local/src/php5.3-200805151430/main/main.c:2077
#5  0x083437f6 in main (argc=2, argv=0xbfd03684) at
/usr/local/src/php5.3-200805151430/sapi/cli/php_cli.c:1139

Verified - there are issues with UNION. I'll play with it. Andrey, wait
for my test code.

This looks like a libmysql only issue. Pumuckel, if possible give
mysqlnd a test with your code.

Client API version: mysqlnd 5.0.4-dev - 080501 - $Revision: 1.3.2.15

With this version and this script we do not get segmentation fault.

But I have another script where you won't get expected results:

[...]
$foo = "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ";
$foo2 = "foo238964283467254725472725347254757652734522374628346246";
$stmt = $db->prepare("SELECT ? UNION SELECT ?");
$stmt->bind_param("ss", $foo, $foo2);
$stmt->bind_result($bar);
$stmt->execute();
$stmt->fetch(); // first to fetch "foo"
echo("F1: $bar vs $foo (should be equal)\n");
$stmt->fetch(); // second to fetch $foo
echo("F2: $bar vs $foo2 (should be equal)\n");
$stmt->free_result();
[...]

 Mike

Can't be fixed, as libmysql is faulty. Metadata changes when using
UNIONS, mysqlnd handles it, but libmysql doesn't well. If you have
SELECT with UNION and different metadata - then use mysqlnd.

Hi Andrey,

I personally can live with that - since we are using 5.3 & mysqlnd
successfully in production. I'm going to close this bug. Thank you
anyway.