Core dumped: Segmentation fault on PDO::__construct with SET NAMES init command #8111

kamioftea · 2018-01-22T14:07:50Z

HHVM Version

3.24.0
installed from hhvm_3.24.0-1~trusty_amd64.deb package

Operating System and Version

Ubuntu 14.04.5 LTS (GNU/Linux 3.13.0-139-generic x86_64)
MySQL Version: 5.7.21-log MySQL Community Server (GPL)

Standalone code, or other way to reproduce the problem

$dsn = ' mysql:host=localhost;port=3306;dbname=staging';
$user = '<username>';
$password = '<password>';
$options = [
    PDO::MYSQL_ATTR_INIT_COMMAND => "SET NAMES 'UTF8' COLLATE 'utf8_unicode_ci'"
];

$pdo = new PDO($dsn, $user, $password, $options);

Expected result

Connected PDO instance, or PDOException thrown

Actual result

HHVM crashes with a Seg Fault.

Notes:

If the PDO::MYSQL_ATTR_INIT_COMMAND is removed, the error does not occur.

Possibly related to #8050 since both involve setting the charset.

This was previously working on 3.18.5~trusty debian package. It currently works in php 5.6.

The text was updated successfully, but these errors were encountered:

I think we are running into this problem: facebook/hhvm#8111 We don't solve that problem, but we avoid it by specifying utf8 in a different fashion. I also took the opportunity to use the "TFB-database" hostname instead of the DBHOST environment variable because it's simpler that way. Here are the steps I took in a local TFB environment that make me think we're running into the same issue as that GitHub issue: - Run toolset/run-tests.py --mode verify --test hvm, see that it fails all tests with error messages that look like the application server simply isn't there - Enable logging in PHP/hhvm/deploy/config.hdf (basically copy the "Log" section over from config-debug.hdf), run the test again - Look at the log file it spit out, PHP/hhvm/error.log, notice messages like this: Core dumped: Segmentation fault Stack trace in /tmp/stacktrace.28653.log - /tmp is cleared by the TFB toolset each run, so I comment out that part of benchmarker.py that clears /tmp - Run the test again, look at the stacktrace file in /tmp, notice a stack trace referring to our implementation code like this: #0 PDO->__construct() called at [/home/techempower/FrameworkBenchmarks/frameworks/PHP/hhvm/once.php.inc:14] TechEmpower#1 Benchmark->setup_db() called at [/home/techempower/FrameworkBenchmarks/frameworks/PHP/hhvm/once.php.inc:31] TechEmpower#2 Benchmark->bench_db() called at [/home/techempower/FrameworkBenchmarks/frameworks/PHP/hhvm/db.php:10] TechEmpower#3 main() called at [/home/techempower/FrameworkBenchmarks/frameworks/PHP/hhvm/db.php:13] - Google a bit, come across a GitHub issue talking about a similar problem when they used "SET NAMES" - Comment the part of PHP/hhvm/once.php.inc that uses SET NAMES, run test again and it worked, except for fortunes which failed because of character encoding problems - Google for a different way to specify utf8 in the PDO constructor, try it again, all tests pass locally

…3220) I think we are running into this problem: facebook/hhvm#8111 We don't solve that problem, but we avoid it by specifying utf8 in a different fashion. I also took the opportunity to use the "TFB-database" hostname instead of the DBHOST environment variable because it's simpler that way. Here are the steps I took in a local TFB environment that make me think we're running into the same issue as that GitHub issue: - Run toolset/run-tests.py --mode verify --test hvm, see that it fails all tests with error messages that look like the application server simply isn't there - Enable logging in PHP/hhvm/deploy/config.hdf (basically copy the "Log" section over from config-debug.hdf), run the test again - Look at the log file it spit out, PHP/hhvm/error.log, notice messages like this: Core dumped: Segmentation fault Stack trace in /tmp/stacktrace.28653.log - /tmp is cleared by the TFB toolset each run, so I comment out that part of benchmarker.py that clears /tmp - Run the test again, look at the stacktrace file in /tmp, notice a stack trace referring to our implementation code like this: #0 PDO->__construct() called at [/home/techempower/FrameworkBenchmarks/frameworks/PHP/hhvm/once.php.inc:14] #1 Benchmark->setup_db() called at [/home/techempower/FrameworkBenchmarks/frameworks/PHP/hhvm/once.php.inc:31] #2 Benchmark->bench_db() called at [/home/techempower/FrameworkBenchmarks/frameworks/PHP/hhvm/db.php:10] #3 main() called at [/home/techempower/FrameworkBenchmarks/frameworks/PHP/hhvm/db.php:13] - Google a bit, come across a GitHub issue talking about a similar problem when they used "SET NAMES" - Comment the part of PHP/hhvm/once.php.inc that uses SET NAMES, run test again and it worked, except for fortunes which failed because of character encoding problems - Google for a different way to specify utf8 in the PDO constructor, try it again, all tests pass locally

csdougliss · 2018-01-31T13:49:10Z

Similar issue.

hhvm --version

HipHop VM 3.24.1 (rel)
Compiler: 1517332083_323251458
Repo schema: 73338ff742646a2481293e590010bd5f18e48cb9

Ubuntu 16.04.3, on Amazon c5.large server

Host: ip-xx
ProcessID: 17121
ThreadID: 139819342616320
ThreadPID: 17132
Name: unknown program
Type: Segmentation fault
Runtime: hhvm
Version: 1517332083_323251458
DebuggerCount: 0

Server: dev.xx
ThreadType: Web Request
Server_SERVER_NAME: dev.xx
URL: /

# 0  0000000000d77e96
# 1  0000000000fceae5
# 2  00007f2a562e0390
# 3  00000000023db097
# 4  0000000001fa9d9c
# 5  00000000023da2d3
# 6  00000000023d76e6
# 7  0000000001d59939
# 8  0000000001b71c6e
# 9  000000000131e52f
# 10 0000000001323fe6
# 11 00000000013245be
# 12 000000000125f571
# 13 000000000127460b
# 14 00000000023b88d1
# 15 000000000248d925
# 16 000000000248d7dc
# 17 000000000248d572
# 18 000000000248c1cf
# 19 000000000248042c
# 20 00000000024784fe
# 21 00000000011f8a63
# 22 0000000000d8cc3f
# 23 0000000000d8ce39
# 24 0000000000ff6876
# 25 00007f2a562d66ba
# 26 00007f2a503c541d

PHP Stacktrace:

#0  PDOStatement->execute() called at [/var/www/vhosts/magento-capistrano-dev/releases/20180131095743/lib/Zend/Db/Statement/Pdo.php:228]
#1  Zend_Db_Statement_Pdo->_execute() called at [/var/www/vhosts/magento-capistrano-dev/releases/20180131095743/lib/Varien/Db/Statement/Pdo/Mysql.php:110]
#2  Varien_Db_Statement_Pdo_Mysql->_execute() called at [/var/www/vhosts/magento-capistrano-dev/releases/20180131095743/app/code/core/Zend/Db/Statement.php:291]
#3  Zend_Db_Statement->execute() called at [/var/www/vhosts/magento-capistrano-dev/releases/20180131095743/lib/Zend/Db/Adapter/Abstract.php:480]
#4  Zend_Db_Adapter_Abstract->query() called at [/var/www/vhosts/magento-capistrano-dev/releases/20180131095743/lib/Zend/Db/Adapter/Pdo/Abstract.php:238]
#5  Zend_Db_Adapter_Pdo_Abstract->query() called at [/var/www/vhosts/magento-capistrano-dev/releases/20180131095743/lib/Varien/Db/Adapter/Pdo/Mysql.php:504]
#6  Varien_Db_Adapter_Pdo_Mysql->query() called at [/var/www/vhosts/magento-capistrano-dev/releases/20180131095743/app/code/core/Mage/Core/Model/Resource.php:179]
#7  Mage_Core_Model_Resource->_newConnection() called at [/var/www/vhosts/magento-capistrano-dev/releases/20180131095743/app/code/core/Mage/Core/Model/Resource.php:110]
#8  Mage_Core_Model_Resource->getConnection() called at [/var/www/vhosts/magento-capistrano-dev/releases/20180131095743/app/code/core/Mage/Core/Model/Resource/Db/Abstract.php:320]
#9  Mage_Core_Model_Resource_Db_Abstract->_getConnection() called at [/var/www/vhosts/magento-capistrano-dev/releases/20180131095743/app/code/core/Mage/Core/Model/Resource/Db/Abstract.php:350]
#10 Mage_Core_Model_Resource_Db_Abstract->_getWriteAdapter() called at [/var/www/vhosts/magento-capistrano-dev/releases/20180131095743/app/code/core/Mage/Core/Model/Resource/Db/Abstract.php:335]
#11 Mage_Core_Model_Resource_Db_Abstract->_getReadAdapter() called at [/var/www/vhosts/magento-capistrano-dev/releases/20180131095743/app/code/core/Mage/Core/Model/Resource/Cache.php:53]
#12 Mage_Core_Model_Resource_Cache->getAllOptions() called at [/var/www/vhosts/magento-capistrano-dev/releases/20180131095743/app/code/core/Mage/Core/Model/Cache.php:478]
#13 Mage_Core_Model_Cache->_initOptions() called at [/var/www/vhosts/magento-capistrano-dev/releases/20180131095743/app/code/core/Mage/Core/Model/Cache.php:520]
#14 Mage_Core_Model_Cache->canUse() called at [/var/www/vhosts/magento-capistrano-dev/releases/20180131095743/app/code/core/Mage/Core/Model/App.php:1202]
#15 Mage_Core_Model_App->useCache() called at [/var/www/vhosts/magento-capistrano-dev/releases/20180131095743/app/code/core/Mage/Core/Model/Config.php:417]
#16 Mage_Core_Model_Config->_canUseCacheForInit() called at [/var/www/vhosts/magento-capistrano-dev/releases/20180131095743/app/code/core/Mage/Core/Model/Config.php:297]
#17 Mage_Core_Model_Config->loadModulesCache() called at [/var/www/vhosts/magento-capistrano-dev/releases/20180131095743/app/code/core/Mage/Core/Model/App.php:424]
#18 Mage_Core_Model_App->_initModules() called at [/var/www/vhosts/magento-capistrano-dev/releases/20180131095743/app/code/core/Mage/Core/Model/App.php:354]
#19 Mage_Core_Model_App->run() called at [/var/www/vhosts/magento-capistrano-dev/releases/20180131095743/app/Mage.php:692]
#20 Mage::run() called at [/var/www/vhosts/magento-capistrano-dev/releases/20180131095743/index.php:109]

csdougliss · 2018-02-01T09:00:56Z

@fredemmott any updates on this? hhvm is now completely useless.

fredemmott · 2018-02-01T16:23:58Z

I'll follow up with our mysql team on https://github.com/facebook/mysql-5.6/pull/781/files

Once that's reviewed, this and #8050 are one of the next few things I want to look at.

fredemmott · 2018-02-01T18:31:42Z

#8050

csdougliss · 2018-02-06T10:25:42Z

@fredemmott when can we expect a release (specifically stable)?

fredemmott · 2018-02-06T16:26:07Z

It should be this week; I'm hoping to also get a fix for #8061 and hh_client hangs on mac in, but I'll push this out by itself if those end up delaying this more than a day or two.

