#45161 [NEW]: reusing a curl handle leaks memory
From: humbads at alum dot mit dot edu
Operating system: FreeBSD 6.2, Windows XP SP3
PHP version: 5.2.6
PHP Bug Type: cURL related
Bug description: reusing a curl handle leaks memory
Description:
Reusing a curl handle for multiple requests leaks memory. It leaks about
100 bytes per request. This is a problem when making a large number of
requests using the same handle. Libcurl documentation says to always reuse
the handle when possible in order to reuse connections. The bug occurs on
Windows XP/IIS and Apache/FreeBSD 6.2.
Reproduce code:
---
?php
// Reuse curl handle memory leak test
$ch = curl_init();
$startmem = memory_get_usage();
for($i = 0; $i 100; $i++) {
$fp = fopen('/dev/null', w);
curl_setopt($ch, CURLOPT_URL,
'http://debug.atensoftware.com/r.php?echo='.rand());
curl_setopt($ch, CURLOPT_FILE, $fp);
curl_exec($ch);
fclose($fp);
unset($fp);
print $i-mem: .(memory_get_usage() - $startmem). bytes\n;
}
?
Expected result:
The memory usage should not increase after each request.
--
Edit bug report at http://bugs.php.net/?id=45161edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=45161r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=45161r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=45161r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=45161r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=45161r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=45161r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=45161r=needscript
Try newer version:http://bugs.php.net/fix.php?id=45161r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=45161r=support
Expected behavior:http://bugs.php.net/fix.php?id=45161r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=45161r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=45161r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=45161r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45161r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=45161r=dst
IIS Stability:http://bugs.php.net/fix.php?id=45161r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=45161r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=45161r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=45161r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=45161r=mysqlcfg
#45161 [Opn]: humbads
ID: 45161
User updated by: humbads at alum dot mit dot edu
-Summary: reusing a curl handle leaks memory
Reported By: humbads at alum dot mit dot edu
Status: Open
Bug Type: cURL related
Operating System: FreeBSD 6.2, Windows XP SP3
PHP Version: 5.2.6
New Comment:
Below is the r.php script. When testing this bug report, please use
this script (or some other URL) so my poor server does not get
hammered.
?php
// This script runs a variable amount of time
// and generates a variable amount of data
// Output a random number of blank space
$s = microtime(true);
$m = rand(100,200);
$bytes = 0;
for($i = 0; $i $m; $i++) {
$message = \n;
print $message;
$bytes += strlen($message);
usleep(10);
}
// Print time taken and the value of the echo parameter
print isset($_REQUEST['echo']) ? 'echo: '.$_REQUEST['echo'].' ' : ;
print $bytes.' bytes ';
print in ;
print round(microtime(true) - $s, 4). seconds;
exit();
?
Previous Comments:
[2008-06-03 15:04:41] humbads at alum dot mit dot edu
Description:
Reusing a curl handle for multiple requests leaks memory. It leaks
about 100 bytes per request. This is a problem when making a large
number of requests using the same handle. Libcurl documentation says to
always reuse the handle when possible in order to reuse connections.
The bug occurs on Windows XP/IIS and Apache/FreeBSD 6.2.
Reproduce code:
---
?php
// Reuse curl handle memory leak test
$ch = curl_init();
$startmem = memory_get_usage();
for($i = 0; $i 100; $i++) {
$fp = fopen('/dev/null', w);
curl_setopt($ch, CURLOPT_URL,
'http://debug.atensoftware.com/r.php?echo='.rand());
curl_setopt($ch, CURLOPT_FILE, $fp);
curl_exec($ch);
fclose($fp);
unset($fp);
print $i-mem: .(memory_get_usage() - $startmem). bytes\n;
}
?
Expected result:
The memory usage should not increase after each request.
--
Edit this bug report at http://bugs.php.net/?id=45161edit=1
#45161 [Opn]: Reusing a curl handle leaks memory
ID: 45161
User updated by: humbads at alum dot mit dot edu
Reported By: humbads at alum dot mit dot edu
Status: Open
Bug Type: cURL related
Operating System: FreeBSD 6.2, Windows XP SP3
PHP Version: 5.2.6
New Comment:
I did some more investigation, and found that this is not really a leak
as much as it is runaway memory usage. PHP does indeed free the memory
eventually.
The problem is in interface.c curl_setopt under CURLOPT_URL. The
function is making a copy of the string parameter, in this case, the
URL, and saving that to the to_free list. That list is not freed
until sometime later, so repeatedly setting CURLOPT_URL on the same
handle will keep using more memory. In the sample code I posted, the
memory only increases during the curl_setopt CURLOPT_URL function call.
This is just an inefficient design of the PHP curl handle. One way
around it is for the code to maintain only one copied string for each
CURLOPT string option. If the same CURLOPT string option is set again,
it should free the previously created string, and create a new one.
At the PHP level, the only workaround for now is to periodically close
the handle and then create a new one with curl_init. This seems to cap
the memory usage.
Previous Comments:
[2008-06-03 16:07:04] humbads at alum dot mit dot edu
Below is the r.php script. When testing this bug report, please use
this script (or some other URL) so my poor server does not get
hammered.
?php
// This script runs a variable amount of time
// and generates a variable amount of data
// Output a random number of blank space
$s = microtime(true);
$m = rand(100,200);
$bytes = 0;
for($i = 0; $i $m; $i++) {
$message = \n;
print $message;
$bytes += strlen($message);
usleep(10);
}
// Print time taken and the value of the echo parameter
print isset($_REQUEST['echo']) ? 'echo: '.$_REQUEST['echo'].' ' : ;
print $bytes.' bytes ';
print in ;
print round(microtime(true) - $s, 4). seconds;
exit();
?
[2008-06-03 15:04:41] humbads at alum dot mit dot edu
Description:
Reusing a curl handle for multiple requests leaks memory. It leaks
about 100 bytes per request. This is a problem when making a large
number of requests using the same handle. Libcurl documentation says to
always reuse the handle when possible in order to reuse connections.
The bug occurs on Windows XP/IIS and Apache/FreeBSD 6.2.
Reproduce code:
---
?php
// Reuse curl handle memory leak test
$ch = curl_init();
$startmem = memory_get_usage();
for($i = 0; $i 100; $i++) {
$fp = fopen('/dev/null', w);
curl_setopt($ch, CURLOPT_URL,
'http://debug.atensoftware.com/r.php?echo='.rand());
curl_setopt($ch, CURLOPT_FILE, $fp);
curl_exec($ch);
fclose($fp);
unset($fp);
print $i-mem: .(memory_get_usage() - $startmem). bytes\n;
}
?
Expected result:
The memory usage should not increase after each request.
--
Edit this bug report at http://bugs.php.net/?id=45161edit=1
#35552 [Csd]: access violation on any invalid odbc query
ID: 35552
User updated by: humbads at alum dot mit dot edu
Reported By: humbads at alum dot mit dot edu
Status: Closed
Bug Type: PDO related
Operating System: Windows XP SP2
PHP Version: 5CVS-2005-12-14 (snap)
Assigned To: wez
New Comment:
Confirmed fix in 5.1.4. Note, you have to print $db-errorInfo() to
see the actual error message.
Previous Comments:
[2006-04-30 00:52:52] [EMAIL PROTECTED]
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Fix will be in 5.1.4
[2005-12-23 12:55:25] markus at fischer dot name
I'm expiriencing the same behaviour with pdo_odbc and the M$ Access
Driver. I can verify this with this snapshot:
php5.1-win32-200512231130.zip
My testcase is:
$sDsn = 'odbc:driver={Microsoft Access Driver
(*.mdb)};Dbq=beispieldatenbank.mdb;';
$oPdo = new PDO($sDsn);
$oPdo-query('SELEC * FROM ADDRESSES');
[2005-12-14 09:11:23] humbads at alum dot mit dot edu
This one still gives an exception, but it is different from before.
The call stack is one thousand deep. I'm using snapshot
php5.1-win32-200512140730.zip.
Unhandled exception at 0x005f1164 (php_pdo_odbc.dll) in php-cgi.exe:
0xC005: Access violation writing location 0x0012.
php_pdo_odbc.dll!pdo_odbc_error(_pdo_dbh_t * dbh=0x0071e338,
_pdo_stmt_t * stmt=0x0071e850, void * statement=0x, char *
what=0x005f3194, const char * file=0x005f31cc, int line=202, void * * *
tsrm_ls=0x00324090) Line 101 + 0x7 C
php_pdo_odbc.dll!odbc_handle_preparer(_pdo_dbh_t * dbh=0x0071e338,
const char * sql=0x0071e510, long sql_len=13, _pdo_stmt_t *
stmt=0x0071e850, _zval_struct * driver_options=0x, void * * *
tsrm_ls=0x00324090) Line 202 + 0x20C
php_pdo.dll!zif_PDO_query(int ht=1, _zval_struct *
return_value=0x0071e4a0, _zval_struct * * return_value_ptr=0x,
_zval_struct * this_ptr=0x0071e510, int return_value_used=0, void * * *
tsrm_ls=0x000d) Line 992 + 0x2fC
php5ts.dll!10018d52()
php5ts.dll!100b4b32()
php5ts.dll!10018765()
php5ts.dll!100186e5()
php5ts.dll!10008d52()
... ... REPEATS MANY TIMES
php5ts.dll!100a7b94()
php5ts.dll!10002e2d()
msvcrt.dll!_free() + 0xc3
[EMAIL PROTECTED]() + 0x130
00300030()
[EMAIL PROTECTED]() + 0x25
odbc32.dll!_MPLeaveCriticalSection() + 0x17
0012fa34()
[EMAIL PROTECTED]() + 0x96
php_pdo_odbc.dll!odbc_handle_preparer(_pdo_dbh_t * dbh=0x0071e338,
const char * sql=0x0071e510, long sql_len=13, _pdo_stmt_t *
stmt=0x0071e850, _zval_struct * driver_options=0x, void * * *
tsrm_ls=0x00324090) Line 202 + 0x20C
php_pdo.dll!zif_PDO_query(int ht=1, _zval_struct *
return_value=0x0071e4a0, _zval_struct * * return_value_ptr=0x,
_zval_struct * this_ptr=0x0071e510, int return_value_used=0, void * * *
tsrm_ls=0x000d) Line 992 + 0x2fC
php5ts.dll!10018d52()
php5ts.dll!100b4b32()
php5ts.dll!10018765()
php5ts.dll!100186e5()
php5ts.dll!10008d52()
[2005-12-14 06:02:19] [EMAIL PROTECTED]
I made an adjustment to the way that we pull out the error information;
I'm not sure that it will have resolved this particular issue, but it's
worth trying it out while you're checking to see if #35620 is fixed.
[2005-12-05 18:54:18] humbads at alum dot mit dot edu
This is with the latest snapshot release:
php5.1-win32-200512051530.zip
Here is the stack trace:
[EMAIL PROTECTED]() + 0x6a
[EMAIL PROTECTED]() + 0x120
[EMAIL PROTECTED]() + 0xaa
php_pdo_odbc.dll!pdo_odbc_error(_pdo_dbh_t * dbh=0x0071e6c8,
_pdo_stmt_t * stmt=0x0071ebb8, void * statement=0x, char *
what=0x005f3194, const char * file=0x005f31cc, int line=175, void * * *
tsrm_ls=0x00323f68) Line 82C
php_pdo_odbc.dll!odbc_handle_preparer(_pdo_dbh_t * dbh=0x0071e6c8,
const char * sql=0x0071e878, long sql_len=13, _pdo_stmt_t *
stmt=0x0071ebb8, _zval_struct * driver_options=0x, void * * *
tsrm_ls=0x00323f68) Line 175 + 0x20C
php_pdo.dll!zif_PDO_query(int ht=1, _zval_struct *
return_value=0x0071e808, _zval_struct * * return_value_ptr=0x,
_zval_struct * this_ptr=0x0071e878, int return_value_used=0, void * * *
tsrm_ls=0x000d) Line 992 + 0x2fC
#37335 [NEW]: zip_entry_read handling of null byte
From: humbads at alum dot mit dot edu Operating system: FreeBSD 4.7 RELEASE PHP version: 4.4.2 PHP Bug Type: ZZiplib Related Bug description: zip_entry_read handling of null byte Description: When using zip_entry_read to decompress a zip entry containing a null byte, the function only returns data up to the first null byte in the decompressed file. Bug does not occur on PHP 5.1.2 for Windows XP. Reproduce code: --- ?php dl(zip.so); // test.zip contains one file with a null byte in the middle $zipfile = zip_open(onejpg.zip); $zipentry = zip_read($zipfile); zip_entry_open($zipfile, $zipentry); $content = zip_entry_read($zipentry, zip_entry_filesize($zipentry)); print filesize: .filesize(onejpg.jpg).\n; print variable: ; var_dump($content); zip_entry_close($zipentry); zip_close($zipfile); ? Expected result: var_dump should show a string with the same length as the file size. To download onejpg.zip and onejpg.jpg, go here: http://www.somacon.com/p258.php http://www.somacon.com/p257.php Actual result: -- var_dump only shows length 4, which is the length up to the null byte. -- Edit bug report at http://bugs.php.net/?id=37335edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=37335r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=37335r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=37335r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=37335r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=37335r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=37335r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=37335r=needscript Try newer version:http://bugs.php.net/fix.php?id=37335r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=37335r=support Expected behavior:http://bugs.php.net/fix.php?id=37335r=notwrong Not enough info: http://bugs.php.net/fix.php?id=37335r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=37335r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=37335r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=37335r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=37335r=dst IIS Stability:http://bugs.php.net/fix.php?id=37335r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=37335r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=37335r=float No Zend Extensions: http://bugs.php.net/fix.php?id=37335r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=37335r=mysqlcfg
#37335 [Bgs-Opn]: zip_entry_read handling of null byte
ID: 37335 User updated by: humbads at alum dot mit dot edu Reported By: humbads at alum dot mit dot edu -Status: Bogus +Status: Open Bug Type: ZZiplib Related Operating System: FreeBSD 4.7 RELEASE PHP Version: 4.4.2 Assigned To: pajoye New Comment: The version of pecl-zip seems to be 1.2.1 based on the Makefile in the ports directory. I'd prefer not to upgrade to PHP 5.1 at this time, and I am extracting the zip contents into a database, so it has to happen in memory. I'll try the latest PECL zip package. Previous Comments: [2006-05-05 22:28:47] [EMAIL PROTECTED] Thank you for taking the time to report a problem with PHP. Unfortunately you are not using a current version of PHP -- the problem might already be fixed. Please download a new PHP version from http://www.php.net/downloads.php If you are able to reproduce the bug with one of the latest versions of PHP, please change the PHP version on this bug report to the version you tested and change the status back to Open. Again, thank you for your continued support of PHP. I cannot reproduce your problen with the latest Zip release. Your zip works with php 4.4 and 5.1.x. I can read and extract the image. I also recommend to use the new API with php 5.1+. It is more efficient and you can extract directly to the disk. You can fetch the latest release from the PECL site: http://pecl.php.net/package/zip If you still have troubles, please reopen this bug. [2006-05-05 21:44:33] [EMAIL PROTECTED] Sorry for the previous comment, a wrong snippet was selected. My question is only: which version(s) of the zip package do you use? [2006-05-05 21:43:43] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to Open. Thank you for helping us make PHP better. Which version(s) of the zip package do you use? [2006-05-05 21:15:37] humbads at alum dot mit dot edu Description: When using zip_entry_read to decompress a zip entry containing a null byte, the function only returns data up to the first null byte in the decompressed file. Bug does not occur on PHP 5.1.2 for Windows XP. Reproduce code: --- ?php dl(zip.so); // test.zip contains one file with a null byte in the middle $zipfile = zip_open(onejpg.zip); $zipentry = zip_read($zipfile); zip_entry_open($zipfile, $zipentry); $content = zip_entry_read($zipentry, zip_entry_filesize($zipentry)); print filesize: .filesize(onejpg.jpg).\n; print variable: ; var_dump($content); zip_entry_close($zipentry); zip_close($zipfile); ? Expected result: var_dump should show a string with the same length as the file size. To download onejpg.zip and onejpg.jpg, go here: http://www.somacon.com/p258.php http://www.somacon.com/p257.php Actual result: -- var_dump only shows length 4, which is the length up to the null byte. -- Edit this bug report at http://bugs.php.net/?id=37335edit=1
#37335 [Opn-Bgs]: zip_entry_read handling of null byte
ID: 37335 User updated by: humbads at alum dot mit dot edu Reported By: humbads at alum dot mit dot edu -Status: Open +Status: Bogus Bug Type: ZZiplib Related Operating System: FreeBSD 4.7 RELEASE PHP Version: 4.4.2 Assigned To: pajoye New Comment: Just noticed the changelog for pecl-zip, and this bug has been fixed since version 1.2.3 -- #7214, use binary safe string as return value. Sorry for the trouble. Previous Comments: [2006-05-06 02:15:20] humbads at alum dot mit dot edu The version of pecl-zip seems to be 1.2.1 based on the Makefile in the ports directory. I'd prefer not to upgrade to PHP 5.1 at this time, and I am extracting the zip contents into a database, so it has to happen in memory. I'll try the latest PECL zip package. [2006-05-05 22:28:47] [EMAIL PROTECTED] Thank you for taking the time to report a problem with PHP. Unfortunately you are not using a current version of PHP -- the problem might already be fixed. Please download a new PHP version from http://www.php.net/downloads.php If you are able to reproduce the bug with one of the latest versions of PHP, please change the PHP version on this bug report to the version you tested and change the status back to Open. Again, thank you for your continued support of PHP. I cannot reproduce your problen with the latest Zip release. Your zip works with php 4.4 and 5.1.x. I can read and extract the image. I also recommend to use the new API with php 5.1+. It is more efficient and you can extract directly to the disk. You can fetch the latest release from the PECL site: http://pecl.php.net/package/zip If you still have troubles, please reopen this bug. [2006-05-05 21:44:33] [EMAIL PROTECTED] Sorry for the previous comment, a wrong snippet was selected. My question is only: which version(s) of the zip package do you use? [2006-05-05 21:43:43] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to Open. Thank you for helping us make PHP better. Which version(s) of the zip package do you use? [2006-05-05 21:15:37] humbads at alum dot mit dot edu Description: When using zip_entry_read to decompress a zip entry containing a null byte, the function only returns data up to the first null byte in the decompressed file. Bug does not occur on PHP 5.1.2 for Windows XP. Reproduce code: --- ?php dl(zip.so); // test.zip contains one file with a null byte in the middle $zipfile = zip_open(onejpg.zip); $zipentry = zip_read($zipfile); zip_entry_open($zipfile, $zipentry); $content = zip_entry_read($zipentry, zip_entry_filesize($zipentry)); print filesize: .filesize(onejpg.jpg).\n; print variable: ; var_dump($content); zip_entry_close($zipentry); zip_close($zipfile); ? Expected result: var_dump should show a string with the same length as the file size. To download onejpg.zip and onejpg.jpg, go here: http://www.somacon.com/p258.php http://www.somacon.com/p257.php Actual result: -- var_dump only shows length 4, which is the length up to the null byte. -- Edit this bug report at http://bugs.php.net/?id=37335edit=1
#37335 [Bgs]: zip_entry_read handling of null byte
ID: 37335 User updated by: humbads at alum dot mit dot edu Reported By: humbads at alum dot mit dot edu Status: Bogus Bug Type: ZZiplib Related Operating System: FreeBSD 4.7 RELEASE PHP Version: 4.4.2 Assigned To: pajoye New Comment: Confirmed. After updating zip.so to the latest 1.3.1 by running pkg_add for gnu-autoconf, gnu-automake, and gnu-libtool, adding a symbolic link autoconf to /usr/local/bin/autoconf529, and then running pear install http://pecl.php.net/get/zip-1.3.1.tgz;, the error went away. Previous Comments: [2006-05-06 02:17:59] humbads at alum dot mit dot edu Just noticed the changelog for pecl-zip, and this bug has been fixed since version 1.2.3 -- #7214, use binary safe string as return value. Sorry for the trouble. [2006-05-06 02:15:20] humbads at alum dot mit dot edu The version of pecl-zip seems to be 1.2.1 based on the Makefile in the ports directory. I'd prefer not to upgrade to PHP 5.1 at this time, and I am extracting the zip contents into a database, so it has to happen in memory. I'll try the latest PECL zip package. [2006-05-05 22:28:47] [EMAIL PROTECTED] Thank you for taking the time to report a problem with PHP. Unfortunately you are not using a current version of PHP -- the problem might already be fixed. Please download a new PHP version from http://www.php.net/downloads.php If you are able to reproduce the bug with one of the latest versions of PHP, please change the PHP version on this bug report to the version you tested and change the status back to Open. Again, thank you for your continued support of PHP. I cannot reproduce your problen with the latest Zip release. Your zip works with php 4.4 and 5.1.x. I can read and extract the image. I also recommend to use the new API with php 5.1+. It is more efficient and you can extract directly to the disk. You can fetch the latest release from the PECL site: http://pecl.php.net/package/zip If you still have troubles, please reopen this bug. [2006-05-05 21:44:33] [EMAIL PROTECTED] Sorry for the previous comment, a wrong snippet was selected. My question is only: which version(s) of the zip package do you use? [2006-05-05 21:43:43] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to Open. Thank you for helping us make PHP better. Which version(s) of the zip package do you use? The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/37335 -- Edit this bug report at http://bugs.php.net/?id=37335edit=1
#35552 [Fbk-Opn]: access violation on any invalid odbc query
ID: 35552 User updated by: humbads at alum dot mit dot edu Reported By: humbads at alum dot mit dot edu -Status: Feedback +Status: Open Bug Type: PDO related Operating System: Windows XP SP2 -PHP Version: 5CVS-2005-12-05 (snap) +PHP Version: 5CVS-2005-12-14 (snap) Assigned To: wez New Comment: This one still gives an exception, but it is different from before. The call stack is one thousand deep. I'm using snapshot php5.1-win32-200512140730.zip. Unhandled exception at 0x005f1164 (php_pdo_odbc.dll) in php-cgi.exe: 0xC005: Access violation writing location 0x0012. php_pdo_odbc.dll!pdo_odbc_error(_pdo_dbh_t * dbh=0x0071e338, _pdo_stmt_t * stmt=0x0071e850, void * statement=0x, char * what=0x005f3194, const char * file=0x005f31cc, int line=202, void * * * tsrm_ls=0x00324090) Line 101 + 0x7 C php_pdo_odbc.dll!odbc_handle_preparer(_pdo_dbh_t * dbh=0x0071e338, const char * sql=0x0071e510, long sql_len=13, _pdo_stmt_t * stmt=0x0071e850, _zval_struct * driver_options=0x, void * * * tsrm_ls=0x00324090) Line 202 + 0x20C php_pdo.dll!zif_PDO_query(int ht=1, _zval_struct * return_value=0x0071e4a0, _zval_struct * * return_value_ptr=0x, _zval_struct * this_ptr=0x0071e510, int return_value_used=0, void * * * tsrm_ls=0x000d) Line 992 + 0x2fC php5ts.dll!10018d52() php5ts.dll!100b4b32() php5ts.dll!10018765() php5ts.dll!100186e5() php5ts.dll!10008d52() ... ... REPEATS MANY TIMES php5ts.dll!100a7b94() php5ts.dll!10002e2d() msvcrt.dll!_free() + 0xc3 [EMAIL PROTECTED]() + 0x130 00300030() [EMAIL PROTECTED]() + 0x25 odbc32.dll!_MPLeaveCriticalSection() + 0x17 0012fa34() [EMAIL PROTECTED]() + 0x96 php_pdo_odbc.dll!odbc_handle_preparer(_pdo_dbh_t * dbh=0x0071e338, const char * sql=0x0071e510, long sql_len=13, _pdo_stmt_t * stmt=0x0071e850, _zval_struct * driver_options=0x, void * * * tsrm_ls=0x00324090) Line 202 + 0x20C php_pdo.dll!zif_PDO_query(int ht=1, _zval_struct * return_value=0x0071e4a0, _zval_struct * * return_value_ptr=0x, _zval_struct * this_ptr=0x0071e510, int return_value_used=0, void * * * tsrm_ls=0x000d) Line 992 + 0x2fC php5ts.dll!10018d52() php5ts.dll!100b4b32() php5ts.dll!10018765() php5ts.dll!100186e5() php5ts.dll!10008d52() Previous Comments: [2005-12-14 06:02:19] [EMAIL PROTECTED] I made an adjustment to the way that we pull out the error information; I'm not sure that it will have resolved this particular issue, but it's worth trying it out while you're checking to see if #35620 is fixed. [2005-12-05 18:54:18] humbads at alum dot mit dot edu This is with the latest snapshot release: php5.1-win32-200512051530.zip Here is the stack trace: [EMAIL PROTECTED]() + 0x6a [EMAIL PROTECTED]() + 0x120 [EMAIL PROTECTED]() + 0xaa php_pdo_odbc.dll!pdo_odbc_error(_pdo_dbh_t * dbh=0x0071e6c8, _pdo_stmt_t * stmt=0x0071ebb8, void * statement=0x, char * what=0x005f3194, const char * file=0x005f31cc, int line=175, void * * * tsrm_ls=0x00323f68) Line 82C php_pdo_odbc.dll!odbc_handle_preparer(_pdo_dbh_t * dbh=0x0071e6c8, const char * sql=0x0071e878, long sql_len=13, _pdo_stmt_t * stmt=0x0071ebb8, _zval_struct * driver_options=0x, void * * * tsrm_ls=0x00323f68) Line 175 + 0x20C php_pdo.dll!zif_PDO_query(int ht=1, _zval_struct * return_value=0x0071e808, _zval_struct * * return_value_ptr=0x, _zval_struct * this_ptr=0x0071e878, int return_value_used=0, void * * * tsrm_ls=0x000d) Line 992 + 0x2fC php5ts.dll!zend_do_fcall_common_helper_SPEC(_zend_execute_data * execute_data=0x0012fb38, void * * * tsrm_ls=0x00323f68) Line 192 + 0x35C php5ts.dll!ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER(_zend_execute_data * execute_data=0x0012fb38, void * * * tsrm_ls=0x00323f68) Line 314 + 0x11C php5ts.dll!execute(_zend_op_array * op_array=0x0032, void * * * tsrm_ls=0x0071dda0) Line 92 + 0xc C [EMAIL PROTECTED]() + 0x130 [EMAIL PROTECTED]() + 0xc [EMAIL PROTECTED]() + 0x8a Unhandled exception at 0x7c80a258 (kernel32.dll) in php-cgi.exe: 0xC005: Access violation writing location 0x000c. [2005-12-05 06:15:31] humbads at alum dot mit dot edu Description: PHP crashes with a memory exception when running any query with invalid syntax. The driver is PDO-ODBC-Visual Foxpro on Windows XP SP2. The folder has full control
#35620 [Fbk-Opn]: access violation on odbc query
ID: 35620
User updated by: humbads at alum dot mit dot edu
Reported By: humbads at alum dot mit dot edu
-Status: Feedback
+Status: Open
Bug Type: PDO related
Operating System: Windows XP SP2
-PHP Version: 5CVS-2005-12-10 (snap)
+PHP Version: 5CVS-2005-12-14 (snap)
Assigned To: wez
New Comment:
This one also gives an exception, slightly different from before. This
crash is different than bug #35552, which occurs on any query for which
ODBC should return an error. This crash seems to happens when the
destructor is called on the statement. I noticed if there is no die()
or exit() in the function call (or class), there is no crash. My
second code example doesn't have this call and doesn't crash, so maybe
that's why you couldn't reproduce it. Snapshot
php5.1-win32-200512140730.zip.
Here a fixed example:
Reproduce code:
---
q();
function q() {
$odbc = new PDO(odbc:DSN=LocalPT;UID=ptuser;PWD=ptuser);
$query = SELECT * FROM tblUser;
$result = $odbc-query($query);
die();
}
Stack trace:
---
Unhandled exception at 0x7c901010 (ntdll.dll) in php-cgi.exe:
0xC005: Access violation reading location 0x0018.
[EMAIL PROTECTED]() + 0xb
odbc32.dll!CCriticalSection::Enter() + 0xf
[EMAIL PROTECTED]() + 0xf
[EMAIL PROTECTED]() + 0x23
[EMAIL PROTECTED]() + 0x2b
php_pdo_odbc.dll!odbc_stmt_dtor(_pdo_stmt_t * stmt=0x007218a0, void *
* * tsrm_ls=0x00324090) Line 56C
php_pdo.dll!free_statement(_pdo_stmt_t * stmt=0x007218a0, void * * *
tsrm_ls=0x00324090) Line 2118 + 0x8C
php_pdo.dll!php_pdo_stmt_delref(_pdo_stmt_t * stmt=0x007218a0, void *
* * tsrm_ls=0x00324090) Line 2157 + 0xbC
php_pdo.dll!pdo_dbstmt_free_storage(_pdo_stmt_t * stmt=0x007218a0,
void * * * tsrm_ls=0x00324090) Line 2162 + 0xf C
php5ts.dll!100ab5f7()
php5ts.dll!10096192()
[EMAIL PROTECTED]() + 0x26
[EMAIL PROTECTED]() + 0x114
Previous Comments:
[2005-12-14 06:00:14] [EMAIL PROTECTED]
I meant that this could be the same as #35592, not #35552.
[2005-12-14 05:58:57] [EMAIL PROTECTED]
This could be the same bug as #35552.
I couldn't reproduce the issue, but did spot some code that might cause
something like this to happen.
Please try the next snapshot dated after this message to see if that
nailed it.
[2005-12-10 08:43:54] humbads at alum dot mit dot edu
The same crash occurs if the code is simply within a function, rather
than a class. Furthermore, the same crash occurs if another data source
is used, e.g. SQL Server.
myfunction();
function myfunction() {
$odbc = new PDO(odbc:Driver={Microsoft Visual FoxPro
Driver};SourceType=DBF;SourceDB=C:\\);
$query = SELECT * FROM invoice;
$result = $odbc-query($query);
}
[2005-12-10 08:24:07] humbads at alum dot mit dot edu
Description:
php-cgi.exe crashes with an access violation when using PDO ODBC to run
a simple query as given below. The code runs without error if not
enclosed in a class. It also runs without error if the query is run
without saving the return value in $result. The stack trace indicates a
crash when destroying the implicit prepared statement.
Reproduce code:
---
$mc = new MyClass;
class MyClass {
function MyClass() {
$odbc = new PDO(odbc:Driver={Microsoft Visual FoxPro
Driver};SourceType=DBF;SourceDB=C:\\);
$query = SELECT * FROM invoice;
$result = $odbc-query($query);
die(happy);
}
}
Expected result:
It should not crash when returning the result, or when running from
within a class.
Actual result:
--
[EMAIL PROTECTED]() + 0xb
odbc32.dll!CCriticalSection::Enter() + 0xf
[EMAIL PROTECTED]() + 0xf
[EMAIL PROTECTED]() + 0x23
[EMAIL PROTECTED]() + 0x2b
php_pdo_odbc.dll!odbc_stmt_dtor(_pdo_stmt_t * stmt=0x00720448, void *
* * tsrm_ls=0x00323eb0) Line 56C
php_pdo.dll!free_statement(_pdo_stmt_t * stmt=0x00720448, void * * *
tsrm_ls=0x00323eb0) Line 2118 + 0x8C
php_pdo.dll!php_pdo_stmt_delref(_pdo_stmt_t * stmt=0x00720448, void *
* * tsrm_ls=0x00323eb0) Line 2157 + 0xbC
php_pdo.dll!pdo_dbstmt_free_storage(_pdo_stmt_t * stmt=0x00720448,
void * * * tsrm_ls=0x00323eb0) Line 2162 + 0xf C
php5ts.dll!zend_objects_store_free_object_storage(_zend_objects_store
* objects=0x00328dc4, void * * * tsrm_ls=0x00323eb0) Line 83 + 0xb C
php5ts.dll!shutdown_executor(void * * * tsrm_ls=0x00a232c0) Line
#35620 [NEW]: access violation on odbc query
From: humbads at alum dot mit dot edu
Operating system: Windows XP SP2
PHP version: 5CVS-2005-12-10 (snap)
PHP Bug Type: ODBC related
Bug description: access violation on odbc query
Description:
php-cgi.exe crashes with an access violation when using PDO ODBC to run a
simple query as given below. The code runs without error if not enclosed
in a class. It also runs without error if the query is run without saving
the return value in $result. The stack trace indicates a crash when
destroying the implicit prepared statement.
Reproduce code:
---
$mc = new MyClass;
class MyClass {
function MyClass() {
$odbc = new PDO(odbc:Driver={Microsoft Visual FoxPro
Driver};SourceType=DBF;SourceDB=C:\\);
$query = SELECT * FROM invoice;
$result = $odbc-query($query);
die(happy);
}
}
Expected result:
It should not crash when returning the result, or when running from within
a class.
Actual result:
--
[EMAIL PROTECTED]() + 0xb
odbc32.dll!CCriticalSection::Enter() + 0xf
[EMAIL PROTECTED]() + 0xf
[EMAIL PROTECTED]() + 0x23
[EMAIL PROTECTED]() + 0x2b
php_pdo_odbc.dll!odbc_stmt_dtor(_pdo_stmt_t * stmt=0x00720448, void * *
* tsrm_ls=0x00323eb0) Line 56 C
php_pdo.dll!free_statement(_pdo_stmt_t * stmt=0x00720448, void * * *
tsrm_ls=0x00323eb0) Line 2118 + 0x8C
php_pdo.dll!php_pdo_stmt_delref(_pdo_stmt_t * stmt=0x00720448, void * *
* tsrm_ls=0x00323eb0) Line 2157 + 0xb C
php_pdo.dll!pdo_dbstmt_free_storage(_pdo_stmt_t * stmt=0x00720448, void
* * * tsrm_ls=0x00323eb0) Line 2162 + 0xf C
php5ts.dll!zend_objects_store_free_object_storage(_zend_objects_store *
objects=0x00328dc4, void * * * tsrm_ls=0x00323eb0) Line 83 + 0xb C
php5ts.dll!shutdown_executor(void * * * tsrm_ls=0x00a232c0) Line 273 +
0x13C
[EMAIL PROTECTED]() + 0x26
Unhandled exception at 0x7c901010 (ntdll.dll) in php-cgi.exe: 0xC005:
Access violation reading location 0x0018.
--
Edit bug report at http://bugs.php.net/?id=35620edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=35620r=trysnapshot44
Try a CVS snapshot (PHP 5.1):
http://bugs.php.net/fix.php?id=35620r=trysnapshot51
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=35620r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=35620r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=35620r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=35620r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=35620r=needscript
Try newer version:http://bugs.php.net/fix.php?id=35620r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=35620r=support
Expected behavior:http://bugs.php.net/fix.php?id=35620r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=35620r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=35620r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=35620r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=35620r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=35620r=dst
IIS Stability:http://bugs.php.net/fix.php?id=35620r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=35620r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=35620r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=35620r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=35620r=mysqlcfg
#35620 [Opn]: access violation on odbc query
ID: 35620
User updated by: humbads at alum dot mit dot edu
Reported By: humbads at alum dot mit dot edu
Status: Open
Bug Type: ODBC related
Operating System: Windows XP SP2
PHP Version: 5CVS-2005-12-10 (snap)
New Comment:
The same crash occurs if the code is simply within a function, rather
than a class. Furthermore, the same crash occurs if another data source
is used, e.g. SQL Server.
myfunction();
function myfunction() {
$odbc = new PDO(odbc:Driver={Microsoft Visual FoxPro
Driver};SourceType=DBF;SourceDB=C:\\);
$query = SELECT * FROM invoice;
$result = $odbc-query($query);
}
Previous Comments:
[2005-12-10 08:24:07] humbads at alum dot mit dot edu
Description:
php-cgi.exe crashes with an access violation when using PDO ODBC to run
a simple query as given below. The code runs without error if not
enclosed in a class. It also runs without error if the query is run
without saving the return value in $result. The stack trace indicates a
crash when destroying the implicit prepared statement.
Reproduce code:
---
$mc = new MyClass;
class MyClass {
function MyClass() {
$odbc = new PDO(odbc:Driver={Microsoft Visual FoxPro
Driver};SourceType=DBF;SourceDB=C:\\);
$query = SELECT * FROM invoice;
$result = $odbc-query($query);
die(happy);
}
}
Expected result:
It should not crash when returning the result, or when running from
within a class.
Actual result:
--
[EMAIL PROTECTED]() + 0xb
odbc32.dll!CCriticalSection::Enter() + 0xf
[EMAIL PROTECTED]() + 0xf
[EMAIL PROTECTED]() + 0x23
[EMAIL PROTECTED]() + 0x2b
php_pdo_odbc.dll!odbc_stmt_dtor(_pdo_stmt_t * stmt=0x00720448, void *
* * tsrm_ls=0x00323eb0) Line 56C
php_pdo.dll!free_statement(_pdo_stmt_t * stmt=0x00720448, void * * *
tsrm_ls=0x00323eb0) Line 2118 + 0x8C
php_pdo.dll!php_pdo_stmt_delref(_pdo_stmt_t * stmt=0x00720448, void *
* * tsrm_ls=0x00323eb0) Line 2157 + 0xbC
php_pdo.dll!pdo_dbstmt_free_storage(_pdo_stmt_t * stmt=0x00720448,
void * * * tsrm_ls=0x00323eb0) Line 2162 + 0xf C
php5ts.dll!zend_objects_store_free_object_storage(_zend_objects_store
* objects=0x00328dc4, void * * * tsrm_ls=0x00323eb0) Line 83 + 0xb C
php5ts.dll!shutdown_executor(void * * * tsrm_ls=0x00a232c0) Line 273
+ 0x13 C
[EMAIL PROTECTED]() + 0x26
Unhandled exception at 0x7c901010 (ntdll.dll) in php-cgi.exe:
0xC005: Access violation reading location 0x0018.
--
Edit this bug report at http://bugs.php.net/?id=35620edit=1
#35552 [Fbk-Opn]: access violation on any invalid odbc query
ID: 35552
User updated by: humbads at alum dot mit dot edu
Reported By: humbads at alum dot mit dot edu
-Status: Feedback
+Status: Open
Bug Type: ODBC related
Operating System: Windows XP SP2
PHP Version: 5.1.1
New Comment:
This is with the latest snapshot release:
php5.1-win32-200512051530.zip
Here is the stack trace:
[EMAIL PROTECTED]() + 0x6a
[EMAIL PROTECTED]() + 0x120
[EMAIL PROTECTED]() + 0xaa
php_pdo_odbc.dll!pdo_odbc_error(_pdo_dbh_t * dbh=0x0071e6c8,
_pdo_stmt_t * stmt=0x0071ebb8, void * statement=0x, char *
what=0x005f3194, const char * file=0x005f31cc, int line=175, void * * *
tsrm_ls=0x00323f68) Line 82C
php_pdo_odbc.dll!odbc_handle_preparer(_pdo_dbh_t * dbh=0x0071e6c8,
const char * sql=0x0071e878, long sql_len=13, _pdo_stmt_t *
stmt=0x0071ebb8, _zval_struct * driver_options=0x, void * * *
tsrm_ls=0x00323f68) Line 175 + 0x20C
php_pdo.dll!zif_PDO_query(int ht=1, _zval_struct *
return_value=0x0071e808, _zval_struct * * return_value_ptr=0x,
_zval_struct * this_ptr=0x0071e878, int return_value_used=0, void * * *
tsrm_ls=0x000d) Line 992 + 0x2fC
php5ts.dll!zend_do_fcall_common_helper_SPEC(_zend_execute_data *
execute_data=0x0012fb38, void * * * tsrm_ls=0x00323f68) Line 192 +
0x35C
php5ts.dll!ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER(_zend_execute_data *
execute_data=0x0012fb38, void * * * tsrm_ls=0x00323f68) Line 314 +
0x11C
php5ts.dll!execute(_zend_op_array * op_array=0x0032, void * * *
tsrm_ls=0x0071dda0) Line 92 + 0xc C
[EMAIL PROTECTED]() + 0x130
[EMAIL PROTECTED]() + 0xc
[EMAIL PROTECTED]() + 0x8a
Unhandled exception at 0x7c80a258 (kernel32.dll) in php-cgi.exe:
0xC005: Access violation writing location 0x000c.
Previous Comments:
[2005-12-05 09:56:57] [EMAIL PROTECTED]
Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php
If you can provide more information, feel free to add it
to this bug and change the status back to Open.
Thank you for your interest in PHP.
[2005-12-05 06:15:31] humbads at alum dot mit dot edu
Description:
PHP crashes with a memory exception when running any query with invalid
syntax. The driver is PDO-ODBC-Visual Foxpro on Windows XP SP2. The
folder has full control permission for IUSR to the directory containing
the Foxpro DBF files.
The exception dialog shows:
php-cgi.exe - Application Error
The instruction at 0x7c80a258 reference memory at 0x000c. The
memory could not be written.
Using the out-of-the box install of PHP 5.1.1 with pdo and pdo_odbc
extensions loaded via php.ini. Latest Visual Foxpro ODBC driver was
downloaded from Microsoft website.
Reproduce code:
---
?php
$db = new PDO(odbc:Driver={Microsoft Visual FoxPro
Driver};SourceType=DBF;SourceDB=C:\\temp\\;Exclusive=No);
$db-query(any query with invalid syntax);
?
Expected result:
Should give a proper error message, no?
--
Edit this bug report at http://bugs.php.net/?id=35552edit=1
#35552 [NEW]: access violation on any invalid odbc query
From: humbads at alum dot mit dot edu
Operating system: Windows XP SP2
PHP version: 5.1.1
PHP Bug Type: Reproducible crash
Bug description: access violation on any invalid odbc query
Description:
PHP crashes with a memory exception when running any query with invalid
syntax. The driver is PDO-ODBC-Visual Foxpro on Windows XP SP2. The
folder has full control permission for IUSR to the directory containing
the Foxpro DBF files.
The exception dialog shows:
php-cgi.exe - Application Error
The instruction at 0x7c80a258 reference memory at 0x000c. The
memory could not be written.
Using the out-of-the box install of PHP 5.1.1 with pdo and pdo_odbc
extensions loaded via php.ini. Latest Visual Foxpro ODBC driver was
downloaded from Microsoft website.
Reproduce code:
---
?php
$db = new PDO(odbc:Driver={Microsoft Visual FoxPro
Driver};SourceType=DBF;SourceDB=C:\\temp\\;Exclusive=No);
$db-query(any query with invalid syntax);
?
Expected result:
Should give a proper error message, no?
--
Edit bug report at http://bugs.php.net/?id=35552edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=35552r=trysnapshot44
Try a CVS snapshot (PHP 5.1):
http://bugs.php.net/fix.php?id=35552r=trysnapshot51
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=35552r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=35552r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=35552r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=35552r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=35552r=needscript
Try newer version:http://bugs.php.net/fix.php?id=35552r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=35552r=support
Expected behavior:http://bugs.php.net/fix.php?id=35552r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=35552r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=35552r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=35552r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=35552r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=35552r=dst
IIS Stability:http://bugs.php.net/fix.php?id=35552r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=35552r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=35552r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=35552r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=35552r=mysqlcfg
