Bug #52998 [Com]: memory content leak when using invalid utf-8 with XMLWriter::writeAttribute
Edit report at http://bugs.php.net/bug.php?id=52998&edit=1
ID: 52998
Comment by: kees at outflux dot net
Reported by:kees at outflux dot net
Summary:memory content leak when using invalid utf-8 with
XMLWriter::writeAttribute
Status: Bogus
Type: Bug
Package:XML Writer
Operating System: Ubuntu 10.10
PHP Version:5.3.3
Assigned To:rrichards
Block user comment: N
New Comment:
Yeah, it wasn't clear if the API was being misused or not. But it does
seem like a libxml2 bug after I got a test case working there this
morning. For reference, it's here:
https://bugzilla.gnome.org/show_bug.cgi?id=631551
Previous Comments:
[2010-10-06 21:38:06] rricha...@php.net
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
You just reported the same bug to libxml2 bug system. Will be handled
there
[2010-10-06 21:25:48] paj...@php.net
Rob, does it ring a bell? It could be a bug in libxml?
[2010-10-06 20:38:47] kees at outflux dot net
This was discovered in Ubuntu, btw:
https://bugs.launchpad.net/php/+bug/655442
[2010-10-06 03:52:16] kees at outflux dot net
Description:
It seems that PHP is not correctly using libxml2's xmlwriter routines,
and allows passing in invalid utf-8 strings which are then misparsed by
libxml2, allowing memory contents to leak into the resulting output.
Test script:
---
# License: GPLv3
#
# Proof-of-concept memory content leak
$xw = new XMLWriter();
$xw->openURI('php://output');
$xw->startElement('input');
$xw->writeAttribute('value', "\xe0\x81");
$xw->endElement();
?>
Expected result:
Actual result:
--
PHP Warning: XMLWriter::writeAttribute(): string is not in UTF-8 in
/tmp/xmlwriter.php on line 12
--
Edit this bug report at http://bugs.php.net/bug.php?id=52998&edit=1
Bug #52998 [Com]: memory content leak when using invalid utf-8 with XMLWriter::writeAttribute
Edit report at http://bugs.php.net/bug.php?id=52998&edit=1
ID: 52998
Comment by: kees at outflux dot net
Reported by:kees at outflux dot net
Summary:memory content leak when using invalid utf-8 with
XMLWriter::writeAttribute
Status: Open
Type: Bug
Package:XML Writer
Operating System: Ubuntu 10.10
PHP Version:5.3.3
Block user comment: N
New Comment:
This was discovered in Ubuntu, btw:
https://bugs.launchpad.net/php/+bug/655442
Previous Comments:
[2010-10-06 03:52:16] kees at outflux dot net
Description:
It seems that PHP is not correctly using libxml2's xmlwriter routines,
and allows passing in invalid utf-8 strings which are then misparsed by
libxml2, allowing memory contents to leak into the resulting output.
Test script:
---
# License: GPLv3
#
# Proof-of-concept memory content leak
$xw = new XMLWriter();
$xw->openURI('php://output');
$xw->startElement('input');
$xw->writeAttribute('value', "\xe0\x81");
$xw->endElement();
?>
Expected result:
Actual result:
--
PHP Warning: XMLWriter::writeAttribute(): string is not in UTF-8 in
/tmp/xmlwriter.php on line 12
--
Edit this bug report at http://bugs.php.net/bug.php?id=52998&edit=1
[PHP-BUG] Bug #52998 [NEW]: memory content leak when using invalid utf-8 with XMLWriter::writeAttribute
From:
Operating system: Ubuntu 10.10
PHP version: 5.3.3
Package: XML Writer
Bug Type: Bug
Bug description:memory content leak when using invalid utf-8 with
XMLWriter::writeAttribute
Description:
It seems that PHP is not correctly using libxml2's xmlwriter routines, and
allows passing in invalid utf-8 strings which are then misparsed by
libxml2, allowing memory contents to leak into the resulting output.
Test script:
---
# License: GPLv3
#
# Proof-of-concept memory content leak
$xw = new XMLWriter();
$xw->openURI('php://output');
$xw->startElement('input');
$xw->writeAttribute('value', "\xe0\x81");
$xw->endElement();
?>
Expected result:
Actual result:
--
PHP Warning: XMLWriter::writeAttribute(): string is not in UTF-8 in
/tmp/xmlwriter.php on line 12
--
Edit bug report at http://bugs.php.net/bug.php?id=52998&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52998&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52998&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=52998&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52998&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=52998&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52998&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=52998&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=52998&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=52998&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=52998&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=52998&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=52998&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=52998&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52998&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52998&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=52998&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=52998&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=52998&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=52998&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=52998&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=52998&r=mysqlcfg
#40544 [Fbk->Opn]: PostgreSQL connection hangs after die()
ID: 40544 User updated by: kees at tweakers dot net Reported By: kees at tweakers dot net -Status: Feedback +Status: Open Bug Type: PostgreSQL related Operating System: Linux (Debian) PHP Version: 5.2.1 New Comment: Using the latest snapshots results in the same behaviour; the script hangs and the connection stays open. Previous Comments: [2008-10-30 17:02:18] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2007-04-05 07:48:28] [EMAIL PROTECTED] >'Rollback on shutdown' is like 'Don't flush buffer before closing file'. I disagree, you need to commit everything explicitly. If you didn't commit the transaction, it should be rolled back. [2007-04-05 01:28:11] yohgaki at ohgaki dot net > And that's something I would call expected, because "rollback on > shutdown" is much safer than "commit on shutdown". As I wrote, under normal condition, current code(commit on shutdown) does make more sense than rollback on shutdown because PostgreSQL supports async query. 'Rollback on shutdown' is like 'Don't flush buffer before closing file'. It does not acceptable for most people. (And more efficient if it finish pending query at shutdown, too. If you are curious, take some simple benchmarks) However, under shared environment, it is not acceptable to consume all connection by COPY FROM SDTIN. It is better to have a way to avoid such action. There are 2 options: 1) Leave it alone (and make DoS possible under shared environment) 2) Give administrators a option that cancel current and pending async query. I prefer first option. I'll ask PostgreSQL developer if it's possible to have GRANT option for COPY in the future. [2007-03-09 10:11:12] [EMAIL PROTECTED] >By calling PQcanel() before clean up resource, all async query which >is not finished yet will be discarded instead of finishing its query. And that's something I would call expected, because "rollback on shutdown" is much safer than "commit on shutdown". >I'll add new ini option that enables PQcancel() in >list_entry_destructor. Any comments? More INI options? No, thanks. [2007-03-08 04:24:24] yohgaki at ohgaki dot net I didn't look the backtrace carefully. It stops when PQclear() is called on the backtrace, while my PHP 5.2 stopeed at PQgetReuslt(). (Both of them are called when request is shutting down) For at least PHP 5.2, it would be solved by calling PQcanel() when cleaning up resource, but with compatibility issue. By calling PQcanel() before clean up resource, all async query which is not finished yet will be discarded instead of finishing its query. I'll add new ini option that enables PQcancel() in list_entry_destructor. Any comments? 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/40544 -- Edit this bug report at http://bugs.php.net/?id=40544&edit=1
#40544 [Fbk->Opn]: PostgreSQL connection hangs after die()
ID: 40544 User updated by: kees at tweakers dot net Reported By: kees at tweakers dot net -Status: Feedback +Status: Open Bug Type: PostgreSQL related Operating System: Linux (Debian) PHP Version: 5.2.1 New Comment: tested with the snapshot: [EMAIL PROTECTED]:/usr/src/php5.2-200702191330$ sapi/cli/php test.3.php Starting And now he hangs in a busy wait [ctrl-c] [EMAIL PROTECTED]:/usr/src/php5.2-200702191330$ sapi/cli/php -v PHP 5.2.2-dev (cli) (built: Feb 19 2007 16:49:22) Copyright (c) 1997-2007 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies ldd sapi/cli/php libpq.so.5 => /usr/lib/libpq.so.5 (0xa7f3c000) Previous Comments: [2007-02-19 15:19:10] acm at tweakers dot net Btw, when hanging gdb to the php-process and type 'bt' you get this: #0 0xa7ba88c0 in free () from /lib/tls/libc.so.6 #1 0xa7ec8ea7 in PQclear () from /usr/lib/libpq.so.5 #2 0x08086fc8 in _close_pgsql_link (rsrc=0x81e43ec) at /usr/src/php-4.4.2/ext/pgsql/pgsql.c:277 #3 0x08139fb2 in list_entry_destructor (ptr=0x81e43ec) at /usr/src/php-4.4.2/Zend/zend_list.c:177 #4 0x08137977 in zend_hash_apply_deleter (ht=0x81a49e0, p=0x81e43b4) at /usr/src/php-4.4.2/Zend/zend_hash.c:611 #5 0x08137b97 in zend_hash_graceful_reverse_destroy (ht=0x81a49e0) at /usr/src/php-4.4.2/Zend/zend_hash.c:677 #6 0x0812b9ed in shutdown_executor () at /usr/src/php-4.4.2/Zend/zend_execute_API.c:211 #7 0x08133801 in zend_deactivate () at /usr/src/php-4.4.2/Zend/zend.c:689 #8 0x08107862 in php_request_shutdown (dummy=0x0) at /usr/src/php-4.4.2/main/main.c:999 #9 0x0814ee56 in main (argc=2, argv=0xafb6d114) at /usr/src/php-4.4.2/sapi/cli/php_cli.c:881 [2007-02-19 15:10:06] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.2-win32-latest.zip [2007-02-19 14:57:19] kees at tweakers dot net Description: After opening a db connection to postgresql and executing a query, and after that query a 'die()' php doesnt return to the CLI but hangs Reproduce code: --- Expected result: [EMAIL PROTECTED]:~$ php test.3.php Starting And now he hangs in a busy wait [EMAIL PROTECTED]:~$ Actual result: -- [EMAIL PROTECTED]:~$ php test.3.php Starting And now he hangs in a busy wait [no prompt, you have to ctrl-c to exit] Last part of strace: recv(3, "C\0\0\0\21CREATE TABLE\0G\0\0\0\t\0\0\1\0\0", 16384, 0) = 28 write(1, "And now he hangs in a busy wait\n", 32And now he hangs in a busy wait ) = 32 close(6)= 0 close(5)= 0 close(4)= 0 He probably wants to do a close(3) here as that is the postgresql connection, but it never closes, and netstat will show an open connection: Active UNIX domain sockets (servers and established) Proto RefCnt Flags Type State I-Node PID/Program namePath unix 3 [ ] STREAM CONNECTED 549701 - /var/run/postgresql/.s.PGSQL.5432 unix 3 [ ] STREAM CONNECTED 549700 26884/php Tested with PHP 5.2.0-8 (debian package) and PHP 4.4.2 -- Edit this bug report at http://bugs.php.net/?id=40544&edit=1
#40544 [NEW]: PostgreSQL connection hangs after die()
From: kees at tweakers dot net Operating system: Linux (Debian) PHP version: 5.2.1 PHP Bug Type: PostgreSQL related Bug description: PostgreSQL connection hangs after die() Description: After opening a db connection to postgresql and executing a query, and after that query a 'die()' php doesnt return to the CLI but hangs Reproduce code: --- Expected result: [EMAIL PROTECTED]:~$ php test.3.php Starting And now he hangs in a busy wait [EMAIL PROTECTED]:~$ Actual result: -- [EMAIL PROTECTED]:~$ php test.3.php Starting And now he hangs in a busy wait [no prompt, you have to ctrl-c to exit] Last part of strace: recv(3, "C\0\0\0\21CREATE TABLE\0G\0\0\0\t\0\0\1\0\0", 16384, 0) = 28 write(1, "And now he hangs in a busy wait\n", 32And now he hangs in a busy wait ) = 32 close(6)= 0 close(5)= 0 close(4)= 0 He probably wants to do a close(3) here as that is the postgresql connection, but it never closes, and netstat will show an open connection: Active UNIX domain sockets (servers and established) Proto RefCnt Flags Type State I-Node PID/Program name Path unix 3 [ ] STREAM CONNECTED 549701 - /var/run/postgresql/.s.PGSQL.5432 unix 3 [ ] STREAM CONNECTED 549700 26884/php Tested with PHP 5.2.0-8 (debian package) and PHP 4.4.2 -- Edit bug report at http://bugs.php.net/?id=40544&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=40544&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=40544&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=40544&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=40544&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=40544&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=40544&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=40544&r=needscript Try newer version:http://bugs.php.net/fix.php?id=40544&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=40544&r=support Expected behavior:http://bugs.php.net/fix.php?id=40544&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=40544&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=40544&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=40544&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40544&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=40544&r=dst IIS Stability:http://bugs.php.net/fix.php?id=40544&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=40544&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=40544&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=40544&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=40544&r=mysqlcfg
#29249 [Opn]: imagettfbbox / imagettfbbox returning wrong values w/ linebreaks
ID: 29249 User updated by: kees at tweakers dot net Reported By: kees at tweakers dot net Status: Open Bug Type: GD related Operating System: Linux PHP Version: 5.0.0 New Comment: Actual result should be: -- Both will give the same result, a box of x: 15 y: 12. Previous Comments: [2004-07-19 03:24:20] kees at tweakers dot net Description: The imagettfbbox / imagettftext should return an array with the boundaries on texts. This works fine with a single string, but if you use a multiline string (with \n in it) it fails to report the actual size, and returns the size / box of a single line. The string _is_ writen normally on the image, ie; with a newline instead of an \n, but the sizes are wrong. Reproduce code: --- // string with a line break, try imagettftext, it'll put the correct string on the image, but return the wrong results $bounds = imagettfbbox(8, 0, 'tahoma.ttf', 'j\nj'); print_r($bounds); // no line break here, just a \ instead of a /, which is the same size. $bounds = imagettfbbox(8, 0, 'tahoma.ttf', 'j/nj'); print_r($bounds); Expected result: The first line should return something like a box with an x/y of 3 / 26 (or close), the second result should return (and does ;)) an x/y box of 15 / 12. Actual result: -- Both will give the same result, a box of x: 15 y: 26. -- Edit this bug report at http://bugs.php.net/?id=29249&edit=1
#29249 [NEW]: imagettfbbox / imagettfbbox returning wrong values w/ linebreaks
From: kees at tweakers dot net Operating system: Linux PHP version: 5.0.0 PHP Bug Type: GD related Bug description: imagettfbbox / imagettfbbox returning wrong values w/ linebreaks Description: The imagettfbbox / imagettftext should return an array with the boundaries on texts. This works fine with a single string, but if you use a multiline string (with \n in it) it fails to report the actual size, and returns the size / box of a single line. The string _is_ writen normally on the image, ie; with a newline instead of an \n, but the sizes are wrong. Reproduce code: --- // string with a line break, try imagettftext, it'll put the correct string on the image, but return the wrong results $bounds = imagettfbbox(8, 0, 'tahoma.ttf', 'j\nj'); print_r($bounds); // no line break here, just a \ instead of a /, which is the same size. $bounds = imagettfbbox(8, 0, 'tahoma.ttf', 'j/nj'); print_r($bounds); Expected result: The first line should return something like a box with an x/y of 3 / 26 (or close), the second result should return (and does ;)) an x/y box of 15 / 12. Actual result: -- Both will give the same result, a box of x: 15 y: 26. -- Edit bug report at http://bugs.php.net/?id=29249&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=29249&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=29249&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=29249&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=29249&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=29249&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=29249&r=needscript Try newer version: http://bugs.php.net/fix.php?id=29249&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=29249&r=support Expected behavior: http://bugs.php.net/fix.php?id=29249&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=29249&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=29249&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=29249&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=29249&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=29249&r=dst IIS Stability: http://bugs.php.net/fix.php?id=29249&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=29249&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=29249&r=float
#25927 [Com]: get_html_translation_table calls the ' ' instead of '
ID: 25927
Comment by: kees at tweakers dot net
Reported By: acm at tweakers dot net
Status: Open
Bug Type: Unknown/Other Function
Operating System: Linux
PHP Version: 4.3.3
New Comment:
We've fixed it be commenting line 421 of ext/standard/html.c:
420-{ '\'', "'", 6, ENT_HTML_QUOTE_SINGLE },
421:/* { '\'', "'",5, ENT_HTML_QUOTE_SINGLE }, */
Previous Comments:
[2003-10-20 17:53:29] acm at tweakers dot net
Description:
When you call get_html_translation_table, with the ENT_QUOTES
parameter, it'll return ' for '
The code for ' should, of course, be '
This was not broken in 4.3.1, so is newly introduced in either 4.3.2 or
4.3.3
One wonders how this could occur, since both
htmlspecialchars/htmlentities and html_entity_decode work correctly.
Reproduce code:
---
Expected result:
Array
(
[&] => &
["] => "
['] => '
[<] => <
[>] => >
)
Actual result:
--
Array
(
[&] => &
["] => "
['] => '
[<] => <
[>] => >
)
--
Edit this bug report at http://bugs.php.net/?id=25927&edit=1
#15333 [Com]: strndup access violation
ID: 15333 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: IIS related Operating System: Windows 2000 Pro PHP Version: 4.3.0-dev New Comment: We had the same "php4ts!zend_strndup + 0x2B + 0xA05CB1AD." error on our win2k server iis5 and php4.2.1. Stan.nospam, and maybe others as well mentioned about setting isapi filters. We added an isapi filter pointing to the same php4isapi.dll as in the apps mappings. The application which was hanging every 5 minutes before, didn't hang since (which is for 4 days now) Previous Comments: [2002-11-27 09:16:04] [EMAIL PROTECTED] Same issue, and even worse: since the last MS updates (IIS, SQL, MDAC), I get a bunch of access violations that I almost never got before. And running manually php.cgi causes the script to quit at the first SQL request, without warning/errors. It says 'missing cgi headers' when running under php-cgi. I tried 4.3.0RC1, 4.3.0-dev, 4.4.0-dev (yesterday's snapshots), all the same result. Any PHP developper using a dual cpu Win2K platform could test/fix this? [2002-11-20 14:30:05] [EMAIL PROTECTED] Add me to the list of people experiencing this. After a little while of switching back and forth from AV to working it goes to not responding at all. :-( [2002-11-18 18:10:24] [EMAIL PROTECTED] Hi.. i have been working on this a couple of days for now, and here are some facts i noticed after a couple of work-arounds... - the error occurs only on systems with Win2K (SP >= 2) - the error WILL NOT occur if logged in as system administrator, and the IIS security is turned to LOW !! - the error will occur on EACH request if you fronpage extensions installed, and a global.asa file exists on the root . - please keep us informed of a solution thanks... http://www.snip.com.ua [2002-11-07 10:01:14] [EMAIL PROTECTED] attachment to previous message: >> There is a curious connection: >> Under applications-configuration... also not the best.., dit crash aniway. [2002-11-06 12:52:54] [EMAIL PROTECTED] I get same error but also with different function: php4ts!zend_strndup + 0x2B + 0xA05D8578 php4ts!zend_hash_copy + 0x1B + 0xA05D8578 There is a curious connection: Under applications-configuration (i do not now the english correct name) (where to install php4isapi.dll) Dlg-page: applications-options (seems concerning ASP) After deselecting "Buffer", IIS run very stable with no more interruption. Mayby tray also.. 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/15333 -- Edit this bug report at http://bugs.php.net/?id=15333&edit=1
Bug #15561 Updated: make install fails to copy libphp4.so
ID: 15561 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Compile Failure Operating System: AIX 4.3.3 PHP Version: 4.1.1 New Comment: I have the same problem with AIX 4.2.1, Apache 1.3.24 and PHP 4.1.2 (and PHP 4.0.4pl1). I'm using gcc 2.95.2, GNU-make 3.79.1, bison 1.35, and the standard AIX ld. The problem also occurred when using the standard AIX make, and without bison. Just copying libphp4.so.0 to /usr/local/apache/libexec/libphp4.so made PHP working from within Apache. Previous Comments: [2002-02-28 09:02:37] [EMAIL PROTECTED] I have the same problem, on the same platform using the same PHP version, and reproducible for PHP 4.1.2 as well. I used the same work around for the 'make-install' issue (cp ./.libs/* ./libs), and have the same problem on server-startup. I got some more information when I discovered that in my case, iPlanet is recieving signal 11/segmentation fault and trying to dump core when it 'hangs'. It's the uxwdog process that restarts it/keeps it from crashing, giving the impression that the server is 'frozen'. In order to get a core file and some more info: Make sure the account you are running the server as, can write to "/usr/netscape/server4/https-/config/core". By default, the core file should be located there. Make sure that the filesystem this dir is in has enough space for a corefile. Make sure there is no limit set for dumping core for the user-id the server is running under, by checking the users stanza in '/etc/security/limits' (set core=-1). start the httpd manually (instead of using the 'start' script) by doing: cd /usr/netscape/server4/bin/https/bin ./ns-httpd -d /usr/netscape/server4/https-/config Also, check the aix error log for messages by doing: errpt -a | more If you are running syslog, check that logfile too for messages from uxwdog. [2002-02-21 10:18:09] [EMAIL PROTECTED] I have copied libphp4.a, libphp4.la, and libphp4.so.0 from the .libs directory to the libs/ directory. Renaming libphp4.so.0 to libphp4.so. Then run make install, the install goes fine after this and copies the binaries around. Is this ok to do? iPlanet is still hanging when I go to a page as it was with php 4.0.6. Thanks, Chris [2002-02-21 03:53:35] [EMAIL PROTECTED] I guess this is PHP's fault. It seems libphp4.a is collect shared lib name for AIX. (not?) [2002-02-20 15:16:43] [EMAIL PROTECTED] AIX uses lib*.a for shared libraries as well as static archives, so the *.so file isn't supposed to be installed, rather it is archived into the lib*.a file. [2002-02-15 18:03:33] [EMAIL PROTECTED] This is not PHP problem, but a bug in libtool. Please report it to the friendly gnu people. --Jani 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/15561 -- Edit this bug report at http://bugs.php.net/?id=15561&edit=1