…echEmpower#3220) I think we are running into this problem: facebook/hhvm#8111 We don't solve that problem, but we avoid it by specifying utf8 in a different fashion. I also took the opportunity to use the "TFB-database" hostname instead of the DBHOST environment variable because it's simpler that way. Here are the steps I took in a local TFB environment that make me think we're running into the same issue as that GitHub issue: - Run toolset/run-tests.py --mode verify --test hvm, see that it fails all tests with error messages that look like the application server simply isn't there - Enable logging in PHP/hhvm/deploy/config.hdf (basically copy the "Log" section over from config-debug.hdf), run the test again - Look at the log file it spit out, PHP/hhvm/error.log, notice messages like this: Core dumped: Segmentation fault Stack trace in /tmp/stacktrace.28653.log - /tmp is cleared by the TFB toolset each run, so I comment out that part of benchmarker.py that clears /tmp - Run the test again, look at the stacktrace file in /tmp, notice a stack trace referring to our implementation code like this: #0 PDO->__construct() called at [/home/techempower/FrameworkBenchmarks/frameworks/PHP/hhvm/once.php.inc:14] #1 Benchmark->setup_db() called at [/home/techempower/FrameworkBenchmarks/frameworks/PHP/hhvm/once.php.inc:31] #2 Benchmark->bench_db() called at [/home/techempower/FrameworkBenchmarks/frameworks/PHP/hhvm/db.php:10] #3 main() called at [/home/techempower/FrameworkBenchmarks/frameworks/PHP/hhvm/db.php:13] - Google a bit, come across a GitHub issue talking about a similar problem when they used "SET NAMES" - Comment the part of PHP/hhvm/once.php.inc that uses SET NAMES, run test again and it worked, except for fortunes which failed because of character encoding problems - Google for a different way to specify utf8 in the PDO constructor, try it again, all tests pass locally

fredemmott · 2018-02-07T19:27:26Z

https://hhvm.com/blog/2018/02/07/hhvm-3.24.2.html

csdougliss · 2018-03-27T11:19:47Z

@fredemmott Thank you

kamioftea changed the title ~~Core dumped: Segmentation fault on PDO::connect with SET NAMES init command~~ Core dumped: Segmentation fault on PDO::__construct with SET NAMES init command Jan 22, 2018

michaelhixson mentioned this issue Jan 30, 2018

Try to fix PHP/hhvm tests by working around an issue with SET NAMES TechEmpower/FrameworkBenchmarks#3220

Merged

fredemmott added the crash label Jan 30, 2018

fredemmott added the duplicate label Feb 1, 2018

fredemmott closed this as completed Feb 1, 2018

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Core dumped: Segmentation fault on PDO::__construct with SET NAMES init command #8111

Core dumped: Segmentation fault on PDO::__construct with SET NAMES init command #8111

kamioftea commented Jan 22, 2018 •

edited

Loading

csdougliss commented Jan 31, 2018

Uh oh!

csdougliss commented Feb 1, 2018

Uh oh!

fredemmott commented Feb 1, 2018

Uh oh!

fredemmott commented Feb 1, 2018

Uh oh!

csdougliss commented Feb 6, 2018

Uh oh!

fredemmott commented Feb 6, 2018

Uh oh!

fredemmott commented Feb 7, 2018

Uh oh!

csdougliss commented Mar 27, 2018

Uh oh!

Core dumped: Segmentation fault on PDO::__construct with SET NAMES init command #8111

Core dumped: Segmentation fault on PDO::__construct with SET NAMES init command #8111

Comments

kamioftea commented Jan 22, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

HHVM Version

Operating System and Version

Standalone code, or other way to reproduce the problem

Expected result

Actual result

Notes:

csdougliss commented Jan 31, 2018

Uh oh!

csdougliss commented Feb 1, 2018

Uh oh!

fredemmott commented Feb 1, 2018

Uh oh!

fredemmott commented Feb 1, 2018

Uh oh!

csdougliss commented Feb 6, 2018

Uh oh!

fredemmott commented Feb 6, 2018

Uh oh!

fredemmott commented Feb 7, 2018

Uh oh!

csdougliss commented Mar 27, 2018

Uh oh!

kamioftea commented Jan 22, 2018 •

edited

Loading