Seg. faults at login process (TYPO3) #2377
Comments
|
Thanks for opening this issue, and for attaching the stack traces. Feel free to dig deeper into this (you, or anyone else) and send us a PR; we'd appreciate it. |
|
Hi @alexmalyshev, you're welcome. |
|
@khaefeli do you mind sharing the version of libmysqlclient you're using? |
|
@Aatch sure: libmysqlclient18:amd64 - 5.5.37-0+wheezy1 hope it helps. |
|
is there any hope for us? |
|
@Aatch & @r3wt regarding the refernce #2921 - I dont think it's related to this bug. anyway: but for sure, we should get a usable error message instead of a seg. fault / crash @ptarjan is there any chance for a higher priority here? |
|
@khaefeli This will be fixed in no time if you got a small reproduction case. :P |
|
@SiebelsTim g
|
|
@khaefeli |
|
@SiebelsTim I tried to break it down to a small code snippet. But as I wrote in #2377 (comment) I'm sysadmin and no php dev ;-) var_dump of $this->statement with php5-fpm when it's called in the TYPO3 login process: HHVM: |
|
It seems that the problem is caused by mysql datatype longtext. CREATE TABLE `be_sessions` (
`ses_id` varchar(32) NOT NULL DEFAULT '',
`ses_data` longtext,
PRIMARY KEY (`ses_id`),
) ENGINE=InnoDB DEFAULT CHARSET=utf8;Here is a test script provided. When you change the data type of the above given attribute ses_data to TEXT it works fine. <?php
$mysqli = new mysqli("localhost", "username", "password" "database");
if (mysqli_connect_errno()) {
printf("Connect failed: %s\n", mysqli_connect_error());
exit();
}
$query = "SELECT ses_id, ses_data FROM be_sessions";
if ($stmt = $mysqli->prepare($query)) {
$stmt->execute();
$stmt->bind_result($ses_id, $ses_data);
while ($stmt->fetch()) {
printf ("%s (%s)\n", $ses_id, $ses_data);
}
$stmt->close();
}
$mysqli->close();
?>Other data types it works not with: longblob, longtext Contribution to @beachmachine, @rewi, @sascha-egerer |
|
Problem seems to be on libmysqlclient, the following test fails either on hhvm and on vanilla php: <?php
/*
* Create a table with a LONGTEXT and pull in some data
*/
$mysqli = new mysqli("127.0.0.1", "root", "root", "test_hhvm");
if ($mysqli->connect_errno) {
echo "Failed to connect to MySQL: (" . $mysqli->connect_errno . ") " . $mysqli->connect_error;
}
if (!$mysqli->query("DROP TABLE IF EXISTS test") || !$mysqli->query("CREATE TABLE test(label LONGTEXT)")) {
echo "Table creation failed: (" . $mysqli->errno . ") " . $mysqli->error;
}
$mysqli->query('INSERT INTO test(label) values ("test")');
/*
* Hit the bug, expect a segfault on hhvm
*/
$stmt = $mysqli->prepare("SELECT label FROM test");
$stmt->execute();
$stmt->bind_result($label);
while($stmt->fetch()) {
echo "$label" . PHP_EOL;
}
$stmt->close();
$mysqli->close();
?>Difference is hhvm dies on a segmentation fault and vanilla php tries to allocate all the system memory so a fatal error is thrown. HHVM output PHP output Tested on Ubuntu 14.04 64bits |
|
@jaguerra What libmysqlclient and hhvm version do you have? I use Ubuntu 14.04, mysql 5.5.37 and hhvm 3.1.0 |
|
@SiebelsTim Using hhvm-nightly |
|
@SiebelsTim Also breaks on HHVM 3.1.0 |
|
yep. my column it was failing on was a longtext |
|
@jaguerra I also tried with 3.2.0. It's not failing for me. However I can reproduce this in a virtual machine. |
|
@jaguerra I get a segfault on my host machine as well when I am low on memory. Are we running out of memory? How much memory do you have? I have 4GB. |
|
It's probably this call that fails, because This might be a mysql bug (regarding php fails as well) Reproduce like this:
|
PHP calls STMT_ATTR_UPDATE_MAX_LENGTH in bind_result This results in LONGTEXTs being variable length rather than 4GB Fixes facebook#2377 Probably Fixes facebook#2921
|
There's a fix being reviewed/tested internally; FB: D1407344 |
|
I can confirm the bugfix. It working with HipHop VM 3.2.0-dev+2014.07.17 (rel) |
Hi,
I've the following setup:
loginSecurityLevel' => 'rsa'
loginSecurityLevel' => 'normal' (both not working)
I try to login into the TYPO3 6.2 backend and hhvm crashes.
Credentials are correct - frontend is working well.
HHVM stacktrace
PHP Stacktrace:
reproduction case in comment #2377 (comment)
The text was updated successfully, but these errors were encountered: