Bug #47387 [Com]: Load stmt result bool false
Edit report at http://bugs.php.net/bug.php?id=47387&edit=1
ID: 47387
Comment by: clewis at myfonts dot com
Reported by:lars dot a dot johansson at se dot atlascopco dot
com
Summary:Load stmt result bool false
Status: No Feedback
Type: Bug
Package:MySQLi related
Operating System: Linux mandriva 2009
PHP Version:5.3CVS-2009-02-14 (snap)
Assigned To:mysql
Block user comment: N
Private report: N
New Comment:
The bug happens if you do a SELECT before the LOAD DATA. In the script
above
(comment [2009-08-25 13:24 UTC] u...@php.net), if you insert these lines
before
the LOAD DATA query:
$res = $mysqli->query("SELECT * FROM foo limit 1");
printf("SELECT -> %s\n", var_export($res, true));
... then the LOAD DATA query will return false. Note that even though
the LOAD
DATA returns false, the data is inserted successfully.
I created a new bug for this the other day:
http://bugs.php.net/bug.php?id=53503
Sorry for the duplicate
Previous Comments:
[2009-09-02 01:00:00] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[2009-08-25 15:24:10] u...@php.net
Running the example gives:
bool(true)
array(1) {
[0]=>
string(4) "test"
}
bool(true)
Warning: mysqli::query(): (42S22/1054): Unknown column 'APP
LICANT_NO' in 'field list' in
/home/nixnutz/src/login/PHP_5_3/bug47387.php on line 85
bool(false)
Please verify if that is the cause of the bool(false).
A short LOAD DATA test such as the one below does not show any
differences between PHP 5.2 and PHP 5.3 on my box. Would be great, if
you could try that one as well.
$mysqli = new mysqli("127.0.0.1", "root", "root");
$res = $mysqli->query("USE phptest");
printf("USE phptest -> %s\n", var_export($res, true));
$mysqli->query("DROP TABLE IF EXISTS foo");
$res = $mysqli->query("CREATE TABLE IF NOT EXISTS foo (id INT, bar
CHAR(2))");
printf("CREATE TABLE -> %s\n", var_export($res, true));
$file = tempnam(sys_get_temp_dir(), "bug47387");
var_dump($file);
$fp = fopen($file, "w");
fwrite($fp, "1;a\n");
fclose($fp);
$res = $mysqli->query(sprintf("LOAD DATA LOCAL INFILE '%s' INTO TABLE
foo FIELDS TERMINATED BY ';'", $file));
printf("LOAD DATA -> %s\n", var_export($res, true));
$res = $mysqli->query("SELECT * FROM foo");
if ($res)
while ($row = $res->fetch_assoc())
var_dump($row);
[2009-02-25 17:13:34] johan...@php.net
I couldn't reproduce using myslqnd and libmysql currently creates other
trouble for me. but I'll investigate. Thanks for the short script so far
:-)
[2009-02-25 15:23:28] lars dot a dot johansson at se dot atlascopco dot
com
Hi,
I can reproduce 'the bug' with attached ugly code. you can use the
infile I supplied earlier. the problem seems a bit tricky.
1 $result = $mysqli->query('CREATE TABLE IF NOT EXISTS ...'
2 $result = $mysqli->query("SHOW WARNINGS", MYSQLI_USE_RESULT...
this shows one warning:
Note (1050): Table 'PROJECT_DETAIL' already exists
3 $result->close();
4 Now when I run $result = $mysqli->query(LOAD DATA LOCAL INFILE ...
then $result is false and I get the warning:
//PHP Warning: mysqli::query(): (0/0): ...
Note! this only happen in 5.3, in 5.2 $result is true.
Look in the code for the snippet that prevent the 'bug'.
Please let me know if there anything more I can do.
#!/home/tooljn/PHP5.3/local/bin/php
query($sqlstmt);
var_dump($result);
//if($result) $result->close();
if ($result = $mysqli->query("SELECT DATABASE()")) {
$row = $result->fetch_row();
$result->close();
}
var_dump($row);
$sqlstmt = 'CREATE TABLE IF NOT EXISTS PROJECT_DETAIL
(`PROJECT_DEFINITION` CHAR(24),`DESCRIPTION` CHAR(40),`MASK_ID`
CHAR(24),`RESPONSIBLE_NO` DECIMAL(8,0),`APPLICANT_NO`
DECIMAL(8,0),`COMP_CODE` CHAR(4),`BUS_AREA` CHAR(4),`CONTROLLING_AREA`
CHAR(4),`PROFIT_CTR` CHAR(10),`PROJECT_CURRENCY`
CHAR(5),`PROJECT_CURRENCY_ISO` CHAR(3),`NETWORK_ASSIGNMENT`
DECIMAL(1,0),`START` DATE,`FINISH` DATE,`PLANT
[PHP-BUG] Bug #53503 [NEW]: mysqli::query returns false after successful LOAD DATA query
From:
Operating system: Linux - CentOS
PHP version: 5.3.3
Package: MySQLi related
Bug Type: Bug
Bug description:mysqli::query returns false after successful LOAD DATA query
Description:
When a LOAD DATA LOCAL INFILE query is run after a previous SELECT query on
the
same mysqli handle, mysqli::query returns false even though the LOAD DATA
query
is successful.
Additionally, PHP outputs two warnings during the mysqli::query call:
PHP Warning: mysqli::query(): (0/0): in /path/to/script.php on line
16
Warning: mysqli::query(): (0/0): in /path/to/script.php on line 16
Properties of the mysqli object, such as errorno and affected_rows,
indicate
success.
If the LOAD DATA query is the first query run on a particular mysqli
object, it
works fine.
We are using the mysqlnd lib.
Configuration:
./configure --prefix=/usr/local --with-xmlrpc --with-apxs2 --with-
mysqli=mysqlnd --with-pdo-mysql=mysqlnd --with-curl --with-curlwrappers --
enable-bcmath --with-gd=/usr --with-mcrypt=/usr/local --enable-mbstring
--with-
zlib --with-iconv --enable-soap --enable-ftp --without-sqlite --with-xsl
--
enable-pcntl --enable-sockets --with-openssl
This may be the same as inactive Bug #47387.
Test script:
---
$db = new mysqli($host,$user,$pass,$dbname);
$tempfile = tempnam("/tmp","loaddata_");
file_put_contents($tempfile, "1");
$db->query("create table if not exists LoadDataTest (Column1 int unsigned
not null primary key)");
$db->query("select * from LoadDataTest limit 1"); //LOAD DATA works
properly without this
$result = $db->query("load data local infile '$tempfile' replace into table
LoadDataTest (Column1)");
if ($result) print "Load data success.\n";
else print "Error {$db->errno}: {$db->error}\n";
unlink($tempfile);
Expected result:
mysqli::query returns result object
Actual result:
--
mysqli::query returns false
--
Edit bug report at http://bugs.php.net/bug.php?id=53503&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=53503&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=53503&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=53503&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=53503&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=53503&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=53503&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=53503&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=53503&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=53503&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=53503&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=53503&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=53503&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=53503&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=53503&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53503&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=53503&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=53503&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=53503&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=53503&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=53503&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=53503&r=mysqlcfg
#34744 [Bgs]: system() forces Content-type header output
ID: 34744 User updated by: clewis at myfonts dot com Reported By: clewis at myfonts dot com Status: Bogus Bug Type: Output Control Operating System: Windows XP, CentOS 4 PHP Version: 5.0.5 New Comment: christian dot mueller at dfpx dot de says: --- I read "web server's OB" ... that is quite different from the "php OB initiated with ob_start()" as reported in this Bug. --- I (original submitter) say: It looks like I should be using passthru() instead of system(). Nonetheless it is confusing that system() completely ignores the PHP output buffer. Previous Comments: [2005-10-05 23:07:24] [EMAIL PROTECTED] RTFM: "The system() call also tries to automatically flush the web server's output buffer after each line of output if PHP is running as a server module." -------- [2005-10-05 22:06:13] clewis at myfonts dot com I'm using Apache 2 APXS module on both Windows XP SP2 and CentOS 4.1 (like RHEL 4), if that helps. [2005-10-05 21:37:40] [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-10-05 20:53:56] clewis at myfonts dot com Description: Calling the system() function forces the standard Content-type: text/html header output, even when output buffering is on. This behaviour is unlike other output commands such as print, which suppress the "automatic" headers until the output buffer is flushed. Note that replacing system() with print() in the sample code works as expected. Reproduce code: --- Expected result: Content-type: text/plain Hello World. Actual result: -- Content-type: text/html Warning: Cannot modify header information - headers already sent... Hello World. -- Edit this bug report at http://bugs.php.net/?id=34744&edit=1
#34744 [Opn]: system() forces Content-type header output
ID: 34744 User updated by: clewis at myfonts dot com Reported By: clewis at myfonts dot com Status: Open Bug Type: Output Control Operating System: Windows XP, CentOS 4 PHP Version: 5.0.5 New Comment: I'm using Apache 2 APXS module on both Windows XP SP2 and CentOS 4.1 (like RHEL 4), if that helps. Previous Comments: [2005-10-05 22:04:10] clewis at myfonts dot com It's a pretty simple problem, I don't know how I can be more specific! [2005-10-05 21:37:40] [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-10-05 20:53:56] clewis at myfonts dot com Description: Calling the system() function forces the standard Content-type: text/html header output, even when output buffering is on. This behaviour is unlike other output commands such as print, which suppress the "automatic" headers until the output buffer is flushed. Note that replacing system() with print() in the sample code works as expected. Reproduce code: --- Expected result: Content-type: text/plain Hello World. Actual result: -- Content-type: text/html Warning: Cannot modify header information - headers already sent... Hello World. -- Edit this bug report at http://bugs.php.net/?id=34744&edit=1
#34744 [Fbk->Opn]: system() forces Content-type header output
ID: 34744 User updated by: clewis at myfonts dot com Reported By: clewis at myfonts dot com -Status: Feedback +Status: Open Bug Type: Output Control Operating System: Windows XP, CentOS 4 PHP Version: 5.0.5 New Comment: It's a pretty simple problem, I don't know how I can be more specific! Previous Comments: [2005-10-05 21:37:40] [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-10-05 20:53:56] clewis at myfonts dot com Description: Calling the system() function forces the standard Content-type: text/html header output, even when output buffering is on. This behaviour is unlike other output commands such as print, which suppress the "automatic" headers until the output buffer is flushed. Note that replacing system() with print() in the sample code works as expected. Reproduce code: --- Expected result: Content-type: text/plain Hello World. Actual result: -- Content-type: text/html Warning: Cannot modify header information - headers already sent... Hello World. -- Edit this bug report at http://bugs.php.net/?id=34744&edit=1
#34744 [NEW]: system() forces Content-type header output
From: clewis at myfonts dot com Operating system: Windows XP, CentOS 4 PHP version: 5.0.5 PHP Bug Type: Output Control Bug description: system() forces Content-type header output Description: Calling the system() function forces the standard Content-type: text/html header output, even when output buffering is on. This behaviour is unlike other output commands such as print, which suppress the "automatic" headers until the output buffer is flushed. Note that replacing system() with print() in the sample code works as expected. Reproduce code: --- Expected result: Content-type: text/plain Hello World. Actual result: -- Content-type: text/html Warning: Cannot modify header information - headers already sent... Hello World. -- Edit bug report at http://bugs.php.net/?id=34744&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34744&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=34744&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=34744&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=34744&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=34744&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=34744&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=34744&r=needscript Try newer version: http://bugs.php.net/fix.php?id=34744&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=34744&r=support Expected behavior: http://bugs.php.net/fix.php?id=34744&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=34744&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=34744&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=34744&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34744&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=34744&r=dst IIS Stability: http://bugs.php.net/fix.php?id=34744&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=34744&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=34744&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=34744&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=34744&r=mysqlcfg
#31822 [Bgs]: __FUNCTION__ magic constant doesn't work in eval()
ID: 31822 User updated by: clewis at myfonts dot com Reported By: clewis at myfonts dot com Status: Bogus Bug Type: Zend Engine 2 problem Operating System: RedHat Enterprise 3 PHP Version: 5.0.3 New Comment: I see. I thought the eval() was run in the current context, but in fact it runs in its own completely separate PHP context? But that doesn't make sense since you can make variable assignments etc within the eval(). It seems if one can make use of pre-existing variables within the eval, it should also know it's inside a function. Previous Comments: [2005-02-03 17:21:52] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php In your example there is no function in your eval\'d code. [2005-02-03 00:35:22] clewis at myfonts dot com Description: The __FUNCTION__ magic constant returns nothing when used in eval()'d code. __FILE__ and __LINE__ work as expected. Reproduce code: --- Expected result: the function is: whatFunctionAmI Actual result: -- the function is: -- Edit this bug report at http://bugs.php.net/?id=31822&edit=1
#31822 [NEW]: __FUNCTION__ magic constant doesn't work in eval()
From: clewis at myfonts dot com Operating system: RedHat Enterprise 3 PHP version: 5.0.3 PHP Bug Type: Zend Engine 2 problem Bug description: __FUNCTION__ magic constant doesn't work in eval() Description: The __FUNCTION__ magic constant returns nothing when used in eval()'d code. __FILE__ and __LINE__ work as expected. Reproduce code: --- Expected result: the function is: whatFunctionAmI Actual result: -- the function is: -- Edit bug report at http://bugs.php.net/?id=31822&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=31822&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=31822&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=31822&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=31822&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=31822&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=31822&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=31822&r=needscript Try newer version: http://bugs.php.net/fix.php?id=31822&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=31822&r=support Expected behavior: http://bugs.php.net/fix.php?id=31822&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=31822&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=31822&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=31822&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=31822&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=31822&r=dst IIS Stability: http://bugs.php.net/fix.php?id=31822&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=31822&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=31822&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=31822&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=31822&r=mysqlcfg
#31732 [NEW]: mb_get_info causes seg fault
From: clewis at myfonts dot com Operating system: RedHat Enterprise 3 PHP version: 5.0.3 PHP Bug Type: Reproducible crash Bug description: mb_get_info causes seg fault Description: Calling the mb_get_info() function causes segmentation fault. This happens both as Apache module and CLI. The other mb_* functions work fine, it's just the info that causes a problem. Compiled with: './configure' '--prefix=/usr/local' '--with-apache=../apache' '--with-mysql=/usr/local/mysql' '--with-curl=/usr/local' '--with-gd' '--with-mcrypt=/usr/local' '--enable-mbstring' '--with-zlib' '--with-iconv' '--with-pspell=/usr/local' '--with-curlwrappers' '--enable-soap' '--with-libxml-dir=/usr/local' '--without-sqlite' Reproduce code: --- Expected result: Multi-byte string library info. Actual result: -- Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1218546240 (LWP 11950)] 0x00aa7f38 in strcasecmp () from /lib/tls/libc.so.6 (gdb) bt #0 0x00aa7f38 in strcasecmp () from /lib/tls/libc.so.6 #1 0x080b9f0d in zif_mb_get_info (ht=0, return_value=0xb62898, this_ptr=0x0, return_value_used=1) at /usr/local/src/currentstuff/php-5.0.3/ext/mbstring/mbstring.c:3219 #2 0x081d04d6 in zend_do_fcall_common_helper (execute_data=0xbfffb150, opline=0x9d69d9c, op_array=0x9d65c4c) at /usr/local/src/currentstuff/php-5.0.3/Zend/zend_execute.c:2711 #3 0x081cdad2 in execute (op_array=0x9d65c4c) at /usr/local/src/currentstuff/php-5.0.3/Zend/zend_execute.c:1400 #4 0x081b3c77 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/local/src/currentstuff/php-5.0.3/Zend/zend.c:1069 #5 0x08186a73 in php_execute_script (primary_file=0xbfffd510) at /usr/local/src/currentstuff/php-5.0.3/main/main.c:1628 #6 0x081d6c64 in main (argc=2, argv=0xbfffd5d4) at /usr/local/src/currentstuff/php-5.0.3/sapi/cli/php_cli.c:943 -- Edit bug report at http://bugs.php.net/?id=31732&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=31732&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=31732&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=31732&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=31732&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=31732&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=31732&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=31732&r=needscript Try newer version: http://bugs.php.net/fix.php?id=31732&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=31732&r=support Expected behavior: http://bugs.php.net/fix.php?id=31732&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=31732&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=31732&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=31732&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=31732&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=31732&r=dst IIS Stability: http://bugs.php.net/fix.php?id=31732&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=31732&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=31732&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=31732&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=31732&r=mysqlcfg
#31732 [Opn]: mb_get_info causes seg fault
ID: 31732 User updated by: clewis at myfonts dot com Reported By: clewis at myfonts dot com Status: Open Bug Type: Reproducible crash Operating System: RedHat Enterprise 3 PHP Version: 5.0.3 New Comment: Only happens when no argument is given. According to the manual, this case should behave as if the argument is 'all'. Previous Comments: [2005-01-28 01:23:45] clewis at myfonts dot com Description: Calling the mb_get_info() function causes segmentation fault. This happens both as Apache module and CLI. The other mb_* functions work fine, it's just the info that causes a problem. Compiled with: './configure' '--prefix=/usr/local' '--with-apache=../apache' '--with-mysql=/usr/local/mysql' '--with-curl=/usr/local' '--with-gd' '--with-mcrypt=/usr/local' '--enable-mbstring' '--with-zlib' '--with-iconv' '--with-pspell=/usr/local' '--with-curlwrappers' '--enable-soap' '--with-libxml-dir=/usr/local' '--without-sqlite' Reproduce code: --- Expected result: Multi-byte string library info. Actual result: -- Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1218546240 (LWP 11950)] 0x00aa7f38 in strcasecmp () from /lib/tls/libc.so.6 (gdb) bt #0 0x00aa7f38 in strcasecmp () from /lib/tls/libc.so.6 #1 0x080b9f0d in zif_mb_get_info (ht=0, return_value=0xb62898, this_ptr=0x0, return_value_used=1) at /usr/local/src/currentstuff/php-5.0.3/ext/mbstring/mbstring.c:3219 #2 0x081d04d6 in zend_do_fcall_common_helper (execute_data=0xbfffb150, opline=0x9d69d9c, op_array=0x9d65c4c) at /usr/local/src/currentstuff/php-5.0.3/Zend/zend_execute.c:2711 #3 0x081cdad2 in execute (op_array=0x9d65c4c) at /usr/local/src/currentstuff/php-5.0.3/Zend/zend_execute.c:1400 #4 0x081b3c77 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/local/src/currentstuff/php-5.0.3/Zend/zend.c:1069 #5 0x08186a73 in php_execute_script (primary_file=0xbfffd510) at /usr/local/src/currentstuff/php-5.0.3/main/main.c:1628 #6 0x081d6c64 in main (argc=2, argv=0xbfffd5d4) at /usr/local/src/currentstuff/php-5.0.3/sapi/cli/php_cli.c:943 -- Edit this bug report at http://bugs.php.net/?id=31732&edit=1
#29665 [Com]: PHP Fails to compile when soap is enabled
ID: 29665 Comment by: clewis at myfonts dot com Reported By: moontumbo at hotmail dot com Status: No Feedback Bug Type: Compile Failure Operating System: Red Hat Enterprise Linux WS 3.0 PHP Version: 5.0.1 New Comment: I too saw this problem on RedHat Enterprise 3 using libxml2 2.5.10. Upgrading to 2.6.12 solved the problem. Previous Comments: [2004-08-28 16:52:52] michiel at dotgeek dot org same problem, slack 9.0 $ xml2-config --version 2.6.12 [2004-08-25 01:00:11] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2004-08-17 23:17:13] ibrash at gaernin dot aswwc dot net Issue reproduced on Slackware 9.1 with libxml2 2.5.11. [2004-08-17 08:06:37] [EMAIL PROTECTED] Which libxml2 did you have installed before? [2004-08-16 21:51:08] ppritzl at hotmail dot com Upgrading the libxml2 to 2.6.11-1 solved this issue for me on both RH9 and RH Enterprise 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/29665 -- Edit this bug report at http://bugs.php.net/?id=29665&edit=1
