#45996 [Asn]: libxml2 2.7.1 causes breakage with character data in xml_parse()
ID: 45996 Updated by: [EMAIL PROTECTED] Reported By: phpbugs at colin dot guthr dot ie Status: Assigned Bug Type: XML related Operating System: Mandriva Linux PHP Version: 5.2.6 Assigned To: rrichards New Comment: Rob, do you have a test case for the regression caused by my test patch, so I can look at that further? Previous Comments: [2008-11-04 21:00:18] [EMAIL PROTECTED] This is still being worked on. Currently the only options are to build PHP with libxml2 = 2.6.32 or build ext/xml with expat. [2008-11-04 20:35:18] rolysatch at hotmail dot com yes i've been struggling with this issue for some time, has anyone discovered a solution yet? [2008-11-03 23:16:48] hjthring at lavabit dot com any suggestions on how one could go about upgrading cms code to avoid this issue ?? Hayden. [2008-10-31 14:45:23] sunil at truesparrow dot com I am also facing the same problem on redhat 5 server.I have php 5.2.6 and libxml 2.7.2 Any updates on the bug? Thanks, Sunil [2008-10-30 18:19:16] phpbugs at hm2k dot org This problem is also documented here... http://social.microsoft.com/Forums/en-US/writerbeta/thread/62ad697b-ed19-4b0b-ae6a-32bec06b142b/ 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/45996 -- Edit this bug report at http://bugs.php.net/?id=45996edit=1
#45996 [Asn]: libxml2 2.7.1 causes breakage with character data in xml_parse()
ID: 45996 Updated by: [EMAIL PROTECTED] Reported By: phpbugs at colin dot guthr dot ie Status: Assigned Bug Type: XML related Operating System: Mandriva Linux PHP Version: 5.2.6 Assigned To: rrichards New Comment: So far as I can tell the only problem here is that libxml2 is bailing in parser.c:xmlParseReference() because the ctxt-wellFormed flag is cleared. It is set to zero by compat.c, which seems simply wrong; xmlCreate*ParserContext initialize it to non-zero. If I apply this patch it works fine: http://people.apache.org/~jorton/php-5.2.6-xmlwformed.patch Rob? Previous Comments: [2008-10-16 14:56:03] mike at kogan dot org Nevermind we got it - libexpat is in and workaround is fine. Thanks again and happy coding! [2008-10-16 02:01:00] mike at Kogan dot org Thanks Col - unfortunately after thrashing on this for a day I either have gotten libexpat built in and it hasn't worked, or my efforts to build it into Apache2 have not worked. How can I tell once I've rebuilt apache whether it's in or not? Will it show up on phpinfo? I see libexpat.so on the system and configured apache --with-expat=builtin and tried using the expat on the system but I'm not sure if it's actually getting there. Sorry in advance if this is not the place to ask such a question but googling libexpat has not been fruitful. [2008-10-15 09:02:54] phpbugs at colin dot guthr dot ie Mike, it's fairly easy to recompile PHP with the libexpat library for the legacy XML parsing functions while keeping libxml2 for the more modern ones. We did that in the Mandriva package for our 2009.0 release after I reported the bug. See the SPEC file here: http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/updates/2009.0/php/current/SPECS/php.spec?revision=291141view=markup The particular change that worked around it is here: http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/updates/2009.0/php/current/SPECS/php.spec?r1=278891r2=281822 I'm sure you can work out how to get the needed patch that is mentioned by navigating the webcvs :) You should be able to use this to recompile the CentOS PHP package accordingly. Hope this helps. Col [2008-10-15 00:04:01] mike at kogan dot org I also have run into this - we had some legacy php code on the xml_parser that was fine on some centos 4 servers with php4 and 5 running apache 1.3. We've been debugging this failure for a day now on our new centos 5 server running php5 and libxml2 2.7.2, and we confirm the same problem. The characterHandler is not called for the known entities so scripts depending on this (rss feed converters etc) emit flawed html. I agree there's much better ways to parse XML but this is legacy stuff thats somewhat pervasive and we didn;t choose what these folks used for their apps. I'd love to rebuild their server with an older libxml2 but am not sure how to go backwards without causing some other problem. Customer has cpanel/whm and all that hooey and I'd rather not create a mess on their new server. Hope ya'll fix this soon as it is an issue on the cpanel folks that have 2.7.2 in their stable branch for centos 5 that is being spread by their updater. If someone can give me a pointer that a straightup build and install of the old release code wont make things worse I'll take a crack at moving their server back. [2008-10-08 09:50:16] phpbugs at colin dot guthr dot ie Yes, I suspect that the comments left by ptn at post dot cz are incorrect when they say it is fixed in libxml. rrichards has given a very complete explanation of the problem and it is more fundamental than a simple bug. Compiling PHP with libexpat is the correct workaround for now. 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/45996 -- Edit this bug report at http://bugs.php.net/?id=45996edit=1
#32979 [Asn-Csd]: socket stream opened with stream_socket_client doesnt work with stream_select
ID: 32979 Updated by: [EMAIL PROTECTED] Reported By: mjpph at stardust dot fi -Status: Assigned +Status: Closed Bug Type: Streams related Operating System: Linux (Fedora Core 3) PHP Version: 5CVS-2006-01-18 (dev) Assigned To: wez New Comment: 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. This is fixed in CVS, xp_ssl.c revision 1.36, thanks to stotty@ for the patch. I've backported it to 5.3.x; will backport to 5.2.x if it's OK with the RM too. Previous Comments: [2008-03-29 10:01:48] stotty at tvnet dot hu Joe Orton has analyzed the bug and found the root cause, see here: http://marc.info/?l=php-internalsm=120522857529781w=2 [2007-10-08 06:03:08] roberto at spadim dot com dot br without openssl everythink work ok now, socket and stream where could i send .php files to develop team check it? [2007-10-08 05:37:14] roberto at spadim dot com dot br the problem occur with php 5.2.4 [2007-10-08 05:32:50] roberto at spadim dot com dot br i'm having the same problem with xeon quad core (prolian HP) on linux socket_select work ok but stream_select don't work i will recompile php without openssl and check what happen [2006-08-25 19:19:54] stotty at tvnet dot hu Bug is still present in 5.1.4 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/32979 -- Edit this bug report at http://bugs.php.net/?id=32979edit=1
#36208 [Fbk-Csd]: Symbols in libphp5.so conflict with symbols in libgd.so and cause apache probs
ID: 36208 Updated by: [EMAIL PROTECTED] Reported By: hb at gentoo dot x256 dot org -Status: Feedback +Status: Closed Bug Type: Dynamic loading Operating System: Gentoo Linux x86 PHP Version: 5.1.2 New Comment: 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. Thanks a lot for the patch Jakub, committed to HEAD/5.1. Previous Comments: [2006-02-01 13:16:44] jakub at gentoo dot org patch for 5.0.5: http://bugs.gentoo.org/attachment.cgi?id=78638 patch for 5.1.2, adding 6 additional compatibility symbols exported by libgd: http://bugs.gentoo.org/attachment.cgi?id=78639action=view Reference Gentoo bug: http://bugs.gentoo.org/show_bug.cgi?id=120908 Should be backported to 4.4.x as well, but that's really upstream job. ;) [2006-02-01 12:05:33] [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. [2006-02-01 11:05:01] hb at gentoo dot x256 dot org Sorry, as I said, I spent over a day tracking down this problem. I submitted a bug report to Gentoo and they told me it was not their problem and that it should be fixed in PHP, which seemed somewhat reasonable. Then I was told that it had to be configured differently, which would require a change in Gentoo, but this problem would remain in other distributions. I just want to fix it so that other people don't have to go through what I did. I will try to make a patch. [2006-02-01 09:16:40] [EMAIL PROTECTED] There is no need to use this kind of language, it will not make us help you faster. That said, we actually do namespace protect those symbols in there by prefixing them with php_gd_. It seems however that some of them are not added yet, see the file main/php_compat.h. Feel free to submit a patch for that file. [2006-02-01 05:33:10] hb at gentoo dot x256 dot org This is a problem with PHP. You can't just tell me to compile it differently because in the real world, when actual users compile and install perl and PHP, they won't know this. There's no warning that I ever saw that tells me not to do this, and then my programs randomly crash, and I spent a whole day trying to work out why. This WILL happen to other people unless you fix YOUR bug, which is exporting non-standard GD symbols with standard names into the dynamic linker namespace. They should be renamed or hidden or set to a different version so they won't collide with the real GD. I guess if you're unwilling to fix it I'll have to get the Gentoo people to either patch PHP or change the portage system so it won't install PHP and mod_perl simultaneously with USE=gd. However, this has the possibility of biting people in other circumstances too. I can't understand why you say it's not your problem. You shouldn't export symbols willy-nilly especially when you modify them from the library you pulled them from originally and don't rename them. 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/36208 -- Edit this bug report at http://bugs.php.net/?id=36208edit=1
#35546 [Bgs]: Content-Length
ID: 35546 Updated by: [EMAIL PROTECTED] Reported By: vitaliy dot okulov at gmail dot com Status: Bogus Bug Type: Apache2 related Operating System: Linux PHP Version: 5.1.1 New Comment: Actually it's a 2.x bug, see: http://issues.apache.org/bugzilla/show_bug.cgi?id=18757 for a patch. Previous Comments: [2005-12-04 22:08:40] [EMAIL PROTECTED] That's because HTML pages are static, but PHP are dynamic ones and neither Apache, nor PHP can't tell you the lenght of the page before it gets out. [2005-12-04 18:27:28] vitaliy dot okulov at gmail dot com Description: Content-Length bug with php scripts. I create simple script. Then just send HEAD request to my WebServer: HEAD -aUuSsx 'http://blabla/media/test2.php' LWP::UserAgent::new: () LWP::UserAgent::request: () LWP::UserAgent::send_request: HEAD http://blabla/media/test2.php LWP::UserAgent::_need_proxy: Not proxied LWP::Protocol::http::request: () LWP::UserAgent::request: Simple response: OK HEAD http://blabla/media/test2.php User-Agent: lwp-request/2.06 As you see there is no Content-Length field. But if i request .html file or something other like gif or jpeg i can see Content-Length header in response. Reproduce code: --- ? phpinfo(); ? Expected result: HEAD http://blabla/media/test2.php -- 200 OK Connection: close Date: Sun, 04 Dec 2005 16:56:31 GMT Server: Apache Content-Language: ru Content-Length: 17 Content-Type: text/html Client-Date: Sun, 04 Dec 2005 16:56:31 GMT Client-Peer: 10.0.0.1:80 Client-Response-Num: 1 Actual result: -- HEAD http://blabla/media/test2.php -- 200 OK Connection: close Date: Sun, 04 Dec 2005 16:56:31 GMT Server: Apache Content-Language: ru Content-Type: text/html Client-Date: Sun, 04 Dec 2005 16:56:31 GMT Client-Peer: 10.0.0.1:80 Client-Response-Num: 1 -- Edit this bug report at http://bugs.php.net/?id=35546edit=1
#35465 [Asn-Bgs]: link error Text relocation remains
ID: 35465
Updated by: [EMAIL PROTECTED]
Reported By: rusty at socrates dot berkeley dot edu
-Status: Assigned
+Status: Bogus
Bug Type: Compile Failure
Operating System: solaris 9
PHP Version: 5.1.1
Assigned To: sniper
New Comment:
This is the expected failure from trying to link non-PIC code into a
shared library on most platforms. If you really insist on using a
static MySQL library you must rebuild it with -fPIC in CFLAGS.
If it worked previously I'd guess it was only because the static
libmysql.a wasn't being found.
Previous Comments:
[2005-11-29 23:35:03] rusty at socrates dot berkeley dot edu
Yes, almost all of my add-on libraries are .a files because long ago I
used to have problem with .so ones. Plus, I like to find out about any
missing symbols at compile time, not run time, which was part of the
problem I used to have.
[2005-11-29 22:58:14] [EMAIL PROTECTED]
See also bug #35475
[2005-11-29 17:19:13] rusty at socrates dot berkeley dot edu
Yes, it compiles with
./configure --disable-all --with-apxs2=/${WWWROOT}/bin/apxs
[2005-11-29 09:25:56] [EMAIL PROTECTED]
Does this work:
# rm config.cache
# ./configure --disable-all --with-apxs2=/${WWWROOT}/bin/apxs
# make clean ; make
Also you shouldn't need to use these options because they either don't
even exist or configure handles them for you automatically:
--enable-inline-optimization (it's enabled by default)
--enable-libgcc (detected automatically when needed)
--enable-trans-sid (has not existed for years)
--with-tsrm-pthreads (detected automatically)
[2005-11-29 03:17:47] rusty at socrates dot berkeley dot edu
Description:
At the final linking stage I get thousands of lines like the following
(at the end of this message). My configure wrapper shell script is
configure \
--prefix=${WWWROOT} \
--enable-bcmath \
--enable-inline-optimization \
--enable-libgcc \
--enable-track-vars \
--enable-trans-sid \
--with-apxs2=/${WWWROOT}/bin/apxs \
--with-config-file-path=${WWWROOT}/conf \
--with-gmp \
--with-ldap=${LOCAL} \
--with-mysql=${MYSQLROOT} \
--with-openssl=${LOCAL} \
--with-tsrm-pthreads
With php 5.0.5 it compiles without a squeek.
Here's the start of the error output; thousands of lines like this
(about 94,000) for many/all of the libraries:
Text relocation remains referenced
against symbol offset in file
unknown 0x570
/local_a/servers/mysql/lib/mysql/libmysqlclient.a(libmysql.o)
unknown 0x574
/local_a/servers/mysql/lib/mysql/libmysqlclient.a(libmysql.o)
unknown 0x578
/local_a/servers/mysql/lib/mysql/libmysqlclient.a(libmysql.o)
unknown 0x57c
/local_a/servers/mysql/lib/mysql/libmysqlclient.a(libmysql.o)
unknown 0x580
/local_a/servers/mysql/lib/mysql/libmysqlclient.a(libmysql.o)
--
Edit this bug report at http://bugs.php.net/?id=35465edit=1
#34435 [Opn]: segmentation fault on object serialize
ID: 34435 Updated by: [EMAIL PROTECTED] Reported By: voxus at mail dot ru Status: Open Bug Type: Reproducible crash Operating System: Gentoo Linux PHP Version: 5CVS-2005-09-09 New Comment: Eh? The warning shows *precisely* why the code is broken on LP64 platforms. Reporter, can you try this patch. http://people.apache.org/~jorton/php_bug34435.patch Previous Comments: [2005-09-09 13:38:11] voxus at mail dot ru reproducible with today's snapshot too. [2005-09-09 13:36:39] [EMAIL PROTECTED] Just ignore those warnings. They are just warnings and have nothing to do with the issue. You'd better provide more info and/or access to the server where it's reproducible. [2005-09-09 12:51:24] etnu at etnu dot org Experiencing the exact same problem with an identical configuration, just using Apache 2.0.54 instead of 2.0.52. Same hardware though; running under Debian 3.1 (Sarge) export CFLAGS=-O2 ./configure \ --with-tidy \ --with-apxs2=/usr/local/apache2/bin/apxs \ --with-mysql=/usr --with-mysqli=/usr/bin/mysql_config \ --prefix=/usr/local/apache2/php \ --with-config-file-path=/usr/local/apache2/php \ --enable-force-cgi-redirect \ --disable-magic-quotes \ --with-gd --with-jpeg-dir=/usr/lib --with-png-dir=/usr/lib \ --with-freetype-dir=/usr/lib --with-zlib-dir=/usr/lib I actually get compiler warnings with this configuration: /usr/src/php-5.0.5/ext/sqlite/libsqlite/src/func.c: In function `minmaxFunc': /usr/src/php-5.0.5/ext/sqlite/libsqlite/src/func.c:38: warning: cast from pointer to integer of different size /usr/src/php-5.0.5/ext/sqlite/libsqlite/src/func.c: In function `minmaxStep': /usr/src/php-5.0.5/ext/sqlite/libsqlite/src/func.c:525: warning: cast from pointer to integer of different size /usr/src/php-5.0.5/ext/standard/var.c: In function `php_var_serialize_class_name': /usr/src/php-5.0.5/ext/standard/var.c:515: warning: passing arg 3 of `zend_get_object_classname' from incompatible pointer type An identical build of 5.0.4 yields no warnings at all. I'm seeing seg faults whenever serializing or unserializing any object. [2005-09-09 12:07:54] m at aptual dot fi I'm not sure what you mean exactly with platform, but like I said before, I'm using Apache 2.0.52, an SMP kernel version 2.6.8 (x86_64) and gcc version 3.3.4. The glibc6 version is 2.3.2. To be more precise, the machine is a Dual Opteron box, and it is running on Ubuntu Linux (Warty). However, both Apache and PHP have been compiled from sources. Oh, and Apache uses the Prefork MPM, which should be (and has been, so far) safe to use with PHP. And just like with the initial poster, this problem doesn't occur on, for example, PHP 5.0.3. I noticed this during a normal upgrade, when an application stopped working immediately after trying the new version. [2005-09-09 11:33:21] voxus at mail dot ru btw, what platform you're using, m? 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/34435 -- Edit this bug report at http://bugs.php.net/?id=34435edit=1
#33299 [Fbk]: php:function no longer handles returned dom objects
ID: 33299
Updated by: [EMAIL PROTECTED]
Reported By: clicknmix at gmail dot com
Status: Feedback
Bug Type: XSLT related
Operating System: Linux
PHP Version: 5.0.4
New Comment:
Rob asked me to look at this...
it looks like the variables are not declared properly in
ext/dom/xml_common.h.
#define PHP_DOM_EXPORT(__type) PHPAPI __type
...
PHP_DOM_EXPORT(zend_class_entry *) dom_node_class_entry;
results in
zend_class_entry *dom_class_entry;
rather than the desired
extern zend_class_entry *dom_class_entry;
when included by xsltprocessor.c. The former just defines a new global
variable in the BSS which is not going to work at all. I'm testing a
patch.
Previous Comments:
[2005-06-19 23:19:17] jon at dsvr dot co dot uk
On a hunch, I patched the .spec file from the Redhat-provided RPM to
build XSL and DOM support statically, instead of as a shared library,
and this test fragment of code works.
I hope the debugging I've done gives someone with a bit more knowledge
of this code enough information to get this cracked.
[2005-06-19 16:54:07] jon at dsvr dot co dot uk
In fact, something quite strange appears to be happening.
instanceof_function is called from xsltprocessor.c:281. At this point
dom_node_class_entry is not null.
At a breakpoint in instanceof_function (zend_operators.c:1581),
instance_ce and ce are equal (we can see therefore that this test
should go on to succeed).
instanceof_function calls instanceof_function_ex. At a breakpoint in
this function, (zend_operators.c:1560), instance_ce has apparently been
passed correctly, but ce is now null, and the function goes on to return
0.
Looks like there could be some stack breakage going on here. Any
suggestions welcome.
[2005-06-19 16:38:56] jon at dsvr dot co dot uk
I've done a bit more digging and poking with gdb.
It looks to be the case that when instanceof_function is called from
xsltprocessor.c:281, zend_class_entry *ce is NULL, and so the
instanceof test fails. Something seems wrong with
dom_node_class_entry.
[2005-06-17 17:41:46] jon at dsvr dot co dot uk
The following code:
function myxml ($Value=default)
{
$dom = new domdocument();
$dom-loadXML(rootthis is from an external
DomDocument - $Value/root);
return $dom;
}
print debug_zval_dump(myxml(''));
yields:
object(DOMDocument)#1 (0) refcount(1){
}
I haven't yet managed to get gdb attached happily to this build of PHP;
having trouble with loadable modules.
It's worth noting that the stock PHP 5.0.4 that comes with Fedora Core
4 demonstrates this problem, if anyone's looking for basic install to
test with.
[2005-06-15 17:37:56] [EMAIL PROTECTED]
Taking XSL out of the equation, what is returned directly from the
calling the myxml function? I cant reproduce this either (tested on
linux and windows). If the myxml function works, try building in debug
mode and set a breakpoint in the xsl extension to find out what type of
object it thinks is being returned there.
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/33299
--
Edit this bug report at http://bugs.php.net/?id=33299edit=1
#31594 [Opn-Bgs]: virtual(): Unable to include 'xxx' - error finding URI
ID: 31594 Updated by: [EMAIL PROTECTED] Reported By: per at computer dot org -Status: Open +Status: Bogus Bug Type: Apache2 related Operating System: linux 2.4.26 PHP Version: 5.0.4, 4.3.11 New Comment: I can reproduce this only with the setlocale call enabled, and see a no acceptable variant error in error_log. Locale settings are process-global and changing them are quite likely to break other Apache modules doing e.g. case-sensitive string comparisons. So, I think the resolution for this bug should be simply don't do that. Previous Comments: [2005-04-16 08:59:31] per at computer dot org Just checked with 4.3.11 - problem is still there. [2005-01-23 10:23:46] per at computer dot org It's content negotiation. You need mod_negotiation and Options +Multiviews for the directory. I've just tried turning off Multiviews and virtual() then produces Warning: virtual(): Unable to include 'part1' - request execution failed in as expected. [2005-01-22 15:14:20] [EMAIL PROTECTED] How exactly do I have to configure Apache2 to be able to use virtual() without the .php (or like you do, without .phtml) suffix?? Apart from that, when I change the parameter to virtual to be correct, your example works just fine with latest CVS checkout regardless of what locale is in use.. [2005-01-18 17:32:23] per at computer dot org I see no 406 codes (no acceptable variant) in the regular log and no such entries in the error_log either. I'm changing the locale such that e.g. strftime() will display dates in danish for instance. As I said, this application works fine with 4.3.8, so it would appear that something got regressed somewhere. [2005-01-18 16:14:45] [EMAIL PROTECTED] Do you get a no acceptable variant message logged to the httpd error_log? Changing the locale can make functions like strcasecmp behave in unexpected ways and hence random stuff can fail. Why do you need to change the locale? 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/31594 -- Edit this bug report at http://bugs.php.net/?id=31594edit=1
#33002 [Bgs]: IMAP PHP connection crash Apache 2
ID: 33002
Updated by: [EMAIL PROTECTED]
Reported By: netadmin at vcsn dot com
Status: Bogus
Bug Type: IMAP related
Operating System: Linux 2.4.29
PHP Version: 4.3.11
New Comment:
We've seen this before, it's a bug in how Slackware build nss_db:
#1 0x409f4e1e in db_open () from /lib/libnss_db.so.2
#2 0x409f4ed0 in internal_setent () from /lib/libnss_db.so.2
#3 0x409f390e in _nss_db_endprotoent () from /lib/libnss_db.so.2
#4 0x409f3b78 in _nss_db_getprotobyname_r () from /lib/libnss_db.so.2
that means that nss_db.so is built using a non-unique-name-ified
version of BDB, which is doomed to failure. You should report this bug
to the Slackware maintainers.
Previous Comments:
[2005-05-11 08:11:08] netadmin at vcsn dot com
It is not **obvious** to me- isn't it possible for PHP to return data
that could 'cause a crash subsequently?? It would really be more
helpful if you could point me to what you see **is** 'causing the crash
so I can test and report back.
[2005-05-11 01:27:34] [EMAIL PROTECTED]
The crash obviously happens outside PHP code - not PHP bug.
[2005-05-10 23:00:26] netadmin at vcsn dot com
Description:
I've seen some postings about this problem but it appears the issue is
never followed up and thus gets closed- so I'm posting it again since
this is a high priority issue for me:
My environment is Apache 2.0.54 (I have also tried .47 and .49), PHP
4.3.11 (I have also tried, .1, .5, .8, and .10), Horde's IMP product
(version 3.2.1 and version 4 with the appropriate Horde version
respectively), Postgres 8.0.2 (migrated from 7.1.2- all data is intact
and I do see database connections) and the UW c-client (built from 4.58
and 4.63). The OS is Linux 2.4.29 (upgrade slackware 8 disto).
PHP appear's (I think) to be SIGSEGV'ing Apache when IMAP is being
used. Here is the gdb output that I get with different combinations of
the version's I specified about [inserted below]
(note that the last version I tried was .5 but I will repeat
with the lastest snapshot if requested since it also faulted)
Reproduce code:
---
As posted in a previous bug report, the following script will fault and
generate a SIGSEGV in an Apache process and log it:
?php
$mbox=imap_open({127.0.0.1:143}INBOX, demo, x);
?
Expected result:
I actually am not sure since I borrowed the code and I'm not a PHP
programmer. The way I was diagnosed the problem was by using my
sniffer to watch port 143 connections. I would expect to see a
connection to the IMAP server is things were working properly.
Actual result:
--
This GDB was configured as i686-pc-linux-gnu...Using host
libthread_db library /lib/libthread_db.so.1.
(gdb) run -DONE_PROCESS -DSSL
Starting program: /www2/bin/httpd -DONE_PROCESS -DSSL
[Thread debugging using libthread_db enabled]
[New Thread 1024 (LWP 12274)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 12274)]
0x in ?? ()
(gdb) bt
#0 0x in ?? ()
#1 0x409f4e1e in db_open () from /lib/libnss_db.so.2
#2 0x409f4ed0 in internal_setent () from /lib/libnss_db.so.2
#3 0x409f390e in _nss_db_endprotoent () from /lib/libnss_db.so.2
#4 0x409f3b78 in _nss_db_getprotobyname_r () from /lib/libnss_db.so.2
#5 0x403a647f in __getprotobyname_r (name=0x40767d84 tcp,
resbuf=0x403d9b48, buffer=0x83fd720 [EMAIL PROTECTED], buflen=1024,
result=0xbfff6528)
at ../nss/getXXbyYY_r.c:200
#6 0x403a632d in getprotobyname (name=0x40767d84 tcp) at
../nss/getXXbyYY.c:145
#7 0x406e838a in tcp_socket_open (family=2, adr=0x8442d50, adrlen=4,
port=143, tmp=0xbfff671c
\221+D\b|[EMAIL PROTECTED]@|[EMAIL PROTECTED]@\n,
ctr=0xbfff6718, hst=0x8442d45 vcsn.com) at tcp_unix.c:225
#8 0x406e81ee in tcp_open (host=0xbfff6fec vcsn.com, service=0x0,
port=143) at tcp_unix.c:184
#9 0x406f9913 in net_open_work (dv=0x407c53c0, host=0xbfff6fec
vcsn.com, service=0xbfff736e imap, port=143, portoverride=143,
flags=0)
at mail.c:5967
#10 0x406f8113 in net_open (mb=0xbfff6fec, dv=0x0, port=143, ssld=0x0,
ssls=0x407ab92c *imaps, sslp=993) at mail.c:5938
#11 0x4070a652 in imap_open (stream=0x8442a98) at imap4r1.c:823
#12 0x406ed6f9 in mail_open (stream=0x8442a98, name=0x83f9364
{vcsn.com:143/imap/notls}, options=0) at mail.c:1217
#13 0x405e25fb in php_imap_do_open (ht=4, return_value=0x8397c4c,
this_ptr=0x0, return_value_used=1, persistent=0)
at /root/src/INSTALLED/php-4.3.5/ext/imap/php_imap.c:734
#14 0x405e26a9 in zif_imap_open (ht=4, return_value=0x8397c4c,
this_ptr=0x0, return_value_used=1)
at /root/src/INSTALLED/php-4.3.5/ext/imap/php_imap.c:755
#15 0x406d88d3 in execute (op_array=0x846474c) at
/root/src/INSTALLED/php-4.3.5/Zend/zend_execute.c:1623
#32797 [Opn-Csd]: Compile fails with xml_element.c: my_free using gcc 4
ID: 32797
Updated by: [EMAIL PROTECTED]
Reported By: JClawson at tamu dot edu
-Status: Open
+Status: Closed
Bug Type: Compile Failure
Operating System: * (with GCC 4 only)
PHP Version: 5.0.4
New Comment:
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.
This is invalid C code; allowing cast-as-lvalue is an extension to C
which has been deprecated (and has triggered warnings) since gcc 3.4.
Fixed on HEAD, will backport shortly.
Previous Comments:
[2005-04-22 09:14:41] [EMAIL PROTECTED]
Not everyone will use GCC..ever.
[2005-04-22 08:14:33] JClawson at tamu dot edu
Hmmm... I thought free was supposed to ignore the null pointer. At
least that was my understanding:
Here is a nice table:
http://developer.apple.com/qa/qa2001/qa1259.html
I guess its better to be safe than sorry.
[2005-04-22 07:24:46] [EMAIL PROTECTED]
1) Relying on free() to ignore NULL pointers is not portable: we do
have to support other compilers beside GCC 4
2) Using cast expressions as lvalues has always been supported in C,
but apparently GCC 4 suddenly doesn't support it anymore. In this
particular case, however, we might change the macro so it only does the
cast for the argument to free() , and only for compilers that require
it, i.e. compilers/libc's that define free like free(char*)
[2005-04-22 04:44:12] [EMAIL PROTECTED]
Please lose the attitude; we don't have time for that.
As for PHP; you appear to have the knowledge--submit a working patch
that doesn't break the code.
[2005-04-22 04:10:00] JClawson at tamu dot edu
Oh... Everyone will not be using GCC 3 forever. Don't you think it
would be prudent to correct obvious errors now?
After all if you have the following code:
if((char*)root-name)
{
free((char*)root-name);
(char*)root-name = 0;
}
why would you assign a pointer to 0?
And for whatever reason... why the stupid if statement
Why not just simplify everything with:
free((char*)root-name);
Bam... correct C code. If root-name is NULL thats ok... because free
can take NULL as a paramater!
You don't free somthing and then try to assign an integer to it...
seriously.
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/32797
--
Edit this bug report at http://bugs.php.net/?id=32797edit=1
#32150 [Opn-Csd]: PHP fails to compile with gcc 4.0.0-alpha20050213 snapshot
ID: 32150
Updated by: [EMAIL PROTECTED]
Reported By: amd at store20 dot com
-Status: Open
+Status: Closed
Bug Type: Compile Failure
Operating System: Gentoo GNU/Linux
PHP Version: php5-200503041530
New Comment:
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.
Oh, missed this one. The my_free() problem was fixed this morning,
using exactly the fix you proposed!
Previous Comments:
[2005-03-05 06:54:27] amd at store20 dot com
Used yesterday's CVS snapshot. One problem still existed (xmlrpc).
my_free is just a ugly wrapper to free.
http://amd.store20.com/files/2005-Q1/php5_xmlrpc_gcc4_compile_fix_bug_32150.patch
[2005-03-04 16:42:12] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
..and if (when) it fails, provide the patche(s) against to these source
(CVS HEAD branch) and put them online somewhere where we can download
them. The patches get messed up in this bug system..
[2005-03-01 16:49:04] amd at store20 dot com
After applying these two patches, it built fine.
[2005-03-01 16:38:42] amd at store20 dot com
Another catch:
/bin/sh /var/tmp/portage/php-5.0.3-r1/work/php-5.0.3/libtool --silent
--preserve-dup-deps --mode=compile gcc
-I/var/tmp/portage/php-5.0.3-r1/work/php-5.0.3/ext/xmlrpc/libxmlrpc
-DVERSION=0.50 -Iext/xmlrpc/
-I/var/tmp/portage/php-5.0.3-r1/work/php-5.0.3/ext/xmlrpc/
-DPHP_ATOM_INC -I/var/tmp/portage/php-5.0.3-r1/work/php-5.0.3/include
-I/var/tmp/portage/php-5.0.3-r1/work/php-5.0.3/main
-I/var/tmp/portage/php-5.0.3-r1/work/php-5.0.3
-I/var/tmp/portage/php-5.0.3-r1/work/php-5.0.3/Zend
-I/usr/include/libxml2 -I/usr/include/freetype2 -I/usr/include/imap
-I/var/tmp/portage/php-5.0.3-r1/work/php-5.0.3/ext/mbstring/oniguruma
-I/var/tmp/portage/php-5.0.3-r1/work/php-5.0.3/ext/mbstring/libmbfl
-I/var/tmp/portage/php-5.0.3-r1/work/php-5.0.3/ext/mbstring/libmbfl/mbfl
-I/usr/include/mysql -I/usr/include/pspell
-I/var/tmp/portage/php-5.0.3-r1/work/php-5.0.3/TSRM -O2
-mtune=pentium3 -prefer-pic -c
/var/tmp/portage/php-5.0.3-r1/work/php-5.0.3/ext/xmlrpc/libxmlrpc/xml_element.c
-o ext/xmlrpc/libxmlrpc/xml_element.lo
/var/tmp/portage/php-5.0.3-r1/work/php-5.0.3/ext/xmlrpc/libxmlrpc/xml_element.c:
In function 'xml_elem_free_non_recurse':
/var/tmp/portage/php-5.0.3-r1/work/php-5.0.3/ext/xmlrpc/libxmlrpc/xml_element.c:192:
error: invalid lvalue in assignment
/var/tmp/portage/php-5.0.3-r1/work/php-5.0.3/ext/xmlrpc/libxmlrpc/xml_element.c:
In function 'xml_elem_entity_escape':
/var/tmp/portage/php-5.0.3-r1/work/php-5.0.3/ext/xmlrpc/libxmlrpc/xml_element.c:317:
warning: pointer targets in assignment differ in signedness
/var/tmp/portage/php-5.0.3-r1/work/php-5.0.3/ext/xmlrpc/libxmlrpc/xml_element.c:332:
warning: pointer targets in assignment differ in signedness
make: *** [ext/xmlrpc/libxmlrpc/xml_element.lo] Error 1
Proposed fix:
decoder php-5.0.3 # for i in `ls -1 ext/xmlrpc/libxmlrpc/*.orig`; do
diff -u $i ${i/\.orig/} ; done
--- ext/xmlrpc/libxmlrpc/simplestring.c.orig2005-03-01
17:33:43.0 +0200
+++ ext/xmlrpc/libxmlrpc/simplestring.c 2005-03-01 17:33:47.0
+0200
@@ -85,7 +85,7 @@
#include string.h
#include simplestring.h
-#define my_free(thing) if(thing) {free(thing); thing = 0;}
+#define my_free(thing) if(thing) {free(thing); thing = NULL;}
/*--**
* Begin String Functions *
--- ext/xmlrpc/libxmlrpc/xml_element.c.orig 2005-03-01
17:21:12.0 +0200
+++ ext/xmlrpc/libxmlrpc/xml_element.c 2005-03-01 17:35:20.0
+0200
@@ -189,7 +189,11 @@
Q_Destroy(root-children);
Q_Destroy(root-attrs);
- my_free((char*)root-name);
+// my_free((char*)root-name);
+ if (root-name) {
+ free((char *)root-name);
+ root-name = NULL;
+ }
simplestring_free(root-text);
my_free(root);
}
[2005-03-01 15:46:08] amd at store20 dot com
Proposed fix:
--- Zend/zend_modules.h.orig2005-03-01 16:33:58.0 +0200
+++ Zend/zend_modules.h 2005-03-01 16:44:48.0 +0200
@@ -23,6 +23,7 @@
#define MODULES_H
#include zend.h
+#include zend_compile.h
#define INIT_FUNC_ARGS int type, int module_number TSRMLS_DC
#define INIT_FUNC_ARGS_PASSTHRUtype, module_number TSRMLS_CC
#32672 [Fbk-Bgs]: apache child crash with child pid xy exit signal Segmentation fault (11)
ID: 32672
Updated by: [EMAIL PROTECTED]
Reported By: php at pappert dot biz
-Status: Feedback
+Status: Bogus
Bug Type: MySQLi related
Operating System: Debian 3.1 on AMD64
PHP Version: 5.0.4
New Comment:
Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same.
Thank you for your interest in PHP.
This is bug 32282, which was just fixed in CVS - try a snapshot from
snaps.php.net.
Previous Comments:
[2005-04-11 16:54: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
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.
[2005-04-11 16:43:19] php at pappert dot biz
Description:
System:
mysql-4.1.11
apache-2.0.53
debian-3.1 on AMD64
On every DB connect with $oObject = new mysqli('host', 'user', 'pass')
the apache child (only the child) will crash and the connection will
broke down. You can open any other side on this machine without any
trouble, if it doesn't contain mysqli calls (server is still
available).
Phpinfo() shows the mysql part with the right configuration.
And if I start the script in the code box below on the cli it is
crashing with this message: Segmentation fault!
The Apache Error_log shows:
[XXX XXX XX X] [notice] child pid 32424 exit signal Segmentation
fault (11)
The php log is empty, the mysql log also.
This is my configure command:
./configure --with-config-file-path=/etc --prefix=/usr/local/php-5.0.4
--with-apxs2=/usr/local/apache-2.0.53/bin/apxs
--with-mysqli=/usr/local/mysql/bin/mysql_config
Reproduce code:
---
?php
$o = new mysqli('localhost', 'root', '**', 'mysql');
$r = $o-query('select * from db');
echo $o-error;
while($aRow = $r-fetch_array(MYSQLI_ASSOC))
print_r($aRow);
?
--
Edit this bug report at http://bugs.php.net/?id=32672edit=1
#32613 [Opn]: php --version fails with snmpapp.conf access error
ID: 32613 Updated by: [EMAIL PROTECTED] Reported By: ric at arizona dot edu Status: Open Bug Type: SNMP related Operating System: Solaris 8 PHP Version: 4.3.11 New Comment: I agree this is a regression; you see the spam similarly in the httpd error_log at each shutdown, if it *can't* create the snmpapp.conf since it's not running as root (at least using the net-snmp default paths in Fedora Core). That looks like a good solution, except it will inhibit *reading* the config data as well, which might not be desired? I'm not familiar with this area at all. Previous Comments: [2005-04-11 20:33:55] ric at arizona dot edu After much reading on this, I found the problem to be the snmp_shutdown() call added in php 4.3.11. The fix for the errors this is twofold a) modify php to include netsnmp_ds_set_boolean(NETSNMP_DS_LIBRARY_ID, NETSNMP_DS_LIB_DONT_PERSIST_STATE, 1); in php startup, so the newly added snmp_shutdown call won't try to write data. -AND- b) update to net-snmp-5.2.1 which recognizes the above call. --- [2005-04-07 01:51:42] ric at arizona dot edu I disagree with the its net-snmp's fault response. How can it be net-snmp's problem when php 4.3.10 built with the exact same net-snmp within a couple of hours of building 4.3.11 does not exhibit the problem of trying to write to /var/net-snmp??? Isn't it more likely that there was some change php's use of net-snmp between 4.3.10 and 4.3.11 that triggered this change in behavior? [2005-04-07 00:26:03] [EMAIL PROTECTED] This is not any PHP bug to fix, complain to the net-snmp people about this. There might be some configuration options in the snmp.conf friends to control this behaviour.. [2005-04-06 23:50:41] ric at arizona dot edu Description: Build environment is Solaris 8 with net-snmp5.1. I built php 4.3.11 with ./configure --with-mysql=/usr/local \ --with-openssl=/usr/local/ssl --with-ldap \ --with-apxs=/private/apache/bin/apxs --with-xml --with-pspell \ --with-snmp --with-zlib make The build completed normally, but when I then run $ /dfs/src/solaris/php-4.3.11/sapi/cli/php--version I get PHP 4.3.11 (cli) (built: Apr 6 2005 11:12:09) Copyright (c) 1997-2004 The PHP Group Zend Engine v1.3.0, Copyright (c) 1998-2004 Zend Technologies Cannot rename /var/net-snmp/snmpapp.conf to /var/net-snmp/snmpapp.0.conf Cannot unlink /var/net-snmp/snmpapp.conf read_config_store open failure on /var/net-snmp/snmpapp.conf read_config_store open failure on /var/net-snmp/snmpapp.conf read_config_store open failure on /var/net-snmp/snmpapp.conf On the same computer with the same environment, I built php 4.3.10, and it produces no such errors, viz: $ /dfs/src/solaris/php-4.3.10/sapi/cli/php --version PHP 4.3.10 (cli) (built: Apr 6 2005 14:30:39) Copyright (c) 1997-2004 The PHP Group Zend Engine v1.3.0, Copyright (c) 1998-2004 Zend Technologies 4.3.11 appears to need write access to /var/snmp to be able to rename files and read/write access to snmpapp.conf. Short of making /var/snmp world write, and snmpapp.conf world write is there a way to restore the 4.3.10 behvior which doesn't even require the existance of /var/net-snmp? Thanks Ric Anderson ([EMAIL PROTECTED]) Reproduce code: --- Configure and build 4.3.11 --with-snmp, and then try to run sapi/cli/php --version as a mortal (non-root) user. Expected result: I expect to see the version info e.g. PHP 4.3.11 (cli) (built: Apr 6 2005 11:12:09) Copyright (c) 1997-2004 The PHP Group Zend Engine v1.3.0, Copyright (c) 1998-2004 Zend Technologies Actual result: -- PHP 4.3.11 (cli) (built: Apr 6 2005 11:12:09) Copyright (c) 1997-2004 The PHP Group Zend Engine v1.3.0, Copyright (c) 1998-2004 Zend Technologies Cannot rename /var/net-snmp/snmpapp.conf to /var/net-snmp/snmpapp.0.conf Cannot unlink /var/net-snmp/snmpapp.conf read_config_store open failure on /var/net-snmp/snmpapp.conf read_config_store open failure on /var/net-snmp/snmpapp.conf read_config_store open failure on /var/net-snmp/snmpapp.conf -- Edit this bug report at http://bugs.php.net/?id=32613edit=1
#32526 [Opn-Bgs]: PEAR fails installation
ID: 32526
Updated by: [EMAIL PROTECTED]
Reported By: ktk at enterprise dot bidmc dot harvard dot edu
-Status: Open
+Status: Bogus
Bug Type: Compile Failure
Operating System: Linux Slackware 10.1
PHP Version: 5.0.4
New Comment:
Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same.
Thank you for your interest in PHP.
Duplicate of bug 32525.
Previous Comments:
[2005-04-01 14:13:41] henning dot mohren at gmx dot de
same behaviour on solaris 9
[2005-04-01 03:54:45] ktk at enterprise dot bidmc dot harvard dot edu
Description:
This is relevant to PHP 5.0.4, although that could not be
selected from the bug-reporting version dropdown.
Executing make install fails to install PEAR.
Here's a snippit of the output:
Installing PEAR environment: /tmp/foo/lib/php/
[PEAR] Archive_Tar- already installed: 1.1
[PEAR] Console_Getopt - already installed: 1.2
[PEAR] PEAR: file does not exist
[PEAR] HTML_Template_IT- already installed: 1.1
[PEAR] Net_UserAgent_Detect- already installed: 2.0.1
[PEAR] XML_RPC- already installed: 1.2.2
The directory /tmp/foo/lib/php/PEAR is missing all of the
normal PEAR files.
Reproduce code:
---
./configure --prefix=/tmp/foo
make make install
Expected result:
Normally ${INSTALL_ROOT}/lib/php/PEAR/ contains a variety
of .php files, and ${INSTALL_ROOT}/lib/php/PEAR.php
exists. But in this case, none of the PEAR files are
installed.
--
Edit this bug report at http://bugs.php.net/?id=32526edit=1
#32176 [Fbk]: (OS 10054)An existing connection was forcibly closed by the remote host. : cor
ID: 32176 Updated by: [EMAIL PROTECTED] Reported By: webmaster at sanders-consultation-group-plu Status: Feedback Bug Type: Apache2 related Operating System: Windows 2000 Pro PHP Version: 5.0.3 New Comment: Exactly what problem are you reporting? Just that this message is logged to the error_log when a client aborts a connection (and so, may happen a lot)? That is expected behaviour. Previous Comments: [2005-03-12 14:46:03] [EMAIL PROTECTED] Waiting for feedback..(please don't reply before you have tried the snapshot) [2005-03-10 20:58:10] webmaster at sanders-consultation-group-plu Thanks Sniper, I'll work on that CVS update here over the weekend. Things are a bit hectic to do it today. Thanks for the help. I'll report back once it's completed. [2005-03-09 21:38:55] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip It was said in the bug #25570 that this should be fixed in CVS.. [2005-03-09 04:13:36] webmaster at sanders-consultation-group-plu Thought maybe some of this might help...just trying to help identify what's still causing this problem. Server software environment: Apache version 2.0.52 MySQL version 4.1.10 PostgreSQL version 8.0.0 Openssl version 0.9.7e Slimftpd version 3.16 Xmail version 1.21 Perl version 5.8.6 PHP version 5.0.3 readme Python version 2.3.4 [2005-03-09 04:10:25] webmaster at sanders-consultation-group-plu Done Sniper, restarted the server, and still the following: [Tue Mar 08 21:02:17 2005] [info] (OS 10054)An existing connection was forcibly closed by the remote host. : core_output_filter: writing data to the network [Tue Mar 08 20:59:21 2005] [info] (OS 10054)An existing connection was forcibly closed by the remote host. : core_output_filter: writing data to the network [Tue Mar 08 20:59:21 2005] [info] (OS 10054)An existing connection was forcibly closed by the remote host. : core_output_filter: writing data to the network [Tue Mar 08 20:57:20 2005] [info] (OS 10054)An existing connection was forcibly closed by the remote host. : core_output_filter: writing data to the network [Tue Mar 08 20:57:20 2005] [info] (OS 10054)An existing connection was forcibly closed by the remote host. : core_output_filter: writing data to the network [Tue Mar 08 20:56:59 2005] [info] (OS 10054)An existing connection was forcibly closed by the remote host. : core_output_filter: writing data to the network [Tue Mar 08 20:56:58 2005] [info] (OS 10054)An existing connection was forcibly closed by the remote host. : core_output_filter: writing data to the network [Tue Mar 08 20:54:51 2005] [info] (OS 10054)An existing connection was forcibly closed by the remote host. : core_output_filter: writing data to the network [Tue Mar 08 20:54:29 2005] [info] (OS 10054)An existing connection was forcibly closed by the remote host. : core_output_filter: writing data to the network [Tue Mar 08 20:50:41 2005] [info] (OS 10054)An existing connection was forcibly closed by the remote host. : core_output_filter: writing data to the network [Tue Mar 08 20:50:41 2005] [info] (OS 10054)An existing connection was forcibly closed by the remote host. : core_output_filter: writing data to the network Next question or suggestion? Thanks for the suggestion. 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/32176 -- Edit this bug report at http://bugs.php.net/?id=32176edit=1
#31717 [Asn-Csd]: Cannot turn off PATH_INFO
ID: 31717
Updated by: [EMAIL PROTECTED]
Reported By: stijn at win dot tue dot nl
-Status: Assigned
+Status: Closed
Bug Type: Apache2 related
Operating System: FreeBSD 4 and -CURRENT
PHP Version: 4.3.10
Assigned To: jorton
New Comment:
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.
Thanks, that wasn't quite right in a few ways, I've committed the patch
I had in my tree...
Previous Comments:
[2005-03-03 12:50:17] stijn at win dot tue dot nl
Here is a patch that is *VERY* lightly tested, but which appears to do
the right thing for me (I don't see a place to upload a patch in this
bug tracker, so I copy paste this; beware of whitespace changes).
%%%
--- sapi/apache2handler/sapi_apache2.c.orig Mon Dec 6 19:55:16
2004
+++ sapi/apache2handler/sapi_apache2.c Thu Mar 3 12:46:03 2005
@@ -471,6 +471,12 @@
return DECLINED;
}
+ /* check if we can accept PATH_INFO according to apache config
*/
+ if (r-used_path_info == AP_REQ_REJECT_PATH_INFO
+strlen(r-path_info) != 0) {
+ return HTTP_NOT_FOUND;
+ }
+
if (r-finfo.filetype == 0) {
php_apache_sapi_log_message_ex(script '%s' not found
or unable to stat, r);
zend_try {
%%%
What do you think?
[2005-01-28 06:37:22] [EMAIL PROTECTED]
It doesn't make sense to me that this is the responsibility of the
handler. I see by looking at the code that it is, but it doesn't seem
like a valid place for this to happen. If you configure Apache to not
honour path_info then Apache shouldn't trigger the handler on the
partial path.
[2005-01-27 19:37:51] [EMAIL PROTECTED]
Yes it does, in 2.0 the handler has to honour the r-used_path_info
setting appropriately.
[2005-01-27 18:08:01] [EMAIL PROTECTED]
This has nothing to do with PHP and please don't post support questions
to the bug database.
[2005-01-27 11:23:03] stijn at win dot tue dot nl
Description:
I'm trying to turn the support for PATH_INFO off on a *default* install
of apache-2.0.52 and php-4.3.10, but it doesn't work.
Note that I am not 100% sure that this is a PHP bug, however Apache
does not accept PATH_INFO for regular HTML files so I'm inclined to
suspect PHP.
I first installed Apache in a scratch directory:
./configure --prefix=/var/tmp/apachephp --enable-so --with-mpm=prefork
--enable-maintainer-mode
gmake
gmake install
Then PHP:
env CFLAGS=-g ./configure --prefix=/var/tmp/apachephp
--with-apxs2=/var/tmp/apachephp/bin/apxs --disable-cgi
--disable-path-info-check
gmake
gmake install
I edited /var/tmp/apachephp/conf/httpd.conf and added these lines:
%%%
AddType application/x-httpd-php .php
AcceptPathInfo off
Directory /var/tmp/apachephp/htdocs
AcceptPathInfo off
/Directory
%%%
Adding a simple index.php to the docroot
(/var/tmp/apachephp/htdocs/index.php):
%%%
? phpinfo(); ?
%%%
After starting httpd, I can still browse to
http://localhost/index.php/foo/bar
and see that PATH_INFO indeed contains /foo/bar.
I've tried digging in the sources but I'm not familiar with Apache
plugins. I did see this in gdb:
%%%
Breakpoint 2, php_apache_request_ctor (r=0x81b2050, ctx=0x81b3e70)
at
/local/home/stijn/tmp/php-4.3.10/sapi/apache2handler/sapi_apache2.c:408
408 SG(sapi_headers).http_response_code = !r-status ?
HTTP_OK : r-status;
(gdb) print r-path_info
$1 = 0x81b3253 /foo/bar
(gdb) print r-used_path_info
$2 = 1
%%%
So in the request constructor the path info is already set up? I did
see something about overriding r-path_info for apache modules in the
apache sources but here is where I cannot follow the code anymore...
BTW, I tried to post this to php-general twice, but somehow my e-mail
is blocked. I do hope this is not PEBKAC but even if it is I would be
glad if someone pointed this out to me...
Reproduce code:
---
n/a
Expected result:
n/a
Actual result:
--
see above for a maybe relevant backtrace snippet
--
Edit this bug report at http://bugs.php.net/?id=31717edit=1
#32002 [Opn-Fbk]: FATAL erealloc() Restarts
ID: 32002
Updated by: [EMAIL PROTECTED]
Reported By: tlamay at cte1 dot com
-Status: Open
+Status: Feedback
-Bug Type: Apache2 related
+Bug Type: Unknown/Other Function
Operating System: Windows 2003
PHP Version: 4CVS-2005-02-17
New Comment:
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.
The FATAL message correspond to Zend calling exit(), which kills all
the threads in the process, so that much is expected.
To track down the memory issues you could add to your LogFormat
directive: %{mod_php_memory_usage}n - this will log the maximum
number of bytes allocated during each particular request.
Previous Comments:
[2005-02-22 21:28:44] jonohlsson at hotmail dot com
must say i have this exact problem myself
running win 2k / apache 1.3.33 / php 4.3.10 / Zend optimizer 2.5.7 and
phpBB forum
the apache log is filled with those erealloc errors and the browser
page goes blank with a server not found message
...but i think it only happens if browsing with IE. mozilla works fine.
weird isn't it?
i've also tried changing php.ini memory settings, but this deosn't
affect the apache log at all
[2005-02-17 20:46:17] tlamay at cte1 dot com
Okay, after a bit of tweaking I got the latest PHP5 running. It
crashes within 8-10 minutes. I have since migrated back to 4.3.10, the
most stable version for me at the moment.
Funny thing about the PHP5...when it crashes, Apache doesn't ever
restart. The server stays completely down. I have to physically start
it again. This behavior doesnt occur in 4.3.x.
Thu Feb 17 14:31:26 2005] [notice] Parent: Created child process 6672
[Thu Feb 17 14:31:26 2005] [notice] Disabled use of AcceptEx() WinSock2
API
[Thu Feb 17 14:31:35 2005] [notice] Child 6672: Child process is
running
[Thu Feb 17 14:31:35 2005] [notice] Child 6672: Acquired the start
mutex.
[Thu Feb 17 14:31:35 2005] [notice] Child 6672: Starting 750 worker
threads.
[Thu Feb 17 14:31:35 2005] [notice] Child 6672: Listening on port 443.
[Thu Feb 17 14:31:35 2005] [notice] Child 6672: Listening on port 443.
[Thu Feb 17 14:31:35 2005] [notice] Child 6672: Listening on port 80.
[Thu Feb 17 14:31:35 2005] [notice] Child 6672: Listening on port 80.
FATAL: erealloc(): Unable to allocate 98304 bytes
[Thu Feb 17 14:39:29 2005] [notice] Parent: child process exited with
status 1 -- Restarting.
[2005-02-17 05:25:51] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
Please try the latest HEAD too so we'll see if this is any better there
(some memleak fixes exist there which were not allowed to be backported
to PHP_4_3 branch)
[2005-02-17 05:10:17] tlamay at cte1 dot com
I tried the very latest one, and as what happened when I tried the CVS
before, it actually makes the problem much worse. Apache restarts
every 5-10-15 minutes now versus every 30-45m with PHP 4.3.10.
[Wed Feb 16 21:52:39 2005] [notice] Parent: Created child process 3148
[Wed Feb 16 21:52:39 2005] [notice] Disabled use of AcceptEx() WinSock2
API
[Wed Feb 16 21:52:48 2005] [notice] Child 3148: Child process is
running
[Wed Feb 16 21:52:48 2005] [notice] Child 3148: Acquired the start
mutex.
[Wed Feb 16 21:52:48 2005] [notice] Child 3148: Starting 750 worker
threads.
[Wed Feb 16 21:52:48 2005] [notice] Child 3148: Listening on port 443.
[Wed Feb 16 21:52:48 2005] [notice] Child 3148: Listening on port 443.
[Wed Feb 16 21:52:48 2005] [notice] Child 3148: Listening on port 80.
[Wed Feb 16 21:52:48 2005] [notice] Child 3148: Listening on port 80.
FATAL: erealloc(): Unable to allocate 90112 bytes
[Wed Feb 16 22:03:25 2005] [notice] Parent: child process exited with
status 1 -- Restarting.
[Wed Feb 16 22:03:26 2005] [notice] Parent: Created child process 852
[Wed Feb 16 22:03:26 2005] [notice] Disabled use of AcceptEx() WinSock2
API
[Wed Feb 16 22:03:35 2005] [notice] Child 852: Child process is
running
[Wed Feb 16 22:03:35 2005] [notice] Child 852: Acquired the start
mutex.
[Wed Feb 16 22:03:35 2005] [notice] Child 852: Starting 750 worker
threads.
[Wed Feb 16 22:03:35 2005] [notice] Child 852: Listening on port 443.
[Wed Feb 16 22:03:35 2005] [notice] Child 852: Listening on port 443.
[Wed Feb 16 22:03:35 2005] [notice] Child 852: Listening on port 80.
[Wed Feb 16 22:03:35 2005] [notice] Child 852: Listening on port 80.
FATAL: erealloc():
#32001 [Ver-Asn]: xml_parse_into_struct() function exceeds maximum execution time (object)
ID: 32001
Updated by: [EMAIL PROTECTED]
Reported By: geroxp at web dot de
-Status: Verified
+Status: Assigned
Bug Type: XML related
Operating System: Linux (FC3)
PHP Version: 5CVS-2005-02-17
-Assigned To:
+Assigned To: jorton
New Comment:
The test case is triggering an infinite loop in libxml2; I've proposed
this patch: http://www.apache.org/~jorton/php_xmlenc.diff
Previous Comments:
[2005-02-16 18:08:30] geroxp at web dot de
Description:
When using xml_parse_into_struct() function with an object the
following error occurs:
Fatal error: Maximum execution time of 30 seconds exceeded in
/var/www/html/test.php on line 9
Version-Release number:
php-5.0.3-2
How reproducible:
Always
Reproduce code:
---
?php
class myclass {
var $myparser;
function mytest() {
$this-myparser = xml_parser_create('');
$simple = paranotesimple note/note/para;
xml_parse_into_struct($this-myparser, $simple, $myvals, $mytags);
print_r($myvals);
}
}
$myobject = new myclass;
$myobject-mytest();
?
Expected result:
Output of the xml-structure given as an array.
Actual result:
--
Fatal error: Maximum execution time of 30 seconds exceeded in
/var/www/html/test.php on line 9
--
Edit this bug report at http://bugs.php.net/?id=32001edit=1
#31982 [Opn-Bgs]: child pid $PID exit signal Segmentation fault (11) Apache 2.0.53
ID: 31982 Updated by: [EMAIL PROTECTED] Reported By: taskazan at metu dot edu dot tr -Status: Open +Status: Bogus Bug Type: Apache2 related Operating System: debian-linux PHP Version: 4.3.10 New Comment: 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. Per ASF bugzilla, this is a mod_ldap bug. Previous Comments: [2005-02-15 14:20:08] taskazan at metu dot edu dot tr when we try the latest snapshot, given in the previous link, we saw segmentation fault in the error log again. When we debug the httpd process, again we get following logs: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1024 (LWP 10502)] apr_proc_mutex_child_init (mutex=0x4, fname=0x821ee08 #65533;031\b, pool=0x821ee08) at proc_mutex.c:818 818 proc_mutex.c: No such file or directory. in proc_mutex.c (gdb) bt #0 apr_proc_mutex_child_init (mutex=0x4, fname=0x821ee08 #65533;031\b, pool=0x821ee08) at proc_mutex.c:818 #1 0x4014abd2 in apr_global_mutex_child_init (mutex=0x821ee08, fname=0x821ee08 #65533;031\b, pool=0x821ee08) at global_mutex.c:88 #2 0x0807f986 in util_ldap_child_init (p=0x821ee08, s=0x81d86d0) at util_ldap.c:1615 #3 0x080bb90d in ap_run_child_init (pchild=0x821ee08, s=0x81d86d0) at config.c:150 #4 0x080b901f in child_main (child_num_arg=136441352) at worker.c:1104 #5 0x080b93a6 in make_child (s=0x821ee08, slot=0) at worker.c:1248 #6 0x080b9439 in startup_children (number_to_start=0) at worker.c:1302 #7 0x080b9e7a in ap_mpm_run (_pconf=0x819b4f8, plog=0x81d35d8, s=0x0) at worker.c:1617 #8 0x080c113f in main (argc=2, argv=0xbc64) at main.c:618 [2005-02-15 12:58:40] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip [2005-02-15 11:08:35] taskazan at metu dot edu dot tr Description: We have used php4-apache2 series in our web servers without any problems until last week. This week when we upgrade apache2.0.50 to 2.0.53, httpd processes suddenly get killed by a segfault as seen below in the error_log: Mon Feb 14 17:14:26 2005] [notice] child pid 16788 exit signal Segmentation fault (11) [Mon Feb 14 17:14:26 2005] [notice] child pid 16787 exit signal Segmentation fault (11) [Mon Feb 14 17:14:27 2005] [notice] child pid 16789 exit signal Segmentation fault (11) [Mon Feb 14 17:14:28 2005] [notice] child pid 16802 exit signal Segmentation fault (11) [Mon Feb 14 17:14:28 2005] [notice] child pid 16801 exit signal Segmentation fault (11) [Mon Feb 14 17:14:28 2005] [notice] child pid 16800 exit signal Segmentation fault (11) [Mon Feb 14 17:14:28 2005] [notice] child pid 16791 exit signal Segmentation fault (11) ... There is no core file, so we try to debug httpd process with gdb. Here is the outputs: # gdb /usr/local/httpd-2.0.53/bin/httpd GNU gdb 2002-04-01-cvs Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-linux... (gdb) run -X Starting program: /usr/local/httpd-2.0.53/bin/httpd -X Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1024 (LWP 27979)] apr_proc_mutex_child_init (mutex=0x4, fname=0x821dd98 \xef\xbf\xbd031\b, pool=0x821dd 98) at proc_mutex.c:818 818 proc_mutex.c: No such file or directory. in proc_mutex.c (gdb) bt #0 apr_proc_mutex_child_init (mutex=0x4, fname=0x821dd98 \xef\xbf\xbd031\b, pool=0x821dd98) at proc_mutex.c:818 #1 0x4014abd2 in apr_global_mutex_child_init mutex=0x821dd98, fname=0x821dd98 \xef\xbf\xbd031\b, pool=0x821dd98) at global_mutex.c:88 #2 0x0807f986 in util_ldap_child_init (p=0x821dd98, s=0x81d86d0) at util_ldap.c:1615 #3 0x080bb90d in ap_run_child_init (pchild=0x821dd98, s=0x81d86d0) at config.c:150 #4 0x080b901f in child_main (child_num_arg=136437144) at worker.c:1104 #5 0x080b93a6 in make_child (s=0x821dd98, slot=0) at worker.c:1248 #6 0x080b9439 in startup_children (number_to_start=0) at worker.c:1302 #7 0x080b9e7a in ap_mpm_run
#22463 [Csd-Opn]: array_reduce segmentation fault
ID: 22463
Updated by: [EMAIL PROTECTED]
Reported By: mccannwj at pha dot jhu dot edu
-Status: Closed
+Status: Open
Bug Type: Arrays related
Operating System: redhat-linux-8.0
-PHP Version: 4.3.2-dev
+PHP Version: 4.3.11-dev
New Comment:
With memory corruption checking enabled in libc, this test case still
fails with 4.3-dev (but passes in 5.0-dev and 5.1-dev):
MALLOC_CHECK_=3 gdb --args ./4.3-on-2.0.x/sapi/cli/php -f bug22463.php
...
Program received signal SIGSEGV, Segmentation fault.
call_user_function_ex (function_table=0x8dc1078, object_pp=0x0,
function_name=0x0,
retval_ptr_ptr=0xbff693e4, param_count=2, params=0xbff693e8,
no_separation=0,
symbol_table=0x0) at /local/php/4.3/Zend/zend_execute_API.c:443
443 if (function_name-type==IS_ARRAY) { /* assume
array($obj, $name) couple */
(gdb) where
#0 call_user_function_ex (function_table=0x8dc1078, object_pp=0x0,
function_name=0x0,
retval_ptr_ptr=0xbff693e4, param_count=2, params=0xbff693e8,
no_separation=0,
symbol_table=0x0) at /local/php/4.3/Zend/zend_execute_API.c:443
#1 0x080ad4bd in zif_array_reduce (ht=148960076,
return_value=0x8e0982c, this_ptr=0x0,
return_value_used=1) at /local/php/4.3/ext/standard/array.c:3258
#2 0x0815019f in execute (op_array=0x8e0f128) at
/local/php/4.3/Zend/zend_execute.c:1651
#3 0x0814e1c4 in execute (op_array=0x8e0eef8) at
/local/php/4.3/Zend/zend_execute.c:1695
#4 0x081344af in call_user_function_ex (function_table=0x8dc1078,
object_pp=0x0,
function_name=0x8e092c4, retval_ptr_ptr=0xbff69e74, param_count=2,
params=0xbff69e78,
no_separation=0, symbol_table=0x0) at
/local/php/4.3/Zend/zend_execute_API.c:565
#5 0x080ad4bd in zif_array_reduce (ht=148959852,
return_value=0x8e09564, this_ptr=0x0,
return_value_used=1) at /local/php/4.3/ext/standard/array.c:3258
#6 0x0815019f in execute (op_array=0x8e0f128) at
/local/php/4.3/Zend/zend_execute.c:1651
#7 0x0814e1c4 in execute (op_array=0x8e0eef8) at
/local/php/4.3/Zend/zend_execute.c:1695
#8 0x081344af in call_user_function_ex (function_table=0x8dc1078,
object_pp=0x0,
function_name=0x8e0dfc4, retval_ptr_ptr=0xbff6a904, param_count=2,
params=0xbff6a908,
no_separation=0, symbol_table=0x0) at
/local/php/4.3/Zend/zend_execute_API.c:565
#9 0x080ad4bd in zif_array_reduce (ht=148959676,
return_value=0x8e0929c, this_ptr=0x0,
return_value_used=1) at /local/php/4.3/ext/standard/array.c:3258
#10 0x0815019f in execute (op_array=0x8e0f128) at
/local/php/4.3/Zend/zend_execute.c:1651
#11 0x0814e1c4 in execute (op_array=0x8e0eef8) at
/local/php/4.3/Zend/zend_execute.c:1695
#12 0x081344af in call_user_function_ex (function_table=0x8dc1078,
object_pp=0x0,
function_name=0x8e0dc2c, retval_ptr_ptr=0xbff6b394, param_count=2,
params=0xbff6b398,
no_separation=0, symbol_table=0x0) at
/local/php/4.3/Zend/zend_execute_API.c:565
#13 0x080ad4bd in zif_array_reduce (ht=148914716,
return_value=0x8e0df9c, this_ptr=0x0,
return_value_used=1) at /local/php/4.3/ext/standard/array.c:3258
#14 0x0815019f in execute (op_array=0x8e0f128) at
/local/php/4.3/Zend/zend_execute.c:1651
#15 0x0814e1c4 in execute (op_array=0x8e0eef8) at
/local/php/4.3/Zend/zend_execute.c:1695
#16 0x081344af in call_user_function_ex (function_table=0x8dc1078,
object_pp=0x0,
function_name=0x8e0db8c, retval_ptr_ptr=0xbff6be24, param_count=2,
params=0xbff6be28,
no_separation=0, symbol_table=0x0) at
/local/php/4.3/Zend/zend_execute_API.c:565
#17 0x080ad4bd in zif_array_reduce (ht=148914548,
return_value=0x8e0dc04, this_ptr=0x0,
return_value_used=1) at /local/php/4.3/ext/standard/array.c:3258
#18 0x0815019f in execute (op_array=0x8e0f128) at
/local/php/4.3/Zend/zend_execute.c:1651
#19 0x0814e1c4 in execute (op_array=0x8e0902c) at
/local/php/4.3/Zend/zend_execute.c:1695
#20 0x0813d1d9 in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at /local/php/4.3/Zend/zend.c:926
#21 0x08113642 in php_execute_script (primary_file=0xbff6eb50)
at /local/php/4.3/main/main.c:1739
#22 0x0815833b in main (argc=3, argv=0xbff6ec14) at
/local/php/4.3/sapi/cli/php_cli.c:825
Previous Comments:
[2003-05-11 01:39:57] [EMAIL PROTECTED]
This bug has been fixed in CVS.
In case this was a PHP problem, 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/.
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.
In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
Thank you for the report, and for helping us make PHP better.
[2003-03-25 13:57:12] [EMAIL PROTECTED]
It coredumps with latest 5.0.0-dev
Backtrace (relevant lines):
#0
#31002 [Fbk-Bgs]: IA64 Unable to link php with Mysql 4.1.7
ID: 31002 Updated by: [EMAIL PROTECTED] Reported By: zeke at spamcop dot net -Status: Feedback +Status: Bogus Bug Type: MySQL related Operating System: Linux 2.4.21-sgi301r1 PHP Version: 4CVS-2005-01-21 New Comment: The static libmysqlclient.a you have was not compiled using -fPIC so you either need to build MySQL shared libraries, or rebuild the static libraires using CFLAGS=-fPIC; either way, this is not a PHP bug. Previous Comments: [2005-02-01 19:22:13] [EMAIL PROTECTED] Get the latest snapshot from today and try with this configure line: ./configure --disable-all --with-apxs2 --with-mysql=/usr/local/mysql --with-pic --disable-cli [2005-01-21 13:41:24] zeke at spamcop dot net Hi, I tried the latest build:php4-STABLE-200501211130 Same error during the linking step. I used the same configure options as in my original message. /usr/bin/ld: /usr/local/mysql/lib/libmysqlclient.a(libmysql.o): @gprel relocation against dynamic symbol net_buffer_length /usr/bin/ld: /usr/local/mysql/lib/libmysqlclient.a(libmysql.o): @gprel relocation against dynamic symbol max_allowed_packet /usr/bin/ld: /usr/local/mysql/lib/libmysqlclient.a(libmysql.o): @gprel relocation against dynamic symbol net_write_timeout /usr/bin/ld: /usr/local/mysql/lib/libmysqlclient.a(libmysql.o): @gprel relocation against dynamic symbol net_read_timeout collect2: ld returned 1 exit status make: *** [libphp4.la] Error 1 [2005-01-13 04:29:41] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip [2004-12-06 22:43:50] zeke at spamcop dot net Edit: Also tried with the --with-pic option on the configure command line .. still same link errors. [2004-12-06 20:33:27] zeke at spamcop dot net Description: Platform: SGI Altix 350 16p Itainium2 OS: Linux Kern 2.4.21 SGIPropack3 MySql Version: 4.1.7 gcc version: 3.2.2 Building php with the line ./configure --with-mysql=/usr/local/mysql --with-apxs2 Make during the step to create libphp4.la Results in the following errors: /usr/bin/ld: /usr/local/mysql/lib/libmysqlclient.a(libmysql.o): @gprel relocation against dynamic symbol net_buffer_length /usr/bin/ld: /usr/local/mysql/lib/libmysqlclient.a(libmysql.o): @gprel relocation against dynamic symbol max_allowed_packet /usr/bin/ld: /usr/local/mysql/lib/libmysqlclient.a(libmysql.o): @gprel relocation against dynamic symbol net_write_timeout /usr/bin/ld: /usr/local/mysql/lib/libmysqlclient.a(libmysql.o): @gprel relocation against dynamic symbol net_read_timeout collect2: ld returned 1 exit status make: *** [libphp4.la] Error 1 Other informaiton: I can make php fine without mysql support. I had the same problems with php4.3.10RC1 and php5 The Mysql is the 4.1.7 IA64 Max binary distribtion. Any suggesitons to get this linked with mySql would be appreciated. Cheers, Mike -- Edit this bug report at http://bugs.php.net/?id=31002edit=1
#31717 [Bgs-Asn]: Cannot turn off PATH_INFO
ID: 31717 Updated by: [EMAIL PROTECTED] Reported By: stijn at win dot tue dot nl -Status: Bogus +Status: Assigned Bug Type: Apache2 related Operating System: FreeBSD 4 and -CURRENT PHP Version: 4.3.10 -Assigned To: +Assigned To: jorton New Comment: Yes it does, in 2.0 the handler has to honour the r-used_path_info setting appropriately. Previous Comments: [2005-01-27 18:08:01] [EMAIL PROTECTED] This has nothing to do with PHP and please don't post support questions to the bug database. [2005-01-27 11:23:03] stijn at win dot tue dot nl Description: I'm trying to turn the support for PATH_INFO off on a *default* install of apache-2.0.52 and php-4.3.10, but it doesn't work. Note that I am not 100% sure that this is a PHP bug, however Apache does not accept PATH_INFO for regular HTML files so I'm inclined to suspect PHP. I first installed Apache in a scratch directory: ./configure --prefix=/var/tmp/apachephp --enable-so --with-mpm=prefork --enable-maintainer-mode gmake gmake install Then PHP: env CFLAGS=-g ./configure --prefix=/var/tmp/apachephp --with-apxs2=/var/tmp/apachephp/bin/apxs --disable-cgi --disable-path-info-check gmake gmake install I edited /var/tmp/apachephp/conf/httpd.conf and added these lines: %%% AddType application/x-httpd-php .php AcceptPathInfo off Directory /var/tmp/apachephp/htdocs AcceptPathInfo off /Directory %%% Adding a simple index.php to the docroot (/var/tmp/apachephp/htdocs/index.php): %%% ? phpinfo(); ? %%% After starting httpd, I can still browse to http://localhost/index.php/foo/bar and see that PATH_INFO indeed contains /foo/bar. I've tried digging in the sources but I'm not familiar with Apache plugins. I did see this in gdb: %%% Breakpoint 2, php_apache_request_ctor (r=0x81b2050, ctx=0x81b3e70) at /local/home/stijn/tmp/php-4.3.10/sapi/apache2handler/sapi_apache2.c:408 408 SG(sapi_headers).http_response_code = !r-status ? HTTP_OK : r-status; (gdb) print r-path_info $1 = 0x81b3253 /foo/bar (gdb) print r-used_path_info $2 = 1 %%% So in the request constructor the path info is already set up? I did see something about overriding r-path_info for apache modules in the apache sources but here is where I cannot follow the code anymore... BTW, I tried to post this to php-general twice, but somehow my e-mail is blocked. I do hope this is not PEBKAC but even if it is I would be glad if someone pointed this out to me... Reproduce code: --- n/a Expected result: n/a Actual result: -- see above for a maybe relevant backtrace snippet -- Edit this bug report at http://bugs.php.net/?id=31717edit=1
#31645 [Asn-Csd]: apache_lookup_uri prevents further headers from being sent
ID: 31645 Updated by: [EMAIL PROTECTED] Reported By: john at jelsoft dot com -Status: Assigned +Status: Closed Bug Type: Apache2 related Operating System: * PHP Version: 4CVS, 5CVS (2005-01-22) Assigned To: jorton New Comment: 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. Ah, thanks, my bad. Previous Comments: [2005-01-22 14:54:02] [EMAIL PROTECTED] This bug was caused by this fix: revision 1.16 date: 2005/01/11 14:01:32; author: jorton; state: Exp; lines: +6 -1 Fixed bug #30446 - virtual() includes files out of sequence, work around 2.0 subrequest/internal redirect issue. [2005-01-22 12:20:58] john at jelsoft dot com From my phpinfo, from the 'Loaded modules' section of apache2handler, it has sapi_apache2. Also listed in the modules section is worker. PHP's server API is reported as Apache 2.0 Handler. Is that the information you're after? Thanks! [2005-01-22 01:12:16] [EMAIL PROTECTED] What Apache SAPI are you using? [2005-01-21 19:25:10] john at jelsoft dot com Description: Any calls to the header() function after apache_lookup_uri() is called are not processed properly, so that the headers are not sent. Running 4.3.11-dev, build date Jan 16 2005 16:25:34 Save the following in test.php: Reproduce code: --- ?php header( X-John: test1 ); apache_lookup_uri( 'test.php' ); header( X-John2: test2 ); echo hello; ? Expected result: The header X-John2: test2 to be sent. Actual result: -- It's not sent, while X-John: test is sent. -- Edit this bug report at http://bugs.php.net/?id=31645edit=1
#31569 [Opn]: Incorrect Values Returned
ID: 31569 Updated by: [EMAIL PROTECTED] Reported By: php at milonic dot com Status: Open Bug Type: Math related Operating System: Fedora/Linux 9 PHP Version: 4CVS-2005-01-16 New Comment: $a=-3111919630; echo $b ^= ($a10); 1. -3111919630 cannot be represented in a 32-bit long, so it's stored in a double 2. $a 10 is executed using (long) integer arithmetic, so $a is converted to a long here 3. the Zend macro which converts double to long used to be miscompiled by GCC, but this was fixed in the FC3 gcc. Previous Comments: [2005-01-16 17:05:12] php at milonic dot com New test case at: http://www.milonic.com/bugreports/php_fc3.php Can also confirm that JavaScript will return the same values that older Redhat returns. This is getting weirder by the minute. Cheers Andy [2005-01-16 15:38:38] php at milonic dot com UPDATE: Just to confirm that it's also the same with RPM-4.3.9 - so no matter if it's compiled from source or package. Also (was a long shot) changing precision in php.ini makes no difference either Cheers Andy [2005-01-16 15:19:48] php at milonic dot com Yes from source: gcc version 3.4.2 20041017 (Red Hat 3.4.2-6.fc3) one that I know works fine is: gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5) Basically, all machines other than 'Fedora Core 3' are working fine. It's something in FC3 that is wrong, I just can't pinpoint it. It's a standard server install by the way, nothing special. Hardware also seems to be unrelated to the problem, tried it on 2 different FC3 servers and get the same result. Cheers Andy [2005-01-16 14:55:06] [EMAIL PROTECTED] Did you compile from source? If so, what are the different GCC versions on all machines? [2005-01-16 14:45:20] php at milonic dot com Narrowed the problem down to this: $b=251066875; $a=-3111919630; echo $b ^= ($a10); Fedora 3 echos: 251066875 (wrong) All other OS's echo: 25768443 (correct) Maybe it helps? Cheers Andy 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/31569 -- Edit this bug report at http://bugs.php.net/?id=31569edit=1
#31183 [Opn-Fbk]: exit status 128 when printing something before header()
ID: 31183
Updated by: [EMAIL PROTECTED]
Reported By: marco-glatz at web dot de
-Status: Open
+Status: Feedback
Bug Type: Apache2 related
Operating System: WinXP
PHP Version: 5.0.2
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php5-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.0-win32-latest.zip
Can't reproduce with 5.0.4-dev here, can you try 5.0.3 or a CVS
snapshot of 5.0?
...
string(2) de
br /
bWarning/b: Cannot modify header information - headers already
sent by (output started at
Previous Comments:
[2004-12-19 01:14:55] marco-glatz at web dot de
Description:
when i print for example some debugging-informations before i call the
header()-function apache says:
Parent: child process exited with status 128 -- Restarting.
Reproduce code:
---
$language = 'de';
$charset = 'iso-8859-1';
var_dump($language);
header('Content-language: '. $language);
header('Content-type: text/html; charset='. $charset);
Expected result:
something like cannot send headers, output already started at
--
Edit this bug report at http://bugs.php.net/?id=31183edit=1
#29681 [Opn]: Parent: child process exited with status 3221225477
ID: 29681
Updated by: [EMAIL PROTECTED]
Reported By: tony at marston-home dot demon dot co dot uk
Status: Open
-Bug Type: Apache2 related
+Bug Type: Zend Engine 2 problem
Operating System: WindowsXP
PHP Version: 5.0.1
New Comment:
The original problem here, reproduced using the script bundle posted by
Tony, triggers crashes in free() when run with MALLOC_CHECK_=3, using
5.0.4-dev. Backtrace below. Doesn't look like this is
Apache-related:
#5 0x0041baca in free () from /lib/tls/libc.so.6
No symbol table info available.
#6 0x010035b7 in _efree (ptr=0x86e443c) at
/net/jedi/local/php/5.0/Zend/zend_alloc.c:287
p = (zend_mem_header *) 0x4e0800
cache_index = 6
#7 0x0101f1fa in zend_hash_destroy (ht=0x86f1714)
at /net/jedi/local/php/5.0/Zend/zend_hash.c:526
p = (Bucket *) 0x0
q = (Bucket *) 0x86e47dc
#8 0x01029c7f in zend_objects_free_object_storage (object=0x872be84)
at /net/jedi/local/php/5.0/Zend/zend_objects.c:91
No locals.
#9 0x0102c24a in zend_objects_store_del_ref (zobject=0x0)
at /net/jedi/local/php/5.0/Zend/zend_objects_API.c:159
handle = 1
obj = (struct _store_object *) 0x86d9b88
#10 0x010170d0 in _zval_dtor (zvalue=0x86efb2c)
at /net/jedi/local/php/5.0/Zend/zend_variables.c:61
No locals.
#11 0x0100c491 in _zval_ptr_dtor (zval_ptr=0x10a995c)
at /net/jedi/local/php/5.0/Zend/zend_execute_API.c:392
No locals.
#12 0x0104b894 in zend_do_fcall_common_helper
(execute_data=0xbff34610,
opline=0x86ee780, op_array=0x86e306c)
at /net/jedi/local/php/5.0/Zend/zend_execute.c:2797
i = 141458196
p = (zval **) 0x86efb2c
arg_count = 17471360
original_return_value = (zval **) 0xbff346ac
current_scope = (zend_class_entry *) 0x0
current_this = (zval *) 0x0
return_value_used = 1
should_change_scope = 1 '\001'
#13 0x0104ba48 in zend_do_fcall_by_name_handler (execute_data=0x0,
opline=0x86ee780,
op_array=0x86e306c) at
/net/jedi/local/php/5.0/Zend/zend_execute.c:2825
No locals.
#14 0x01039b77 in execute (op_array=0x86e306c)
at /net/jedi/local/php/5.0/Zend/zend_execute.c:1400
execute_data = {opline = 0x86ee780, function_state = {
function_symbol_table = 0x870e404, function = 0x872a444, reserved =
{0x100f260,
0x86e3364, 0xbff36970, 0x0}}, fbc = 0x872a444, fbc_constructor =
0x0,
op_array = 0x86e306c, object = 0x86efb2c, Ts = 0xbff33430,
original_in_execution = 0 '\0', calling_scope = 0x86f0a54,
prev_execute_data = 0x0}
#15 0x01018b25 in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at /net/jedi/local/php/5.0/Zend/zend.c:1069
files = 0xbff34764
i = 1
file_handle = (zend_file_handle *) 0xbff36970
orig_op_array = (zend_op_array *) 0x0
local_retval = (zval *) 0x0
Previous Comments:
[2004-12-19 15:37:13] jason at amp-design dot net
I also get this error in one of my scripts. I have a feeling it is to
do with either Exceptions or overloading using SPL ArrayAccess (or a
combination of the two).
[2004-12-08 20:16:54] akomasinski at gmail dot com
Same error in 5.0.2 + Apache 2.0.50 + MySQL 4.0.22
Windows XP SP1
[2004-12-02 05:40:02] aristotle at brettia dot com
I had this same problem. My stats:
Windows XP SP2, AMD Athlon 64 (32-bit Windows, though)
PHP 5.0.1, Apache 2.0.50, MySQL 4.0.22
Apache Error Log Excerpts:
(Restarted Server)
[Wed Dec 01 21:14:56 2004] [notice] mod_python: Creating 32 session
mutexes based on 0 max processes and 250 max threads.
[Wed Dec 01 21:14:57 2004] [notice] Parent: Created child process 3960
[Wed Dec 01 21:14:57 2004] [notice] mod_python: Creating 32 session
mutexes based on 0 max processes and 250 max threads.
[Wed Dec 01 21:14:57 2004] [notice] Child 3960: Child process is
running
[Wed Dec 01 21:14:57 2004] [notice] Child 3960: Acquired the start
mutex.
[Wed Dec 01 21:14:57 2004] [notice] Child 2080: Released the start
mutex
[Wed Dec 01 21:14:57 2004] [notice] Child 3960: Starting 250 worker
threads.
[Wed Dec 01 21:14:58 2004] [notice] Child 2080: Waiting for 250 worker
threads to exit.
[Wed Dec 01 21:14:58 2004] [notice] Child 2080: All worker threads have
exited.
[Wed Dec 01 21:14:59 2004] [notice] Child 2080: Child process is
exiting
(This error happens upon running a script.)
[Wed Dec 01 21:15:04 2004] [notice] Parent: child process exited with
status 3221225477 -- Restarting.
[Wed Dec 01 21:15:04 2004] [notice] mod_python: Creating 32 session
mutexes based on 0 max processes and 250 max threads.
[Wed Dec 01 21:15:04 2004] [notice] Parent: Created child process 2280
[Wed Dec 01 21:15:04 2004] [notice] mod_python: Creating 32 session
mutexes based on 0 max processes and 250 max
#31594 [Opn]: virtual(): Unable to include 'xxx' - error finding URI
ID: 31594 Updated by: [EMAIL PROTECTED] Reported By: per at computer dot org Status: Open Bug Type: Apache2 related Operating System: linux 2.4.26 PHP Version: 4CVS-2005-01-18 (stable) New Comment: Do you get a no acceptable variant message logged to the httpd error_log? Changing the locale can make functions like strcasecmp behave in unexpected ways and hence random stuff can fail. Why do you need to change the locale? Previous Comments: [2005-01-18 10:27:42] per at computer dot org This now appears to be related to setlocale(). To reproduce: part0.phtml: ?php setlocale(LC_ALL,da_DK.utf8); ? ?xml version=1.0 encoding=UTF-8 ? !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.1//EN xhtml11.dtd html xmlns=http://www.w3.org/1999/xhtml; xml:lang=en head titlephp bug 31594/title /head body part0+?php virtual(part1); ? /body /html part1.phtml: (contents irrelevant). part1 Comment out the setlocale() in part0 to make the code work. When it's commented out I see: part0+part1. When it's left in I see: part0+ Warning: virtual(): Unable to include 'part1' - error finding URI in [2005-01-18 10:00:46] per at computer dot org Description: I suspect this is related to bug#30446, but thought it best to open a new issue rather than re-open that one. I had php4-STABLE-200501160930 running for a day or so, when I discovered the following in one of my existing php apps: Warning: virtual(): Unable to include 'toc' - error finding URI in /srv/www/vhosts/dansklisten/htdocs/albummet/helebilledet.phtml on line 57 This is from a working, stable application, works fine in php-4.3.8, but not with the latest 4CVS. I'll try to work out some simple code to reproduce. -- Edit this bug report at http://bugs.php.net/?id=31594edit=1
#31519 [Opn-Fbk]: Setting Status: 559 works using php-cgi but not using Apache 2 module
ID: 31519 Updated by: [EMAIL PROTECTED] Reported By: trevor dot wekel at autodesk dot com -Status: Open +Status: Feedback Bug Type: Apache2 related Operating System: Windows XP PHP Version: 5.0.3 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.0-win32-latest.zip Previous Comments: [2005-01-12 22:02:27] [EMAIL PROTECTED] Sorry, cat hit Submit while I wasn't looking. http://www.w3.org/Protocols/rfc2616/rfc2616-sec6.html#sec6.1.1 ...is where that is. [2005-01-12 22:00:01] [EMAIL PROTECTED] From the HTTP/1.1 spec, §6.1.1: For example, if an unrecognized status code of 431 is received by the client, it can safely assume that there was something wrong with its request and treat the response as if it had received a 400 status code. 5xx is treated as 500 by applications that don't understand it. Why this behavior pops up in SAPI but not CGI, I'm not sure. Perhaps Apache 2 does not parse CGI return codes, but does for built-in modules? [2005-01-12 17:09:09] trevor dot wekel at autodesk dot com Description: The following PHP script returns different HTTP response status codes when run using php-cgi.exe and run as a Apache module. Versions of software installed: PHP 5.0.3 zip donwloaded from Php.net http://www.php.net/get/php-5.0.3-Win32.zip/from/a/mirror Apache 2.0.52 from Apache.org http://apache.secsup.org/dist/httpd/binaries/win32/apache_2.0.52-win32-x86-no_ssl.msi I can also post my httpd.conf and php.ini files if required. No special tweaking was done other than the standard PHP setup for Apache 2 documented here: http://www.php.net/manual/en/install.windows.apache2.php Reproduce code: --- ?php header(HTTP/1.1 559 CustomError); header(Status: 559 CustomError); echo html\n; echo body\n; echo Error on page!!!\n; echo /body\n; echo /html\n; ? Expected result: I would expect to see an HTTP response status code of 559 returned when running under both the php-cgi and the Apache 2 module. Actual result: -- When running under php-cgi, the 559 HTTP response status code is returned. When under the Apache 2 module, an HTTP 500 Internal Error is returned. Note: The Status: line is returned correctly but it does not match the response status code. -- Edit this bug report at http://bugs.php.net/?id=31519edit=1
#31519 [Opn-Csd]: Setting Status: 559 works using php-cgi but not using Apache 2 module
ID: 31519 Updated by: [EMAIL PROTECTED] Reported By: trevor dot wekel at autodesk dot com -Status: Open +Status: Closed Bug Type: Apache2 related Operating System: Windows XP PHP Version: 5.0.3 New Comment: 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. Thanks; the descrepancy may just have been timing on picking up the snapshots, the fix was only committed this morning. Previous Comments: [2005-01-17 20:38:57] trevor dot wekel at autodesk dot com I just finished building from the PHP 5.0.4 sources detailed below using VS .Net 2003. I built against Apache 2.0.52 headers and applied the necessary resolve.lib patch mentioned on Zend.com. When built locally, php5apache2.dll works correctly! I configured with the following command line: cscript /nologo configure.js --enable-apache2handler --without-libxml Weird. Are there build differences between the posted win32 executables and my local executables? [2005-01-17 17:27:04] trevor dot wekel at autodesk dot com The unusual behaviour is still present in the 5.0.4 development snapshot when run as an Apache module. It returns an HTTP 500 status. Is there anything I can do on my end to determine where the response code is being dropped/remapped? Just out of curiousity, I also tried PHP 5.0.4 dev under IIS 5.1. Both the isapi agent and the cgi return the correct response code. However, the isapi agent does not return the descriptive text correctly. [2005-01-17 15:06:32] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.0-win32-latest.zip [2005-01-12 22:02:27] [EMAIL PROTECTED] Sorry, cat hit Submit while I wasn't looking. http://www.w3.org/Protocols/rfc2616/rfc2616-sec6.html#sec6.1.1 ...is where that is. [2005-01-12 22:00:01] [EMAIL PROTECTED] From the HTTP/1.1 spec, §6.1.1: For example, if an unrecognized status code of 431 is received by the client, it can safely assume that there was something wrong with its request and treat the response as if it had received a 400 status code. 5xx is treated as 500 by applications that don't understand it. Why this behavior pops up in SAPI but not CGI, I'm not sure. Perhaps Apache 2 does not parse CGI return codes, but does for built-in modules? 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/31519 -- Edit this bug report at http://bugs.php.net/?id=31519edit=1
#31413 [Asn-Csd]: cURL not posting on 64-bit machine
ID: 31413
Updated by: [EMAIL PROTECTED]
Reported By: travis at etrafficsolutions dot com
-Status: Assigned
+Status: Closed
Bug Type: cURL related
Operating System: Linux
PHP Version: 4.3.10
Assigned To: jorton
New Comment:
Great, thanks for testing it out. The patch is in 4.3/5.0/5.1 CVS now,
there was talk about 4.3.11 being rolled early this month.
Previous Comments:
[2005-01-06 01:14:32] travis at etrafficsolutions dot com
Works!
Thanks so much for the quick response.
Any idea when this will be in CVS and when the next version (of php)
will be released?
Thanks again.
[2005-01-05 22:36:06] [EMAIL PROTECTED]
Can you try this patch: http://www.apache.org/~jorton/php_curl64.diff
[2005-01-05 01:31:31] travis at etrafficsolutions dot com
Description:
CURL Information: libcurl/7.12.3 OpenSSL/0.9.7d zlib/1.2.1
Tested with PHP 4.3.10 and the latest php4 cvs.
When I run the script below on a 64-bit AMD machine, the post received
by the receiving script are empty. Nothing is posted.
To try and figure out if cURL was having problems or if it was PHP, I
tried the exact same submit using curl command line, to the same
receiving script. Works as expected.
curl -d key=value http://{URL_HERE}/curl_receive.php
Returns a var_dump() with the key key holding a value of value
I have tested this on 3+ 32-bit machines, without any problems (script
or command line curl). I have also tested on 3 64-bit machines, all of
them failed when the script was run, but were successful when run from
command line curl.
-
If I can provide any more information to help with this, please reply
and I will get it to you asap.
Reproduce code:
---
?php
// curl_submit.php
$ch = curl_init();
// replace {URL_HERE} to where you put this script
curl_setopt($ch, CURLOPT_URL, http://{URL_HERE}/curl_receive.php;);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($ch, CURLOPT_POST, 1);
$post_array = array(
'key' = 'value');
curl_setopt($ch, CURLOPT_POSTFIELDS, $post_array);
$response = curl_exec($ch);
var_dump($response);
?
?php
// curl_receive.php
var_dump($_POST);
?
Expected result:
array(1) {
[key]=
string(5) value
}
Actual result:
--
array(0) {}
--
Edit this bug report at http://bugs.php.net/?id=31413edit=1
#31413 [Opn-Ana]: cURL not posting on 64-bit machine
ID: 31413
Updated by: [EMAIL PROTECTED]
Reported By: travis at etrafficsolutions dot com
-Status: Open
+Status: Analyzed
Bug Type: cURL related
Operating System: Linux
PHP Version: 4.3.10
-Assigned To:
+Assigned To: jorton
New Comment:
Can you try this patch: http://www.apache.org/~jorton/php_curl64.diff
Previous Comments:
[2005-01-05 01:31:31] travis at etrafficsolutions dot com
Description:
CURL Information: libcurl/7.12.3 OpenSSL/0.9.7d zlib/1.2.1
Tested with PHP 4.3.10 and the latest php4 cvs.
When I run the script below on a 64-bit AMD machine, the post received
by the receiving script are empty. Nothing is posted.
To try and figure out if cURL was having problems or if it was PHP, I
tried the exact same submit using curl command line, to the same
receiving script. Works as expected.
curl -d key=value http://{URL_HERE}/curl_receive.php
Returns a var_dump() with the key key holding a value of value
I have tested this on 3+ 32-bit machines, without any problems (script
or command line curl). I have also tested on 3 64-bit machines, all of
them failed when the script was run, but were successful when run from
command line curl.
-
If I can provide any more information to help with this, please reply
and I will get it to you asap.
Reproduce code:
---
?php
// curl_submit.php
$ch = curl_init();
// replace {URL_HERE} to where you put this script
curl_setopt($ch, CURLOPT_URL, http://{URL_HERE}/curl_receive.php;);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($ch, CURLOPT_POST, 1);
$post_array = array(
'key' = 'value');
curl_setopt($ch, CURLOPT_POSTFIELDS, $post_array);
$response = curl_exec($ch);
var_dump($response);
?
?php
// curl_receive.php
var_dump($_POST);
?
Expected result:
array(1) {
[key]=
string(5) value
}
Actual result:
--
array(0) {}
--
Edit this bug report at http://bugs.php.net/?id=31413edit=1
#31358 [Opn]: Compile time error, incompatible types in assignment in zend.c on PPC
ID: 31358 Updated by: [EMAIL PROTECTED] Reported By: hawk at pld-linux dot org Status: Open Bug Type: Compile Failure Operating System: PLD Linux 1.0 running on PowerPC PHP Version: 4.3.10 Assigned To: stas New Comment: va_copy is a C99 invention, so that's why it's not in gcc-2.95.2 (though some older gcc's had a __va_copy). But even in C99 va_copy is explicitly allowed to be a function not a macro, I can't see any guarantee that it is defined for the preprocessor as this code assumes. (C99/7.15.1) Previous Comments: [2005-01-04 14:35:44] hawk at pld-linux dot org According to 'gcc -v': Reading specs from /usr/lib/gcc-lib/ppc-pld-linux/2.95.4/specs gcc version 2.95.4 20010319 (prerelease) And yes, there is stdarg.h in /usr/lib/gcc-lib/ppc-pld-linux/2.95.4/include/stdarg.h [2005-01-02 08:58:47] [EMAIL PROTECTED] Which GCC do you have? It is rather strange va_copy is not defined on Linux. Do you have stdarg.h anywhere? [2004-12-31 19:46:59] hawk at pld-linux dot org The bug affects only PPC systems with older GCC which don't support va_copy (sorry, didn't noticed this earlier), the workaround is to change line 776 of zend.c: usr_copy = args; into memcpy(usr_copy, args, sizeof(va_list)); for these architectures. It seems to work perfectly [2004-12-30 22:03:06] hawk at pld-linux dot org Description: The compilation of PHP 4.3.10 fails on Linux running on PowerPC with following error: /home/users/builder/rpm/BUILD/php-4.3.10/Zend/zend.c -o Zend/zend.lo /home/users/builder/rpm/BUILD/php-4.3.10/Zend/zend.c: In function `zend_error': /home/users/builder/rpm/BUILD/php-4.3.10/Zend/zend.c:776: incompatible types in assignment make: *** [Zend/zend.lo] Error 1 Following code change is reponsible for this bug: cvs diff -u -r 1.162.2.21 -r 1.162.2.22 Zend/zend.c Line 776 is: usr_copy = args; where both usr_copy and args are of type va_list. Such code will not compile on Linux on PowerPC (and probably on some other architectures too) because va_list is struct here. I know only two ways for fixing it. One is to use va_copy, but I'm not sure if its safe to change following portion of code: #if defined(va_copy) va_copy(usr_copy, args); #else usr_copy = args; #endif just into: va_copy(usr_copy, args); Probably its not safe. The second way is to use usr_copy[0] = args[0]; for the affected architectures, but its not safe either AFAIR. I also suppose that php 5.0.3 is affected too, because it contains same code -- Edit this bug report at http://bugs.php.net/?id=31358edit=1
#30446 [Opn-Asn]: virtual() includes files out of sequence
ID: 30446 Updated by: [EMAIL PROTECTED] Reported By: per at computer dot org -Status: Open +Status: Assigned Bug Type: Apache2 related Operating System: linux 2.4.26 PHP Version: 4CVS, 5CVS (?) -Assigned To: +Assigned To: jorton New Comment: This is a regression since the apache2handler was switched to use ap_r* directly (4.3.9). Workaround is http://www.apache.org/~jorton/php_virtual.diff. I want to investigate this a little more before committing, I think it's really a 2.0 bug. Previous Comments: [2004-12-26 11:03:22] per at computer dot org Confirmed in 4.3.10. Output buffering is off. [2004-12-25 19:15:20] pquerna at apache dot org Has anyone tried this against Apache 1.3? Do you have output buffering enabled in PHP? [2004-12-12 11:22:47] per at computer dot org Also present in 4.3.10RC2. I'm curious regarding the Category Apache2 related - this problem is not present in php4.3.8, only in the later versions. I'm sure it *is* apache2 related, but it would appear that the problem is in php, not apache2? [2004-12-02 09:43:45] per at computer dot org I'm currently using 2.0.52, but I believe I reproduced this with 2.0.50 as well. The problem does not occur in php 4.3.8 with either apache version. [2004-12-02 03:30:40] [EMAIL PROTECTED] What Apache version are you using? 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/30446 -- Edit this bug report at http://bugs.php.net/?id=30446edit=1
#31080 [Ana]: ftp_connect() fails on a system where there is a large number of open files.
ID: 31080 Updated by: [EMAIL PROTECTED] Reported By: jon at destra dot com Status: Analyzed Bug Type: FTP related Operating System: RedHat Linux Fedora Core 2 PHP Version: 4.3.8 New Comment: We've just been using hacky workarounds for this which I doubt anyone really wants in the 4.3.x tree. Wez has fixed all such problems properly in 5.0.3 so the proper solution lies there. Previous Comments: [2004-12-15 04:10:25] jon at destra dot com Sorry, I forgot you get to deal with folks that can't configure a server reporting things as bugs when they aren't. :) [2004-12-15 03:57:22] [EMAIL PROTECTED] Why didn't you give that RH bug number in the first place? Would have saved our time a lot. :) [2004-12-15 02:30:21] jon at destra dot com Please note I opened this ticket at the suggestion of Wez Furlong. Please also take a look at the following: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=125258 [2004-12-15 02:19:57] jon at destra dot com It triggers the die. There is no more error information to report. There is nothing in the ftp servers logs to help and I can't really turn on verbose logging for it in a production environment. This works fine on an indentically configured server with less open files, or in light of the following I should say open file descriptors, on it. [EMAIL PROTECTED] root]# lsof | wc -l 89854 Which doesn't seem right... lsof lists all open files, including files which are not using file descriptors - such as current working directories, memory mapped library files, and executable text files. [EMAIL PROTECTED] root]# cat /proc/sys/fs/file-nr 45750 32768 That gives a more relevant number I expect. Hope that helps some. [2004-12-15 01:28:41] [EMAIL PROTECTED] What is the error it gives? (set error_reporting = E_ALL!) Does the FTP server log have any clues why the connection fails? At what point of the connection does it fail? Put shortly: We need a lot more information!! And how many files you HAVE open at the time of the failure?? (lsof | wc -l command helps with that) 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/31080 -- Edit this bug report at http://bugs.php.net/?id=31080edit=1
#28461 [Opn]: segmentation fault when using backreferences on a long string
ID: 28461
Updated by: [EMAIL PROTECTED]
Reported By: xanthor at xanthor dot tk
Status: Open
Bug Type: PCRE related
Operating System: Linux, WindowsXP©
PHP Version: 4.3.9, 4.3.10RC2, 5.0.2
New Comment:
This is the standard PCRE uses on-stack recursion bug which has been
filed and closed umpteen times. To reproduce just increase the length
of the string until exhausts your stack space.
One way PHP could mitigate the issue is to to set the match_limit field
in the pcre_extra structure which puts a limit on the depth of the stack
recursion.
Previous Comments:
[2004-12-09 14:13:26] xanthor at xanthor dot tk
Still segfault with PHP 4.3.10RC2 and PCRE Library Version 4.5
01-December-2003
[2004-12-06 16:17:35] [EMAIL PROTECTED]
Can't reproduce with any of dev versions (tried latest 4.3.10-dev,
5.1.0-dev 5.0.3-dev under Linux). Please, try latest snapshots and
tell me what version of pcre you're using (mine is 3.9) if you're still
able to reproduce it.
[2004-09-28 10:41:22] xanthor at xanthor dot tk
The regexs still crash PHP 4.3.9 and PHP 5.0.2
[2004-09-16 15:50:47] [EMAIL PROTECTED]
your last regex crashes PHP 5 also.
The segfault isn't in PHP but in pcre (this is quite normal due to the
NFA nature of pcre).
[2004-09-10 17:01:41] hewei at ied dot org dot cn
preg_match(/(((?!aaa).)*)(?!aaa)aaa/,str_repeat('
',10882).'aaa',$z);
crashes PHP4.3.9RC2
But not on php-4.3.2-11.1.ent (WBEL 3.0), the length
to trigger segmentation fault is about 19230.
The most funny thing is that the more closer to the limit, the more
likely you will get a random segmentation fault.
Not only the above pattern will cause the error,
preg_match(/^( )*$/,str_repeat(' ',19250));
will too.
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/28461
--
Edit this bug report at http://bugs.php.net/?id=28461edit=1
#30999 [Fbk]: $_POST problem with textarea/textarea variables
ID: 30999
Updated by: [EMAIL PROTECTED]
Reported By: kkoehler at comcast dot net
Status: Feedback
Bug Type: *URL Functions
Operating System: Linux mis 2.4.21-4.EL #1-Red Hat
PHP Version: 5.0.2
New Comment:
Which SAPI interface, and what Apache configuration are you using?
Previous Comments:
[2004-12-06 18:41:25] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ?php and ends with ?,
is max. 10-20 lines long and does not require any external
resources such as databases, etc.
If possible, make the script source available online and provide
an URL to it here. Try avoid embedding huge scripts into the report.
[2004-12-06 18:35:18] kkoehler at comcast dot net
More testing - when I run this script on 5.0.2
html
form method=post action=?= $_SERVER['PHP_SELF']; ?
textarea name=ta/textarea
input type=submit value=try this/
/form
pre?php print_r( $_POST ); ?/pre
/html
If I enter Hello, this displays:
Array
(
[ta] = Hellota=Hello
)
On 4.3.8 it displays:
Array
(
[ta] = Hello
)
[2004-12-06 18:20:13] kkoehler at comcast dot net
Also, here is more information:
Apache/2.0.46 (Red Hat)
core prefork http_core mod_so mod_access mod_auth mod_auth_anon
mod_auth_dbm mod_auth_digest mod_include mod_log_config mod_env
mod_mime_magic mod_cern_meta mod_expires mod_deflate mod_headers
mod_usertrack mod_unique_id mod_setenvif mod_mime mod_dav mod_status
mod_autoindex mod_asis mod_info mod_dav_fs mod_vhost_alias
mod_negotiation mod_dir mod_imap mod_actions mod_speling mod_userdir
mod_alias mod_rewrite mod_proxy proxy_ftp proxy_http proxy_connect
mod_cache mod_suexec mod_disk_cache mod_file_cache mod_mem_cache
mod_cgi mod_auth_mysql mod_auth_pgsql mod_authz_ldap mod_perl
sapi_apache2 mod_python mod_ssl
./configure' '--host=i686-pc-linux-gnu' '--build=i686-pc-linux-gnu'
'--target=i386-redhat-linux-gnu' '--program-prefix=' '--prefix=/usr'
'--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin'
'--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include'
'--libdir=/usr/lib' '--libexecdir=/usr/libexec' '--localstatedir=/var'
'--sharedstatedir=/usr/com' '--mandir=/usr/share/man'
'--infodir=/usr/share/info' '--with-config-file-path=/etc'
'--with-config-file-scan-dir=/etc/php.d' '--enable-force-cgi-redirect'
'--disable-debug' '--enable-pic' '--enable-inline-optimization'
'--with-bz2' '--with-db4=/usr' '--with-curl' '--with-exec-dir=/usr/bin'
'--with-freetype-dir=/usr' '--with-png-dir=/usr' '--with-gd'
'--enable-gd-native-ttf' '--with-ttf' '--with-gdbm' '--with-gettext'
'--with-ncurses' '--with-gmp' '--with-iconv' '--with-jpeg-dir=/usr'
'--with-openssl' '--with-png' '--with-pspell' '--with-pcre=/usr'
'--with-zlib' '--with-layout=GNU' '--enable-bcmath' '--enable-exif'
'--enable-ftp' '--enable-magic-quotes' '--enable-safe-mode'
'--enable-sockets' '--enable-sysvsem' '--enable-sysvshm'
'--enable-discard-path' '--enable-track-vars' '--enable-trans-sid'
'--enable-yp' '--enable-mbstring' '--enable-mbstr-enc-trans'
'--with-pear=/usr/share/pear' '--with-imap=shared' '--with-imap-ssl'
'--with-kerberos=/usr/kerberos' '--with-mysql=shared,/usr'
'--with-ldap' '--with-oci8=/opt/oracle/product/9.2.0'
'--with-pgsql=shared' '--with-unixODBC=shared' '--enable-memory-limit'
'--enable-bcmath' '--enable-shmop' '--enable-versioning'
'--enable-calendar' '--enable-dbx' '--enable-dio' '--enable-mcal'
'--with-apxs2filter=/usr/sbin/apxs' '--enable-sigchild' '--enable-cli'
'--enable-libgcc' '--with-java=/usr/local/j2sdk1.3.1'
'--with-tsrm-pthreads' '--enable-embed'
[2004-12-06 17:54:47] kkoehler at comcast dot net
Description:
I'm using Smarty 2.6.5 also. When I have a $_POST coming in that is
over 1300 bytes, it reads in the full data but takes a chunk at the
bottom and duplicates it. So if you have over 1300 bytes, it reads in
the 1300 bytes and then takes part of the last so many bytes and keeps
duplicating it with every submit.
I verified that the $_POST data has the duplicated data but the screen
before submit does not. This same code works in 4.3.8 without any
problem.
Reproduce code:
---
Here's the smarty code:
textarea name=cldescription cols=94 rows=17
{$dformVars.cldescription}/textarea
Piece of the PHP code:
$description = trim($_POST['cldescription']);
echo SIZE . strlen($description);
Expected result:
What I see on the screen is what comes in via the $_POST.
Actual result:
--
As I keep reexecuting the code via submit, the
#31001 [Opn-Bgs]: Failure to compile in 64-bit environment
ID: 31001 Updated by: [EMAIL PROTECTED] Reported By: jse at kronos dot honk dot rog -Status: Open +Status: Bogus Bug Type: Compile Failure Operating System: AIX 5.1 PHP Version: 4.3.9 New Comment: Or simply export CC=/path/to/gcc -maix64 in the first place should work just as well, did you try that? AIX requires use of the slibclean command sometimes, to unmap unused libraries - that's not really a PHP issue either. Previous Comments: [2004-12-06 20:46:11] jse at kronos dot honk dot rog I found a workaround for this bug. When building PHP, a modification will be required to the libtool script in order to build a 64-bit lib. After running the configure command, edit libtool, search for: CC=/usr/local/bin/gcc And change it to: CC=/usr/local/bin/gcc -maix64 (Adjust your compiler path accordingly.) Then, run 'make' followed by 'make install'. You might have to remove an existing php module from the apache server tree before installing the new version. Seems that AIX thinks that the module is in use even though apache is not running. Manually removing the module before installation fixes this. rm /usr/webserver/libexec/libphp4.so You can verify the module is a 64-bit version by running the file command and observing the output: # file libs/libphp4.so libs/libphp4.so:64-bit XCOFF executable or object module not stripped [2004-12-06 18:04:39] jse at kronos dot honk dot rog Description: First, I setup the env for a 64-bit build. This was the best info I could find on how to do this: CC=/usr/local/bin/gcc CFLAGS=-maix64 OBJECT_MODE=64 export CC CFLAGS OBJECT_MODE # /usr/local/bin/gcc --version gcc (GCC) 3.2.2 Next, I configured PHP: ./configure \ --prefix=/usr/webserver \ --enable-force-cgi-redirect \ --disable-cli \ --disable-pear \ --with-apxs=/usr/webserver/bin/apxs (Building for Apache 1.3.33/mod_ssl 2.8.22.) The configure seems to run fine. When I issue the make, it runs fine until libtool is called. Expected result: I would expect to have a 64-bit object produced. Actual result: -- /bin/sh /usr/HTTPServer/apachesrc/php-4.3.9/libtool --silent --preserve-dup-deps --mode=link /usr/local/bin/gcc -maix64 -prefer-pic -rpath /usr/HTTPServer/apachesrc/php-4.3.9/libs -Wl,-brtl -Wl,-bI:/usr/webserver/libexec/httpd.exp -avoid-version -module ext/ctype/ctype.lo ext/mysql/php_mysql.lo ext/mysql/libmysql/libmysql.lo ext/mysql/libmysql/errmsg.lo ext/mysql/libmysql/net.lo ext/mysql/libmysql/violite.lo ext/mysql/libmysql/password.lo ext/mysql/libmysql/my_init.lo ext/mysql/libmysql/my_lib.lo ext/mysql/libmysql/my_static.lo ext/mysql/libmysql/my_malloc.lo ext/mysql/libmysql/my_realloc.lo ext/mysql/libmysql/my_create.lo ext/mysql/libmysql/my_delete.lo ext/mysql/libmysql/my_tempnam.lo ext/mysql/libmysql/my_open.lo ext/mysql/libmysql/mf_casecnv.lo ext/mysql/libmysql/my_read.lo ext/mysql/libmysql/my_write.lo ext/mysql/libmysql/errors.lo ext/mysql/libmysql/my_error.lo ext/mysql/libmysql/my_getwd.lo ext/mysql/libmysql/my_div.lo ext/mysql/libmysql/mf_pack.lo ext/mysql/libmysql/my_messnc.lo ext/mysql/libmysql/mf_dirname.lo ext/mysql/libmysql/mf_fn_ext.lo ext/mysql/libmysql/mf_wcomp.lo ext/mysql/libmysql/typelib.lo ext/mysql/libmysql/safemalloc.lo ext/mysql/libmysql/my_alloc.lo ext/mysql/libmysql/mf_format.lo ext/mysql/libmysql/mf_path.lo ext/mysql/libmysql/mf_unixpath.lo ext/mysql/libmysql/my_fopen.lo ext/mysql/libmysql/mf_loadpath.lo ext/mysql/libmysql/my_pthread.lo ext/mysql/libmysql/my_thr_init.lo ext/mysql/libmysql/thr_mutex.lo ext/mysql/libmysql/mulalloc.lo ext/mysql/libmysql/string.lo ext/mysql/libmysql/default.lo ext/mysql/libmysql/my_compress.lo ext/mysql/libmysql/array.lo ext/mysql/libmysql/my_once.lo ext/mysql/libmysql/list.lo ext/mysql/libmysql/my_net.lo ext/mysql/libmysql/dbug.lo ext/mysql/libmysql/strmov.lo ext/mysql/libmysql/strxmov.lo ext/mysql/libmysql/strnmov.lo ext/mysql/libmysql/strmake.lo ext/mysql/libmysql/strend.lo ext/mysql/libmysql/strfill.lo ext/mysql/libmysql/is_prefix.lo ext/mysql/libmysql/int2str.lo ext/mysql/libmysql/str2int.lo ext/mysql/libmysql/strinstr.lo ext/mysql/libmysql/strcont.lo ext/mysql/libmysql/strcend.lo ext/mysql/libmysql/bchange.lo ext/mysql/libmysql/bmove.lo ext/mysql/libmysql/bmove_upp.lo ext/mysql/libmysql/longlong2str.lo ext/mysql/libmysql/strtoull.lo ext/mysql/libmysql/strtoll.lo ext/mysql/libmysql/charset.lo ext/mysql/libmysql/ctype.lo ext/overload/overload.lo ext/pcre/pcrelib/maketables.lo ext/pcre/pcrelib/get.lo ext/pcre/pcrelib/study.lo ext/pcre/pcrelib/pcre.lo ext/pcre/php_pcre.lo ext/posix/posix.lo ext/session/session.lo ext/session/mod_files.lo ext/session/mod_mm.lo ext/session/mod_user.lo regex/regcomp.lo regex/regexec.lo regex/regerror.lo regex/regfree.lo ext/standard/array.lo
#30999 [Opn]: $_POST problem with textarea/textarea variables
ID: 30999
Updated by: [EMAIL PROTECTED]
Reported By: kkoehler at comcast dot net
Status: Open
Bug Type: *URL Functions
Operating System: Linux mis 2.4.21-4.EL #1-Red Hat
PHP Version: 5.0.2
New Comment:
Please answer the question:
Which SAPI interface, and what Apache configuration are you using?
there's a known issue where you can misconfigure the apache2filter and
it will break with symptoms like this: switching to the apache2handler
is the best fix, or else remove the SetOutputFilter statements for
PHP from the apache configuration.
Previous Comments:
[2004-12-06 20:29:07] kkoehler at comcast dot net
We rolled back to 4.3.8 and it is doing it there also. But I'm running
4.3.8 locally on Windows XP and it is not happening. So it might be
something with the OS??? This is a major issue so any help would be
appreciated.
[2004-12-06 19:39:43] kkoehler at comcast dot net
Here is test code using smarty. You'll probably have to change the
configs a bit:
Template:
html
body
form name=articulate method=POST action=testa.php
a href=javascript:document.articulate.submit()
class=listlink2img src=/images/save.gif border=0/a
table
td class=warning align=left
textarea name=testdesc cols=94 rows=17 {$testdesc}/textarea
/td
/tr
/table
/td
/table
/center
/form
/body
/html
PHP code:
?php
ob_start();
define('SMARTY_DIR', 'C:\Program Files\Apache
Group\Apache2\htdocs\Smarty-2.6.6/libs/');
require(SMARTY_DIR . 'Smarty.class.php');
function getSmarty()
{
$smarty = new Smarty;
$smarty-template_dir = 'templates/';
$smarty-compile_dir = 'templates_c/';
$smarty-config_dir = 'configs/';
$smarty-cache_dir = 'cache/';
return $smarty;
}
session_start();
$smarty = getSmarty();
print_r($_POST);
$test = $_POST['testdesc'];
$smarty-assign('testdesc', $test);
$smarty-display('testa.tpl');
ob_end_flush();
?
[2004-12-06 18:57:05] kkoehler at comcast dot net
Apache 2.0.46
cryus-sasl-gssapi-2.1.15-3
[2004-12-06 18:43:47] [EMAIL PROTECTED]
Which SAPI interface, and what Apache configuration are you using?
[2004-12-06 18:41:25] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ?php and ends with ?,
is max. 10-20 lines long and does not require any external
resources such as databases, etc.
If possible, make the script source available online and provide
an URL to it here. Try avoid embedding huge scripts into the report.
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/30999
--
Edit this bug report at http://bugs.php.net/?id=30999edit=1
#30770 [Opn-Fbk]: php mail() causes apache to temporarily 'crash'
ID: 30770
Updated by: [EMAIL PROTECTED]
Reported By: chris at christopher-dean dot co dot uk
-Status: Open
+Status: Feedback
Bug Type: Apache2 related
Operating System: FreeBSD 5.2.1
PHP Version: 5.0.2
New Comment:
Are you using the worker MPM? Threads on FreeBSD are historically a
bit flaky. Google finds random similar backtraces from e.g. ruby users,
FWIW.
Previous Comments:
[2004-11-13 10:11:02] chris at christopher-dean dot co dot uk
Results of the back trace:
Couldn't get a core file so used method described on webpage for people
who can't get a core file and this output was produced. Note, this is
only the section of the backtrace where the crash occured from running
the script in the browser, as prior to this it was all no debugging
symbols found as apache starts normally:
---
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...
Program received signal SIGABRT, Aborted.
0x283bddcf in kill () from /lib/libc.so.5
(gdb) bt
#0 0x283bddcf in kill () from /lib/libc.so.5
#1 0x283b2878 in raise () from /lib/libc.so.5
#2 0x2842af82 in abort () from /lib/libc.so.5
#3 0x2962a565 in _thread_exit () from /usr/lib/libc_r.so.5
#4 0x29628345 in _thread_kern_sig_undefer () from
/usr/lib/libc_r.so.5
#5 0x29627a94 in _thread_kern_sched_state_unlock () from
/usr/lib/libc_r.so.5
#6 0x29627445 in _thread_kern_scheduler () from /usr/lib/libc_r.so.5
---
I hope this helps
[2004-11-13 01:58:45] [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
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.
[2004-11-13 01:45:39] chris at christopher-dean dot co dot uk
Forgot to mention, the email does get sent
[2004-11-13 01:42:26] chris at christopher-dean dot co dot uk
Description:
I am using php 5.0.2 with apache 2.0.52 on freebsd 5.2.1-RELEASE
whenever the mail() is invoked in a php script e.g. by clicking submit
on a mail form, apache 'crashes' (although it doesn't die completely,
maybe it restarts?) and this error of this form is produced in the
logs:
www kernel: pid 20225 (httpd), uid 80: exited on signal 6
Any ideas what I can do to fix this if it isn't a bug within php
itself?
Reproduce code:
---
? if(empty($_POST['name']))
echo The name field was empty. Please click back and fill in
your
name;
else if(empty($_POST['email']))
echo The email field was empty. Please click back and fill in
your
email address;
else if(empty($_POST['message']))
echo You did not enter a message. Please click back and write
us a
message;
else
{
$headers = From: .$_POST['name']. .$_POST['email'].\r\n
.reply-to:.$_POST['email'].\r\n;
mail([EMAIL PROTECTED], Message from the Media website,
$_POST['message'], $headers);
?
pThank you for your message, we will be in contact shortly if
nessary./p
Expected result:
the thank you message appear on the page
Actual result:
--
I get the page cannot be displayed message from internet explorer
indicating apache's basically not running, but on refresh the orginal
email us submittal form comes up blank as if it has ben loaded up for
the first time (which stands to reason if apache's crashed or
restarted).
FYI: the format of the page is an 'email us' form with the form's
action being the same page, then if(isset(Submit)){...} is used execute
the mail() when sumbmited.
--
Edit this bug report at http://bugs.php.net/?id=30770edit=1
#30952 [Opn-Bgs]: libpng.so.3 error after compiling php5.0.3rc1 with gd
ID: 30952 Updated by: [EMAIL PROTECTED] Reported By: iansutherland75 at gmail dot com -Status: Open +Status: Bogus Bug Type: GD related Operating System: Fedora Core 3 PHP Version: 5.0.2 New Comment: That's an SELinux labelling issue - run: # fixfiles restore or disable enforcement of the Apache/SELinux policy: # setsebool httpd_disable_trans 1 Previous Comments: [2004-12-01 20:44:34] iansutherland75 at gmail dot com Description: I get this error message whenever I try to start apache now that I've compiled PHP5.0.3rc1 with GD. quote: Failed to start apache : Starting httpd: Syntax error on line 190 of /etc/httpd/conf/httpd.conf: Cannot load /usr/lib/httpd/modules/libphp5.so into server: libpng.so.3: failed to map segment from shared object: Permission denied [FAILED] My server is Fedora core 3, and I've got libgd, libgd-devel, libgd-progs, libpng, libpng-devel, libjpeg, and libjpeg-devel all installed. I've confirmed that libpng.so.3 is in my /usr/lib/ folder and I even chmod'd it to 777 to make sure I had ok permissions. -- Edit this bug report at http://bugs.php.net/?id=30952edit=1
#30835 [Bgs]: PHP5 won't configure with mysqli support on Intel EM64T
ID: 30835
Updated by: [EMAIL PROTECTED]
Reported By: noethen at daad dot de
Status: Bogus
Bug Type: Compile Failure
Operating System: SuSE Linux Enterprise Server 9
PHP Version: 5.0.2
New Comment:
And the MySQL-devel package is also installed? What's the output of:
$ mysql_config --libs
Previous Comments:
[2004-12-01 10:51:51] noethen at daad dot de
I _am_ using a native x86_64 build of MySQL
(MySQL-server-4.1.7-0.glibc23.x86_64.rpm).
[2004-11-30 17:32:51] [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
You cannot use 32-bit libraries (e.g. from
MySQL-client-4.1.7-0.i386.rpm) in a 64-bit PHP build.
Either use a native x86_64 build of MySQL (recommended), or try and
build a 32-bit version of PHP (not recommended). The latter can be
done using:
export CC=gcc -m32
before running configure.
[2004-11-30 03:21:58] jfxberns at hotmail dot com
Same problem.
./configure --with-mysqli=/usr/bin/mysql_config
AMD Athlon XP CPU,
Apache 1.3.33,
Redhat Linux 7.3,
PHP 5.0.2,
MySQL 4.1.7 installed as RPM, upgraded from 4.0.22
MySQL packages installed:
MySQL-bench-4.1.7-0.i386.rpm
MySQL-client-4.1.7-0.i386.rpm
MySQL-devel-4.1.7-0.i386.rpm
MySQL-server-4.1.7-0.i386.rpm
MySQL-shared-4.1.7-0.i386.rpm
MySQL-shared-compat-4.1.7-0.i386.rpm
[2004-11-19 13:22:18] noethen at daad dot de
Description:
My System is
SuSE Linux Enterprise Server 9
on Intel EM64T CPU
with MySQL 4.1.7 installed from MySQL RPM package
and Apache 2.0.52 installed from SuSE RPM package
Everything runs fine so far, including Apache and MySQL.
I try to configure PHP 5.0.2 with the following command:
./configure --with-apxs2=/usr/sbin/apxs2
--with-mysqli=/usr/bin/mysql_config
The configuration process breaks with the following lines:
checking for MySQLi support... yes
checking whether to enable embedded MySQLi support... no
checking for mysql_set_server_option in -lmysqlclient... no
configure: error: wrong mysql library version or lib not
found. Check config.log for more information.
These are the last lines of config.log:
configure:54936: checking for MySQLi support
configure:54982: checking whether to enable embedded MySQLi
support
configure:55115: checking for mysql_set_server_option in
-lmysqlclient
configure:55134: gcc -o conftest -g -O2 -lmysqlclient
-lcrypt -lnsl -lm -lz conftest.c
-lmysqlclient -lresolv -lm -ldl -lnsl
-lxml2 -lz -lm -lxml2 -lz -lm 15
/usr/lib64/gcc-lib/x86_64-suse-linux/3.3.3
/../../../../x86_64-suse-linux/bin/ld:
cannot find -lmysqlclient
collect2: ld returned 1 exit status
configure: failed program was:
#line 55123 configure
#include confdefs.h
/* Override any gcc2 internal prototype to avoid an error.
*/
/* We use char because int might match the return type of a
gcc2 builtin and then its argument prototype would still
apply. */
char mysql_set_server_option();
int main() {
mysql_set_server_option()
; return 0; }
--
Edit this bug report at http://bugs.php.net/?id=30835edit=1
#30835 [Opn-Bgs]: PHP5 won't configure with mysqli support on Intel EM64T
ID: 30835
Updated by: [EMAIL PROTECTED]
Reported By: noethen at daad dot de
-Status: Open
+Status: Bogus
Bug Type: Compile Failure
Operating System: SuSE Linux Enterprise Server 9
PHP Version: 5.0.2
New Comment:
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
You cannot use 32-bit libraries (e.g. from
MySQL-client-4.1.7-0.i386.rpm) in a 64-bit PHP build.
Either use a native x86_64 build of MySQL (recommended), or try and
build a 32-bit version of PHP (not recommended). The latter can be
done using:
export CC=gcc -m32
before running configure.
Previous Comments:
[2004-11-30 03:21:58] jfxberns at hotmail dot com
Same problem.
./configure --with-mysqli=/usr/bin/mysql_config
AMD Athlon XP CPU,
Apache 1.3.33,
Redhat Linux 7.3,
PHP 5.0.2,
MySQL 4.1.7 installed as RPM, upgraded from 4.0.22
MySQL packages installed:
MySQL-bench-4.1.7-0.i386.rpm
MySQL-client-4.1.7-0.i386.rpm
MySQL-devel-4.1.7-0.i386.rpm
MySQL-server-4.1.7-0.i386.rpm
MySQL-shared-4.1.7-0.i386.rpm
MySQL-shared-compat-4.1.7-0.i386.rpm
[2004-11-19 13:22:18] noethen at daad dot de
Description:
My System is
SuSE Linux Enterprise Server 9
on Intel EM64T CPU
with MySQL 4.1.7 installed from MySQL RPM package
and Apache 2.0.52 installed from SuSE RPM package
Everything runs fine so far, including Apache and MySQL.
I try to configure PHP 5.0.2 with the following command:
./configure --with-apxs2=/usr/sbin/apxs2
--with-mysqli=/usr/bin/mysql_config
The configuration process breaks with the following lines:
checking for MySQLi support... yes
checking whether to enable embedded MySQLi support... no
checking for mysql_set_server_option in -lmysqlclient... no
configure: error: wrong mysql library version or lib not
found. Check config.log for more information.
These are the last lines of config.log:
configure:54936: checking for MySQLi support
configure:54982: checking whether to enable embedded MySQLi
support
configure:55115: checking for mysql_set_server_option in
-lmysqlclient
configure:55134: gcc -o conftest -g -O2 -lmysqlclient
-lcrypt -lnsl -lm -lz conftest.c
-lmysqlclient -lresolv -lm -ldl -lnsl
-lxml2 -lz -lm -lxml2 -lz -lm 15
/usr/lib64/gcc-lib/x86_64-suse-linux/3.3.3
/../../../../x86_64-suse-linux/bin/ld:
cannot find -lmysqlclient
collect2: ld returned 1 exit status
configure: failed program was:
#line 55123 configure
#include confdefs.h
/* Override any gcc2 internal prototype to avoid an error.
*/
/* We use char because int might match the return type of a
gcc2 builtin and then its argument prototype would still
apply. */
char mysql_set_server_option();
int main() {
mysql_set_server_option()
; return 0; }
--
Edit this bug report at http://bugs.php.net/?id=30835edit=1
#30943 [Fbk-Bgs]: Server problem
ID: 30943
Updated by: [EMAIL PROTECTED]
Reported By: ARM_ARAM at yahoo dot com
-Status: Feedback
+Status: Bogus
Bug Type: Reproducible crash
Operating System: Windows XP
PHP Version: 4.3.9
New Comment:
Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same.
Thank you for your interest in PHP.
This is a duplicate of bug 26771, ISTR this fails on any Win32
(threaded in 1.3 or 2.0).
Previous Comments:
[2004-11-30 14:53:48] [EMAIL PROTECTED]
Also, please, try latest PHP4 CVS snapshot first.
[2004-11-30 14:43:36] [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.
[2004-11-30 14:36:21] ARM_ARAM at yahoo dot com
Description:
Standart Php.ini set
Reproduce code:
---
?php
function pr()
{
echo 'okbr';
}
register_tick_function(pr);
pr();
declare(ticks=2) {
for ($x = 1; $x 50; ++$x) {}}
?
Expected result:
output ok
Actual result:
--
Apache.exe has encountered a problem and needs to close. We are sorry
for the inconvenience.
--
Edit this bug report at http://bugs.php.net/?id=30943edit=1
#30695 [Asn]: 0x80000000 treated as 0x7fffffff
ID: 30695 Updated by: [EMAIL PROTECTED] Reported By: php_bug at cklowe dot com Status: Assigned Bug Type: Math related Operating System: Win32 PHP Version: 4CVS-2004-11-05 (stable) -Assigned To: jorton +Assigned To: andi New Comment: I don't have Zend commit access. Previous Comments: [2004-11-26 13:46:54] [EMAIL PROTECTED] gcc bugfix seems to be creating more trouble that its worth. please revert it before we release 4.3.10. [2004-11-14 23:51:31] php_bug at cklowe dot com Yes, given the implications I believe a reversion would be wise. [2004-11-10 23:11:20] [EMAIL PROTECTED] THis is a change most likely caused by Joe's patches to it. I say we should revert it as it breaks too many scripts. [2004-11-10 19:30:11] php_bug at cklowe dot com I see your point, and I'm happy that integers are unsigned. What worries me is that large hex initialisers (= 0x8000) are not doing their job. This is a change in behaviour. Python v 2.4 and above, uses Large Integers for 0x8000 which seems acceptable. In previous versions it did the Right Thing and treated 0x8000 as -214783648. Bitwise operations work as expected. PHP did the Right Thing in version 4.3.8. As of the current snapshot it no longer does the Right Thing. [2004-11-10 18:59:13] [EMAIL PROTECTED] This is *not* a signed/unsigned integer problem No, why? It is. And it can be clearly seen in this example: ? define (BIG_NUM, 0x8000); $big_var = 0x8000; printf(%u, %u\n, BIG_NUM, $big_var); printf(%f, %f\n, BIG_NUM, $big_var); ? Overflown integers are treated as floats and you cannot use bitwise operators on floats (as I understand you use them to check access privileges). 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/30695 -- Edit this bug report at http://bugs.php.net/?id=30695edit=1
#29107 [Opn-Fbk]: Parent: child process exited with status 3221225725
ID: 29107
Updated by: [EMAIL PROTECTED]
Reported By: bart at mediawave dot nl
-Status: Open
+Status: Feedback
Bug Type: Apache2 related
Operating System: Win2k
PHP Version: 4.3.7
New Comment:
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
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.
Previous Comments:
[2004-08-13 05:20:02] loye dot young at iycc dot net
If you have the PEAR Date package installed, this may be the problem:
There is a command in a Pear function that tries to write information
to the server. Some Windows installations and Unix servers with strict
Safe Mode options enabled do not allow this. You can fix this yourself
however.
Open the file lib/pear/Date/TimeZone.php in a text editor. Go to line
247. You should be in a function named 'inDaylightTime()'. Add this
line: return date(I); at the very top of the function. It should now
look like this:
function inDaylightTime($date)
{
return date(I);
$env_tz = ;
if(getenv(TZ))
$env_tz = getenv(TZ);
putenv(TZ=.$this-id);
$ltime = localtime($date-getTime(), true);
putenv(TZ=.$env_tz);
return $ltime['tm_isdst'];
}
This should stop the error. Perhaps in the future, the Pear team will
supply a work around.
See if that fixes it and let everyone know.
[2004-07-23 15:55:42] bart at mediawave dot nl
I don't think that's my problem. I'm having the problem at my testing
server where, most of the time, I'm the only client. So ,if persistent
connections work like they should I guess, in my case, there's only one
conection there.
[2004-07-23 15:34:59] super_freax at hotmail dot com
It says in the PHP-manual for child operations that :
This means that for every child that opened a persistent connection
will have its own open persistent connection to the server. For
example, if you had 20 different child processes that ran a script that
made a persistent connection to your SQL server, you'd have 20 different
connections to the SQL server, one from each child.
Note, however, that this can have some drawbacks if you are using a
database with connection limits that are exceeded by persistent child
connections. If your database has a limit of 16 simultaneous
connections, and in the course of a busy server session, 17 child
threads attempt to connect, one will not be able to. If there are bugs
in your scripts which do not allow the connections to shut down (such
as infinite loops), the database with only 16 connections may be
rapidly swamped
==
So it might be the database that has no more connections left ?
My Config is :
WinXPProSP1 (NTFS Formatted)
Apache version 2.0.49
MySQL 4.0.18 with MyODBC 3.51 and winMYSQLadmin 1.4
PHP 4.3.6 with Pear 1.3.1 ,Smarty 2.5.0 ,Zend Opt. 2.5.0 , Dbg 2.16.3,
TCL 8.4.5 with TK 8.4 and Vtcl 1.6.0
[2004-07-13 12:57:28] bart at mediawave dot nl
That didn't work. I still get the error.
[2004-07-12 23:20:10] bart at mediawave dot nl
I disabled some extenions. It seems to run stable now.
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/29107
--
Edit this bug report at http://bugs.php.net/?id=29107edit=1
#30790 [Opn-Bgs]: Apache worker crash sending data
ID: 30790 Updated by: [EMAIL PROTECTED] Reported By: stolle at web dot de -Status: Open +Status: Bogus Bug Type: Reproducible crash Operating System: Windows XP PHP Version: 5.0.2 New Comment: This is bug 25570 - try the patch: http://cvs.apache.org/~jorton/php_abort.diff or use any of the snapshots from http://snaps.php.net/ Previous Comments: [2004-11-15 08:58:12] stolle at web dot de Description: Apache Support has forwarded me to use the PHP-Reporting System. Try the small script. The used file c:\temp\x3.iso may be of a size a 20 MB or so. I used an iso-Image of something. But content doesn't matter. If the file-Transfer is interrupted by the client (IE closed f.e.) the Apache worker crashes. If you eleminate the while everything is ok. This is only a simplified Script. Everytime when sending data throug an php script, from whithin a while-loop, or any other language construct, the worker crashes when connection is lost. I'm using XP SP2, Apache 2.0.52 and PHP 5.0.2 I tried the 3 Apache config lines: EnableSendfile Off EnableMMAP Off Win32DisableAcceptEx No difference. Worker crashes. We can't continue developing our php-Application (Alternativ User Interface for Multimedia Home-Devices), Subproject: Streaming Video-Content, if we can't fix this bug. Help would be great. sorry for my english ;) Yours Andreas Reproduce code: --- ?php error_log( Hei ); $fh = fopen( c:/temp/x3.iso, rb ); while ( !feof($fh) ) fpassthru( $fh ); ? Expected result: Apache worker should not crash if connection is lost. Actual result: -- [Thu Nov 11 17:17:02 2004] [notice] Parent: child process exited with status 4294967295 -- Restarting. [Thu Nov 11 17:17:03 2004] [notice] Parent: Created child process 4968 [Thu Nov 11 17:17:03 2004] [notice] Disabled use of AcceptEx() WinSock2 API [Thu Nov 11 17:17:03 2004] [notice] Child 4968: Child process is running [Thu Nov 11 17:17:03 2004] [notice] Child 4968: Acquired the start mutex. [Thu Nov 11 17:17:03 2004] [notice] Child 4968: Starting 250 worker threads. [Thu Nov 11 17:17:03 2004] [notice] Child 4968: Listening on port 8001. -- Edit this bug report at http://bugs.php.net/?id=30790edit=1
#30742 [Opn-Bgs]: In FC3, Curl 7.12.1 compiling with PHP fails
ID: 30742
Updated by: [EMAIL PROTECTED]
Reported By: mukul at iastate dot edu
-Status: Open
+Status: Bogus
Bug Type: Compile Failure
Operating System: Fedora Core 3
PHP Version: 5.0.2
New Comment:
The FC3 curl-devel package should have a dependency on libidn-devel,
this is already addressed for future versions. The fix is to install
libidn-devel, this isn't a PHP bug.
Previous Comments:
[2004-11-10 07:20:36] mukul at iastate dot edu
Description:
Hello,
In FC3, Curl 7.12.1, PHP doesn't compile with cURL. It says -lidn could
not be found by ld.
I did a ldconfig -p | grep idn ... and found it to be there.
The config.log where this might be there :
crypto -lssl -lcrypto -lgssapi_krb5 -lkrb5 -lcom_err -lk5crypto
-lresolv -ldl -lz -lz 15
/usr/bin/ld: cannot find -lidn
collect2: ld returned 1 exit status
configure: failed program was:
#line 22646 configure
#include confdefs.h
/* Override any gcc2 internal prototype to avoid an error. */
/* We use char because int might match the return type of a gcc2
builtin and then its argument prototype would still apply. */
char curl_easy_perform();
int main() {
curl_easy_perform()
--
Edit this bug report at http://bugs.php.net/?id=30742edit=1
#28403 [Sus]: ORA dll make apache child process crash and restart Apache
ID: 28403 Updated by: [EMAIL PROTECTED] Reported By: scouture at novo dot ca Status: Suspended -Bug Type: Apache2 related +Bug Type: OCI8 related Operating System: win 2003 server PHP Version: 4.3.7 New Comment: Reproduced on 1.3 - not apache related, some Oracle threading issue. Previous Comments: [2004-09-02 15:03:16] scouture at novo dot ca Note that I have also experimented this issue with MySql on a Xeon dual procs server. I have find that if I run php with the .dll like LoadModule php4_module d:/Program Files/php/sapi/php4apache2.dll, I get the bug. If I run php with Action application/x-httpd-php /php/php.exe, I don't seem to have it, so far [2004-07-22 21:42:06] [EMAIL PROTECTED] There is a possilbe fix in the cvs version of both php4 and 5. Could you please check it out by downloading it from http://snaps.php.net/ ? [2004-07-22 11:15:53] alain dot bertrand at psi dot ch BTW running on a dual CPU here, and it crash every 5 minutes :-( [2004-07-22 11:14:28] alain dot bertrand at psi dot ch I'm having the same bug with PHP 4.3.4, Oracle 9i and Windows 2003 Server. So it's maybe linked to 9i and windows 2003. Will check out with 10i hoping it will fix this bug. High rated for me. Alain Bertrand [2004-07-15 10:42:24] Lukas dot Theiler at ch dot ibm dot com Running longer tests, even single-cpu systems fail. (after 7hours 1st, 1h34 2nd crash, 6h23 3rd crash...) 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/28403 -- Edit this bug report at http://bugs.php.net/?id=28403edit=1
#30558 [Com]: mbstring mbregex failure to compile pointer cast problems
ID: 30558 Comment by: jorton at redhat dot com Reported By: jbarwick at sentienthealth dot com Status: Feedback Bug Type: Compile Failure Operating System: SuSE 9.1 (amd64) PHP Version: 4.3.8 New Comment: gcc -Wall output for ext/mbstring from amd64 build of HEAD: ext/mbstring/oniguruma/regexec.c: In function `match_at': ext/mbstring/oniguruma/regexec.c:1106: warning: cast to pointer from integer of different size ext/mbstring/oniguruma/regexec.c:1110: warning: cast to pointer from integer of different size ext/mbstring/oniguruma/regexec.c:1126: warning: cast to pointer from integer of different size ext/mbstring/oniguruma/regexec.c:1130: warning: cast to pointer from integer of different size ext/mbstring/oniguruma/regexec.c:1763: warning: cast from pointer to integer of different size ext/mbstring/oniguruma/regexec.c:1777: warning: cast from pointer to integer of different size ext/mbstring/oniguruma/regexec.c:1794: warning: cast from pointer to integer of different size ext/mbstring/oniguruma/regexec.c:1800: warning: cast from pointer to integer of different size ext/mbstring/oniguruma/regexec.c:1839: warning: cast to pointer from integer of different size ext/mbstring/oniguruma/regexec.c:1843: warning: cast to pointer from integer of different size ext/mbstring/oniguruma/regexec.c:1871: warning: cast to pointer from integer of different size ext/mbstring/oniguruma/regexec.c:1875: warning: cast to pointer from integer of different size ext/mbstring/oniguruma/regexec.c:1903: warning: cast to pointer from integer of different size ext/mbstring/oniguruma/regexec.c:1907: warning: cast to pointer from integer of different size ext/mbstring/oniguruma/regexec.c:1942: warning: cast to pointer from integer of different size ext/mbstring/oniguruma/regexec.c:1946: warning: cast to pointer from integer of different size ext/mbstring/oniguruma/regexec.c:2027: warning: cast to pointer from integer of different size ext/mbstring/oniguruma/regexec.c:2050: warning: cast to pointer from integer of different size ext/mbstring/oniguruma/regexec.c:1138: warning: `pstart' might be used uninitialized in this function ext/mbstring/oniguruma/regparse.c: In function `not_code_range_buf': ext/mbstring/oniguruma/regparse.c:1628: warning: `to' might be used uninitialized in this function ext/mbstring/libmbfl/filters/mbfilter_htmlent.c: In function `mbfl_filt_conv_html_dec_ctor': ext/mbstring/libmbfl/filters/mbfilter_htmlent.c:161: warning: cast from pointer to integer of different size ext/mbstring/libmbfl/filters/mbfilter_htmlent.c: In function `mbfl_filt_conv_html_dec_dtor': ext/mbstring/libmbfl/filters/mbfilter_htmlent.c:169: warning: cast to pointer from integer of different size ext/mbstring/libmbfl/filters/mbfilter_htmlent.c: In function `mbfl_filt_conv_html_dec': ext/mbstring/libmbfl/filters/mbfilter_htmlent.c:178: warning: cast to pointer from integer of different size ext/mbstring/libmbfl/filters/mbfilter_htmlent.c: In function `mbfl_filt_conv_html_dec_flush': ext/mbstring/libmbfl/filters/mbfilter_htmlent.c:249: warning: cast to pointer from integer of different size Previous Comments: [2004-11-04 13:09:36] [EMAIL PROTECTED] Please, provide all warnings and/or errors you get. [2004-10-26 09:41:03] jbarwick at sentienthealth dot com Description: The entire MBREGEX.C object appears to be written with pointer address math using int variables. Whereas we all know that with the invent of i586/i686 systems the int veriable is nicely 32 bit, in a 64 bit environment, the pointers and the uint/int objects become completely incompatible. (Am I crazy here?)...or completely stupid? Anyway...lot's of pointer errors in mbstring/mbregex. It appears that this module is totally unusable in a 64-bit environment. To FIX, I did the following mbstring/mbregex/mbregex.h #define MINT long #define MLONG long The changed all int's to MINT and changed all long's to MLONG with a nice search and replace. Compiled with no compiler warnings (retesting make clean/make as we speak). It actually appears that the entire mbstring object must be completely re-written. S much pointer math using int's and so many cast from pointer to integer of different size errors. any chance of getting 4.3.9 or 4.3.10 compilable for 64-bit? I have a lot of work left to fix all the mbstring files that wont compile correctly...eg!!! PLEASE someone tell me I can ignore these because the pointer math works even when the compiler complains!! Reproduce code: --- compile mbstring/mbregex.c Expected result: no compiler warnings about bad pointers Actual result: -- compiler warnings about bad pointers -- Edit this bug
#30558 [Fbk-Asn]: Interpreter crashes reproducibly (2)
ID: 30558 Updated by: [EMAIL PROTECTED] -Summary: mbstring mbregex failure to compile pointer cast problems Reported By: jbarwick at sentienthealth dot com -Status: Feedback +Status: Assigned Bug Type: Compile Failure -Operating System: SuSE 9.1 (amd64) +Operating System: WinXP SP1 -PHP Version: 4.3.8 +PHP Version: 5CVS-2004-04-22 (dev) -Assigned To: +Assigned To: moriyoshi New Comment: I'm not sure if jbarwick's suggested fix: The changed all int's to MINT and changed all long's to MLONG is really advisable; Moriyoshi, have you looked at this? ISTR it being mentioned before on php-dev. Previous Comments: [2004-11-04 14:27:17] jorton at redhat dot com gcc -Wall output for ext/mbstring from amd64 build of HEAD: ext/mbstring/oniguruma/regexec.c: In function `match_at': ext/mbstring/oniguruma/regexec.c:1106: warning: cast to pointer from integer of different size ext/mbstring/oniguruma/regexec.c:1110: warning: cast to pointer from integer of different size ext/mbstring/oniguruma/regexec.c:1126: warning: cast to pointer from integer of different size ext/mbstring/oniguruma/regexec.c:1130: warning: cast to pointer from integer of different size ext/mbstring/oniguruma/regexec.c:1763: warning: cast from pointer to integer of different size ext/mbstring/oniguruma/regexec.c:1777: warning: cast from pointer to integer of different size ext/mbstring/oniguruma/regexec.c:1794: warning: cast from pointer to integer of different size ext/mbstring/oniguruma/regexec.c:1800: warning: cast from pointer to integer of different size ext/mbstring/oniguruma/regexec.c:1839: warning: cast to pointer from integer of different size ext/mbstring/oniguruma/regexec.c:1843: warning: cast to pointer from integer of different size ext/mbstring/oniguruma/regexec.c:1871: warning: cast to pointer from integer of different size ext/mbstring/oniguruma/regexec.c:1875: warning: cast to pointer from integer of different size ext/mbstring/oniguruma/regexec.c:1903: warning: cast to pointer from integer of different size ext/mbstring/oniguruma/regexec.c:1907: warning: cast to pointer from integer of different size ext/mbstring/oniguruma/regexec.c:1942: warning: cast to pointer from integer of different size ext/mbstring/oniguruma/regexec.c:1946: warning: cast to pointer from integer of different size ext/mbstring/oniguruma/regexec.c:2027: warning: cast to pointer from integer of different size ext/mbstring/oniguruma/regexec.c:2050: warning: cast to pointer from integer of different size ext/mbstring/oniguruma/regexec.c:1138: warning: `pstart' might be used uninitialized in this function ext/mbstring/oniguruma/regparse.c: In function `not_code_range_buf': ext/mbstring/oniguruma/regparse.c:1628: warning: `to' might be used uninitialized in this function ext/mbstring/libmbfl/filters/mbfilter_htmlent.c: In function `mbfl_filt_conv_html_dec_ctor': ext/mbstring/libmbfl/filters/mbfilter_htmlent.c:161: warning: cast from pointer to integer of different size ext/mbstring/libmbfl/filters/mbfilter_htmlent.c: In function `mbfl_filt_conv_html_dec_dtor': ext/mbstring/libmbfl/filters/mbfilter_htmlent.c:169: warning: cast to pointer from integer of different size ext/mbstring/libmbfl/filters/mbfilter_htmlent.c: In function `mbfl_filt_conv_html_dec': ext/mbstring/libmbfl/filters/mbfilter_htmlent.c:178: warning: cast to pointer from integer of different size ext/mbstring/libmbfl/filters/mbfilter_htmlent.c: In function `mbfl_filt_conv_html_dec_flush': ext/mbstring/libmbfl/filters/mbfilter_htmlent.c:249: warning: cast to pointer from integer of different size [2004-11-04 13:09:36] [EMAIL PROTECTED] Please, provide all warnings and/or errors you get. [2004-10-26 09:41:03] jbarwick at sentienthealth dot com Description: The entire MBREGEX.C object appears to be written with pointer address math using int variables. Whereas we all know that with the invent of i586/i686 systems the int veriable is nicely 32 bit, in a 64 bit environment, the pointers and the uint/int objects become completely incompatible. (Am I crazy here?)...or completely stupid? Anyway...lot's of pointer errors in mbstring/mbregex. It appears that this module is totally unusable in a 64-bit environment. To FIX, I did the following mbstring/mbregex/mbregex.h #define MINT long #define MLONG long The changed all int's to MINT and changed all long's to MLONG with a nice search and replace. Compiled with no compiler warnings (retesting make clean/make as we speak). It actually appears that the entire mbstring object must be completely re-written. S much pointer math using int's and so many cast from pointer to integer of different size errors
#30558 [Asn]: mbstring mbregex failure to compile pointer cast problems
ID: 30558 Updated by: [EMAIL PROTECTED] -Summary: Interpreter crashes reproducibly (2) Reported By: jbarwick at sentienthealth dot com Status: Assigned Bug Type: Compile Failure -Operating System: WinXP SP1 +Operating System: SuSE 9.1 (amd64) -PHP Version: 5CVS-2004-04-22 (dev) +PHP Version: 4.3.8 Assigned To: moriyoshi New Comment: Grrr, fixing version/OS again. Previous Comments: [2004-11-04 14:37:07] [EMAIL PROTECTED] I'm not sure if jbarwick's suggested fix: The changed all int's to MINT and changed all long's to MLONG is really advisable; Moriyoshi, have you looked at this? ISTR it being mentioned before on php-dev. [2004-11-04 14:27:17] jorton at redhat dot com gcc -Wall output for ext/mbstring from amd64 build of HEAD: ext/mbstring/oniguruma/regexec.c: In function `match_at': ext/mbstring/oniguruma/regexec.c:1106: warning: cast to pointer from integer of different size ext/mbstring/oniguruma/regexec.c:1110: warning: cast to pointer from integer of different size ext/mbstring/oniguruma/regexec.c:1126: warning: cast to pointer from integer of different size ext/mbstring/oniguruma/regexec.c:1130: warning: cast to pointer from integer of different size ext/mbstring/oniguruma/regexec.c:1763: warning: cast from pointer to integer of different size ext/mbstring/oniguruma/regexec.c:1777: warning: cast from pointer to integer of different size ext/mbstring/oniguruma/regexec.c:1794: warning: cast from pointer to integer of different size ext/mbstring/oniguruma/regexec.c:1800: warning: cast from pointer to integer of different size ext/mbstring/oniguruma/regexec.c:1839: warning: cast to pointer from integer of different size ext/mbstring/oniguruma/regexec.c:1843: warning: cast to pointer from integer of different size ext/mbstring/oniguruma/regexec.c:1871: warning: cast to pointer from integer of different size ext/mbstring/oniguruma/regexec.c:1875: warning: cast to pointer from integer of different size ext/mbstring/oniguruma/regexec.c:1903: warning: cast to pointer from integer of different size ext/mbstring/oniguruma/regexec.c:1907: warning: cast to pointer from integer of different size ext/mbstring/oniguruma/regexec.c:1942: warning: cast to pointer from integer of different size ext/mbstring/oniguruma/regexec.c:1946: warning: cast to pointer from integer of different size ext/mbstring/oniguruma/regexec.c:2027: warning: cast to pointer from integer of different size ext/mbstring/oniguruma/regexec.c:2050: warning: cast to pointer from integer of different size ext/mbstring/oniguruma/regexec.c:1138: warning: `pstart' might be used uninitialized in this function ext/mbstring/oniguruma/regparse.c: In function `not_code_range_buf': ext/mbstring/oniguruma/regparse.c:1628: warning: `to' might be used uninitialized in this function ext/mbstring/libmbfl/filters/mbfilter_htmlent.c: In function `mbfl_filt_conv_html_dec_ctor': ext/mbstring/libmbfl/filters/mbfilter_htmlent.c:161: warning: cast from pointer to integer of different size ext/mbstring/libmbfl/filters/mbfilter_htmlent.c: In function `mbfl_filt_conv_html_dec_dtor': ext/mbstring/libmbfl/filters/mbfilter_htmlent.c:169: warning: cast to pointer from integer of different size ext/mbstring/libmbfl/filters/mbfilter_htmlent.c: In function `mbfl_filt_conv_html_dec': ext/mbstring/libmbfl/filters/mbfilter_htmlent.c:178: warning: cast to pointer from integer of different size ext/mbstring/libmbfl/filters/mbfilter_htmlent.c: In function `mbfl_filt_conv_html_dec_flush': ext/mbstring/libmbfl/filters/mbfilter_htmlent.c:249: warning: cast to pointer from integer of different size [2004-11-04 13:09:36] [EMAIL PROTECTED] Please, provide all warnings and/or errors you get. [2004-10-26 09:41:03] jbarwick at sentienthealth dot com Description: The entire MBREGEX.C object appears to be written with pointer address math using int variables. Whereas we all know that with the invent of i586/i686 systems the int veriable is nicely 32 bit, in a 64 bit environment, the pointers and the uint/int objects become completely incompatible. (Am I crazy here?)...or completely stupid? Anyway...lot's of pointer errors in mbstring/mbregex. It appears that this module is totally unusable in a 64-bit environment. To FIX, I did the following mbstring/mbregex/mbregex.h #define MINT long #define MLONG long The changed all int's to MINT and changed all long's to MLONG with a nice search and replace. Compiled with no compiler warnings (retesting make clean/make as we speak). It actually appears that the entire mbstring object must be completely re-written. S much pointer math using int's and so
#28029 [Opn-Fbk]: HTTP request failed!
ID: 28029
Updated by: [EMAIL PROTECTED]
Reported By: coadmin at hostings dot pl
-Status: Open
+Status: Feedback
Bug Type: URL related
Operating System: FreeBSD 4.9 and 5.2.1
PHP Version: 4CVS-2004-04-16 (stable)
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php5-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.0-win32-latest.zip
If using fsockopen and friends on servers with large numbers of error
logs configured and seeing memory corruption bugs or otherwise, then
that's bug 24189 - select vs FD_SETSIZE issues.
This is fixed for future 5.0.x releases (all praise Wez!), so try a
5.0.x snapshot. Bugs in Fedora Core or RHEL PHP packages should be
reported to https://bugzilla.redhat.com/bugzilla/.
Previous Comments:
[2004-11-01 15:51:16] tongsam at 126 dot com
I'v this problem too, on apache started a few hours, the logs:
kernel: pid 65604 (httpd), uid 1011: exited on signal 11
Freebsd 4.9 + Apache 2.0.52 + php 4.3.9
[2004-10-08 01:02:52] joseph at digiweb dot net dot nz
Apache 2.0.46
PHP 4.3.2
Redhat Enterprise 3.0
We were seeing very similar behaviour to this with fopen, getimagesize,
etc, however, we were not experiencing any segfaults.
What we found was that first, the number of VirtualHosts we had defined
would affect the behaviour of this bug: If we had more than 502
virtualhosts, the fopen HTTP requests would fail, if we had 502 or
less, they would work correctly.
We thought it might have something to do with the number of open file
handles, but as far as we could tell, we were well clear of these
limits.
Then (basically by accident) we worked out that if we had each
VirtualHost use the same, global ErrorLog file, the problem went
away, as opposed to the situation before when we had seperate error
logs for each virtualhost.
We also had another test box, running Fedora Core 2, Apache 2.0.51, and
PHP 5.02, on which we were unable to reproduce the problem.
I hope this might possibly shed some light on things.
[2004-09-02 00:02:10] maximander at gmail dot com
this has been happening to my site too.
the following code errors, as does almost any use of
file(),fopen(),file_get_contents() or readfile() on remote files.
fsockopen seems to work for now though.
?
// error'ing code
$file = file(http://gerpok.darkflux.com/write.php;);
if(strpos($file[0],you don't)) { echo not updated;}
?
and, whats more, after a recompile with --enable-debug, it is still
error'ing. anything useful we can do with a debug build that errors on
a regular basis?
[2004-08-18 08:58:26] andreizilla at gmail dot com
I'm having simular (same?) problems on:
* FreeBSD zig.andreib.com 5.2.1-RELEASE-p9 FreeBSD 5.2.1-RELEASE-p9 #0:
Sun Aug 15 18:42:43 CDT 2004
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/MYKERNEL i386
* Apache/1.3.31
* PHP Version 4.3.8 configuted with: './configure'
'--enable-versioning' '--enable-memory-limit' '--with-layout=GNU'
'--with-config-file-scan-dir=/usr/local/etc/php' '--disable-all'
'--with-regex=php' '--disable-cli' '--with-apxs=/usr/local/sbin/apxs'
'--disable-ipv6' '--prefix=/usr/local' 'i386-portbld-freebsd5.2.1'
Apache seems to be segfaulting every several minutes. This is what the
log files look like:
[Wed Aug 18 01:52:25 2004] [notice] child pid 18870 exit signal
Segmentation fault (11)
[Wed Aug 18 01:52:28 2004] [notice] child pid 18869 exit signal
Segmentation fault (11)
[Wed Aug 18 01:52:32 2004] [notice] child pid 18868 exit signal
Segmentation fault (11)
[Wed Aug 18 01:52:45 2004] [notice] child pid 18867 exit signal
Segmentation fault (11)
[Wed Aug 18 01:53:15 2004] [notice] child pid 18866 exit signal
Segmentation fault (11)
... times several hundred.
This also happends when I do `apachectl graceful'
If anyone knows where I can find more information on resolving this
problem please, please, please tell me. Thank you.
- andrei
[2004-07-25 14:02:46] coadmin at hostings dot pl
Hello,
sorry I couldn't use --disable-all on productive machine. There are too
many commercial hostings accounts.
But...
My problem was suddenly resolved about month ago before compiling
PHP. It was very strange. I didn't do any changes in Apache or PHP.
From one day up to now all is working correctly. There wasn't any HTTP
request failed!. Additionaly, I upgraded to 4.3.8 a week ago and there
is many many many less segfaults.
But... #2
On the other server (php 4.3.6) always was OK. After upgrade to PHP
4.3.8 I've again the same bug...
I really don't know what is it. Maybe it's OS releated? But as I see on
bug status,
#29537 [Opn-Bgs]: PHP Configure fails with mysql configure failed when trying to use 64bit libs
ID: 29537
Updated by: [EMAIL PROTECTED]
Reported By: martinkuria at hotmail dot com
-Status: Open
+Status: Bogus
Bug Type: MySQL related
Operating System: Solaris9
PHP Version: 4.3.8
New Comment:
If you want to use 64-bit MySQL libraries you'll need to build a 64-bit
PHP, i.e.:
export CC=/path/to/gcc -m64
if you want to build a 32-bit PHP, you'll have to use 32-bit MySQL
libraries.
Previous Comments:
[2004-11-02 00:07:54] epuening at cdir dot com
Same error using Solaris 8, Apache 2.052, PHP 5.02, mysql 5.01
Configured with the following options
./configure --with-apxs2=/usr/local/apache2/bin/apxs
--with-mysql=/usr/local/mysql/
--enable-dbase --with-libxml-dir=/usr/local/include/libxml2
Terminates with the following error
char mysql_close();
int main() {
mysql_close()
; return 0; }
configure:54501: checking for mysql_errno in -lmysqlclient
configure:54520: gcc -o conftest -g -O2 -D_POSIX_PTHREAD_SEMANTICS
-R/usr/local/mysql//lib -L/usr/local/mysql//lib -R/usr
/ucblib -L/usr/ucblib -R/usr/local/lib/gcc/sparc-sun-solaris2.8/3.4.1
-L/usr/local/lib/gcc/sparc-sun-solaris2.8/3.4.1 -R/us
r/local/lib -L/usr/local/lib conftest.c -lmysqlclient -lz -lresolv -lm
-ldl -lnsl -lsocket -lgcc -lxml2 -lz -liconv -lm -
lsocket -lnsl -lxml2 -lz -liconv -lm -lsocket -lnsl 15
ld: warning: file /usr/local/mysql//lib/libmysqlclient.a(client.o):
wrong ELF class: ELFCLASS64
Undefined first referenced
symbol in file
mysql_errno /var/tmp//ccQGgMLT.o
ld: fatal: Symbol referencing errors. No output written to conftest
collect2: ld returned 1 exit status
configure: failed program was:
#line 54509 configure
#include confdefs.h
/* Override any gcc2 internal prototype to avoid an error. */
/* We use char because int might match the return type of a gcc2
builtin and then its argument prototype would still apply. */
char mysql_errno();
int main() {
mysql_errno()
; return 0; }
[2004-10-19 13:13:30] royw at imsi dot com
Sorry for being a dumbass, in the above i'm using
Solaris 8, and php 5.0.1
Thanks
-Roy
[2004-10-19 13:11:25] royw at imsi dot com
I am also seeing this and concur with the 64bit version of mysql the
reason.
from config.log
==
configure:54351: gcc -o conftest -g -O2 -pthreads
-D_POSIX_PTHREAD_SEMANTICS -D
_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -R/usr/local/mysql/lib
-L/usr/local/mysql/
lib -R/usr/local/lib -L/usr/local/lib -R/usr/ucblib -L/usr/ucblib
-R/local/u1/l
ocal/bin/../lib/gcc/sparc-sun-solaris2.8/3.4.0
-L/local/u1/local/bin/../lib/gcc/
sparc-sun-solaris2.8/3.4.0 -R/usr/local/lib -L/usr/local/lib
-R/usr/local -L/usr
/local conftest.c -lmysqlclient -lz -lldap -llber -lz -lresolv -lm
-ldl -lnsl -
lsocket -lgcc -lxml2 -liconv -lm -lsocket -lnsl -lxml2 -liconv -lm
-lsocket -ln
sl 15
ld: warning: file /usr/local/mysql/lib/libmysqlclient.a(libmysql.o):
wrong ELF c
lass: ELFCLASS64
Undefined first referenced
symbol in file
mysql_error /var/tmp//ccOaQw7R.o
ld: fatal: Symbol referencing errors. No output written to conftest
collect2: ld returned 1 exit status
configure: failed program was:
#line 54340 configure
#include confdefs.h
/* Override any gcc2 internal prototype to avoid an error. */
/* We use char because int might match the return type of a gcc2
builtin and then its argument prototype would still apply. */
char mysql_error();
int main() {
mysql_error()
; return 0; }
==
Thanks
-Roy
[2004-10-18 03:54:14] rsm00th at hotmail dot com
I am having the same problem. It appears as though it wont compile
because we are running 64-bit MySQL.
[2004-09-19 11:53:51] wkaiser at mpimf-heidelberg dot mpg dot de
I experienced the same trying to upgrade my PHP / MySQL combination. I
am using Solaris 9 (on a SunFire V240), Apache 1.3.29, MySQL 4.0.l8 and
PHP 4.3.4. The MySQL Upgrade to 4.1.4-gamma worked fine (i just unpacked
the binaries, moved them to /usr/local besides the old ones and changed
the symbolic link). Then i unpacked the php-5.0.1 src file, adapted my
PATH vars and started configure:
bash-2.05# gunzip php-5.0.1.tar.gz | /usr/local/bin/tar xovf -
bash-2.05# cd php-5.0.1
bash-2.05# export CC=/usr/local/bin/gcc
bash-2.05# export LDFLAGS=-L/usr/lib -L/usr/local -L/usr/local/lib
-L/usr/local/mysql/lib -L/usr/local/ssl/lib -L/usr/local/lib/sasl2
bash-2.05# export CPPFLAGS=-I/usr/include -I/usr/local/include
-I/usr/local/mysql/include -I/usr/local/apache/include
#30563 [Bgs]: Apache doesn't start with PHP. No errors reported.
ID: 30563
Updated by: [EMAIL PROTECTED]
Reported By: david at donpiso dot com
Status: Bogus
Bug Type: Reproducible crash
Operating System: Linux 2.4.25
PHP Version: 4.3.9
New Comment:
The fact that your test:
gcc tst-libc6.c -o tst-libc6 -ldb
doesn't show up in ldd is dubious on the first machine. It may be
necessary to add:
extern int db_open(void);
to force the db_open symbol to be resolved at initial link time to
trigger the same conditions as in PHP.
To debug the PHP issue further you could use LD_DEBUG and
LD_DEBUG_OUTPUT (see man ld.so) and work out where the db_open() is
getting resolved to from nss_db. All the copies of the nss_db library
I have use a statically linked copy of Berkeley DB.
Previous Comments:
[2004-10-28 17:00:51] david at donpiso dot com
It doesn't break. Test program is:
#include netdb.h
#include stdio.h
int main(int argc, char *argv)
{
struct protoent *pe;
pe=getprotobyname(tcp);
printf(Name: %s, Number: %u\n,pe-p_name,pe-p_proto);
}
Tests are:
-Test 1:
gcc tst-libc6.c -o tst-libc6
ldd tst-libc6
libc.so.6 = /lib/libc.so.6 (0x40024000)
/lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x4000)
./tst-libc6
Name: tcp, Number: 6
-Test 2:
gcc tst-libc6.c -o tst-libc6 -ldb
ldd tst-libc6
libc.so.6 = /lib/libc.so.6 (0x40024000)
/lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x4000)
./tst-libc6
Name: tcp, Number: 6
-Test 3:
gcc tst-libc6.c -o tst-libc6 -lnss_db
ldd tst-libc6
libnss_db.so.2 = /lib/libnss_db.so.2 (0x40024000)
libc.so.6 = /lib/libc.so.6 (0x4002b000)
libnss_files.so.2 = /lib/libnss_files.so.2 (0x4014e000)
libdb-3.1.so = /lib/libdb-3.1.so (0x40157000)
/lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x4000)
./tst-libc6
Name: tcp, Number: 6
So it works and doesn't segfault. Compared to a machine that
works, I notice that the working one has a glibc 2.3.1 against
the glibc 2.2.5 that drives the failing one. I will try to upgrade
glibc, although it worked well for slightly older Apache+PHP
versions and I have to evaluate posible collateral effects on
other applications before upgrading glibc from 2.2 to 2.3...
On the working machine, test 2 shows different libraries:
-Test 2:
gcc tst-libc6.c -o tst-libc6 -ldb
ldd tst-libc6
libdb-3.3.so = /lib/libdb-3.3.so (0x40025000)
libc.so.6 = /lib/libc.so.6 (0x400af000)
/lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x4000)
./tst-libc6
Name: tcp, Number: 6
Here it includes libdb (as you may expect), while on the first case
Test2 just links against the same libraries as Test1 (both
working). Maybe some dependencies in php make libraries to
behave bogus and make that call to fail... I will try to upgrade
libraries, but if you know a better method to avoid failure
without changing them, will be of help (it is a production server, I
can test new versions of Apache and PHP in parallel with the
production daemons, but upgrading system libraries is a little
more dangerous and painful as it is 24/7 service...)
Thank you anyway for your time :-)
[2004-10-26 16:36:11] [EMAIL PROTECTED]
This looks suspiciously like a bad glibc installation:
#0 0x in ?? ()
#1 0x407f9cec in db_open () from /lib/libnss_db.so.2
I doubt there is a PHP or Apache bug here. Try a simple program
calling getprotobyname(tcp) to see if that segfaults; try it again
when linked against -ldb.
[2004-10-26 15:06:19] david at donpiso dot com
Yes, you're right. There is a Segmentation Violation:
(gdb) run -DSSL -e debug -k start -X
Starting program: /uxd/apache-server2/bin/httpd -DSSL -e
debug -k start -X
[Tue Oct 26 15:03:42 2004] [debug] mod_so.c(247): loaded
module include_module
[Tue Oct 26 15:03:42 2004] [debug] mod_so.c(247): loaded
module deflate_module
[Tue Oct 26 15:03:42 2004] [debug] mod_so.c(247): loaded
module log_config_module
[Tue Oct 26 15:03:42 2004] [debug] mod_so.c(247): loaded
module env_module
[Tue Oct 26 15:03:42 2004] [debug] mod_so.c(247): loaded
module ssl_module
[Tue Oct 26 15:03:42 2004] [debug] mod_so.c(247): loaded
module status_module
[Tue Oct 26 15:03:42 2004] [debug] mod_so.c(247): loaded
module info_module
[Tue Oct 26 15:03:43 2004] [debug] mod_so.c(247): loaded
module negotiation_module
[Tue Oct 26 15:03:43 2004] [debug] mod_so.c(247): loaded
module dir_module
[Tue Oct 26 15:03:43 2004] [debug] mod_so.c(247): loaded
module alias_module
[Tue Oct 26 15:03:43 2004] [debug] mod_so.c(247): loaded
module php4_module
Program received signal SIGSEGV, Segmentation fault.
0x in ?? ()
(gdb) bt
#0 0x in ?? ()
#1 0x407f9cec in db_open () from
#25570 [Csd]: Some requests cause Apache to crash/restart
ID: 25570 Updated by: [EMAIL PROTECTED] Reported By: robert at profundis dot se Status: Closed Bug Type: Apache2 related Operating System: WinXP SP1 PHP Version: 5CVS-2004-04-22 (dev) Assigned To: jorton New Comment: w.r.t. Win32 AcceptEx errors, see: http://httpd.apache.org/docs-2.0/faq/error.html#error.acceptex Previous Comments: [2004-10-26 13:58:43] suco at felisuco dot com Hello, Running: - Apache 2.0.52 PHP 4.3.9 CVS version as of noon 10/26/2004) win2003 server Hi I have the same problems, the errors has reduced dramaticly but the error is still there: [Tue Oct 26 13:28:44 2004] [warn] (OS 121)Ha terminado el intervalo de espera del semáforo. : winnt_accept: Asynchronous AcceptEx failed. [Tue Oct 26 13:29:49 2004] [warn] (OS 64)El nombre de red especificado ya no está disponible. : winnt_accept: Asynchronous AcceptEx failed. [Tue Oct 26 13:31:57 2004] [warn] (OS 64)El nombre de red especificado ya no está disponible. : winnt_accept: Asynchronous AcceptEx failed. [Tue Oct 26 13:37:53 2004] [warn] (OS 64)El nombre de red especificado ya no está disponible. : winnt_accept: Asynchronous AcceptEx failed. [Tue Oct 26 13:42:11 2004] [warn] (OS 64)El nombre de red especificado ya no está disponible. : winnt_accept: Asynchronous AcceptEx failed. [Tue Oct 26 13:43:03 2004] [warn] (OS 64)El nombre de red especificado ya no está disponible. : winnt_accept: Asynchronous AcceptEx failed. [Tue Oct 26 13:45:19 2004] [warn] (OS 64)El nombre de red especificado ya no está disponible. : winnt_accept: Asynchronous AcceptEx failed. [Tue Oct 26 13:45:26 2004] [warn] (OS 64)El nombre de red especificado ya no está disponible. : winnt_accept: Asynchronous AcceptEx failed. [2004-10-25 20:06:07] FaithPast at gmail dot com Hello, this is the second time i will try posting this here. Running: - Apache 2.0.52 mod_ssl 0.9.7d PHP 5.1.x (WITH CVS version as of noon 10/24/2004) win2k server So far it has reduced the issue dramaticly about how often the server returns a Page not found error. However this issue still is there. Once every X minutes Apache2 restarts herself and durring that 1 - 3 second gap while restarting any requests are returned with a PNF error. Now is this an Apache2 issue? or PHP? [2004-10-22 17:02:31] sintemaa at hotmail dot com Any idea when 4.3.10 will be released. Currently I'm a bit caught in a split. I'm running 4.3.6 and I need to upgrade to a new version, but when I upgrade to 4.3.9 I get these problems... :( [2004-10-21 21:44: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. Thanks for testing it out. The fix has been included in the 4.3 branch now too so it should be included in the next 4.3.x and 5.0.x releases. [2004-10-21 20:53:51] aaron at gwmicro dot com Sorry about the double post in 30405. With the latest 5.1.X CVS build (Oct 21, 2004 18:30 GMT), this problem has been resolved for me. Thank you. 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/25570 -- Edit this bug report at http://bugs.php.net/?id=25570edit=1
#30563 [Opn]: Apache doesn't start with PHP. No errors reported.
ID: 30563 Updated by: [EMAIL PROTECTED] Reported By: david at donpiso dot com Status: Open Bug Type: Apache2 related Operating System: Linux 2.4.25 PHP Version: 4.3.9 New Comment: Can you try with -X added to the flags passed to run in gdb, to try a single-process startup. Previous Comments: [2004-10-26 13:21:32] david at donpiso dot com Description: Apache simply fails to start after loading all modules, it seems it exits after loading, probably following initialization phase of the modules. No error neither at console nor log files. This happens since Apache 2.0.48 + PHP 4.3.4 in this machine, but I succeeded to start Apache 2.0.49 + PHP 4.3.6 in a different machine. Now tried Apache 2.0.52 + PHP 4.3.9 and still doesn't work. This is PHP configure: ./configure --with-apxs2=/usr/local/apache-server2/bin/apxs --enable-ctype --with-gd --enable-gd-native-ttf --with-jpeg-dir=/usr --with-png --with-gmp --with-pgsql --enable-shmop --enable-memory-limit --enable-shared --disable-debug --with-zlib=/usr --disable-cgi --disable-path-info-check --enable-safe-mode --with-openssl --with-bz2 --enable-calendar --enable-exif --enable-ftp --enable-sockets --without-mysql This are Apache modules: Server version: Apache/2.0.52 Server built: Oct 25 2004 18:59:00 Server's Module Magic Number: 20020903:9 Architecture: 32-bit Server compiled with -D APACHE_MPM_DIR=server/mpm/prefork -D APR_HAS_SENDFILE -D APR_HAS_MMAP -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled) -D APR_USE_SYSVSEM_SERIALIZE -D APR_USE_PTHREAD_SERIALIZE -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT -D APR_HAS_OTHER_CHILD -D AP_HAVE_RELIABLE_PIPED_LOGS -D HTTPD_ROOT=/usr/local/apache-server2 -D SUEXEC_BIN=/usr/local/apache-server2/bin/suexec -D DEFAULT_PIDLOG=logs/httpd.pid -D DEFAULT_SCOREBOARD=logs/apache_runtime_status -D DEFAULT_LOCKFILE=logs/accept.lock -D DEFAULT_ERRORLOG=logs/error_log -D AP_TYPES_CONFIG_FILE=conf/mime.types -D SERVER_CONFIG_FILE=conf/httpd.conf The php.ini changes: precision= 14 y2k_compliance = Off output_buffering = 4096 allow_call_time_pass_reference = Off safe_mode_gid = On highlight.* ;max_input_time = 60 memory_limit = 6M error_reporting = E_ALL display_errors = Off log_errors = On error_log = /(...)/apache2/logs/php.log variables_order = GPCS register_argc_argv = Off post_max_size = 4M magic_quotes_gpc = Off upload_tmp_dir = /(...)/tmp upload_max_filesize = 4M ;SMTP = localhost ;sendmail_from = [EMAIL PROTECTED] session.cache_expire = 60 session.use_trans_sid = 1 Actual result: -- Running gdb httpd gives: GNU gdb 5.2 (...) This GDB was configured as i386-slackware-linux... (gdb) run -DSSL -e debug -k start Starting program: /uxd/apache-server2/bin/httpd -DSSL -e debug -k start [Tue Oct 26 13:16:42 2004] [debug] mod_so.c(247): loaded module include_module [Tue Oct 26 13:16:42 2004] [debug] mod_so.c(247): loaded module deflate_module [Tue Oct 26 13:16:42 2004] [debug] mod_so.c(247): loaded module log_config_module [Tue Oct 26 13:16:42 2004] [debug] mod_so.c(247): loaded module env_module [Tue Oct 26 13:16:42 2004] [debug] mod_so.c(247): loaded module ssl_module [Tue Oct 26 13:16:42 2004] [debug] mod_so.c(247): loaded module status_module [Tue Oct 26 13:16:42 2004] [debug] mod_so.c(247): loaded module info_module [Tue Oct 26 13:16:42 2004] [debug] mod_so.c(247): loaded module negotiation_module [Tue Oct 26 13:16:42 2004] [debug] mod_so.c(247): loaded module dir_module [Tue Oct 26 13:16:42 2004] [debug] mod_so.c(247): loaded module alias_module [Tue Oct 26 13:16:43 2004] [debug] mod_so.c(247): loaded module php4_module Program exited normally. -- Edit this bug report at http://bugs.php.net/?id=30563edit=1
#30563 [Opn-Bgs]: Apache doesn't start with PHP. No errors reported.
ID: 30563 Updated by: [EMAIL PROTECTED] Reported By: david at donpiso dot com -Status: Open +Status: Bogus -Bug Type: Apache2 related +Bug Type: Reproducible crash Operating System: Linux 2.4.25 PHP Version: 4.3.9 New Comment: This looks suspiciously like a bad glibc installation: #0 0x in ?? () #1 0x407f9cec in db_open () from /lib/libnss_db.so.2 I doubt there is a PHP or Apache bug here. Try a simple program calling getprotobyname(tcp) to see if that segfaults; try it again when linked against -ldb. Previous Comments: [2004-10-26 15:06:19] david at donpiso dot com Yes, you're right. There is a Segmentation Violation: (gdb) run -DSSL -e debug -k start -X Starting program: /uxd/apache-server2/bin/httpd -DSSL -e debug -k start -X [Tue Oct 26 15:03:42 2004] [debug] mod_so.c(247): loaded module include_module [Tue Oct 26 15:03:42 2004] [debug] mod_so.c(247): loaded module deflate_module [Tue Oct 26 15:03:42 2004] [debug] mod_so.c(247): loaded module log_config_module [Tue Oct 26 15:03:42 2004] [debug] mod_so.c(247): loaded module env_module [Tue Oct 26 15:03:42 2004] [debug] mod_so.c(247): loaded module ssl_module [Tue Oct 26 15:03:42 2004] [debug] mod_so.c(247): loaded module status_module [Tue Oct 26 15:03:42 2004] [debug] mod_so.c(247): loaded module info_module [Tue Oct 26 15:03:43 2004] [debug] mod_so.c(247): loaded module negotiation_module [Tue Oct 26 15:03:43 2004] [debug] mod_so.c(247): loaded module dir_module [Tue Oct 26 15:03:43 2004] [debug] mod_so.c(247): loaded module alias_module [Tue Oct 26 15:03:43 2004] [debug] mod_so.c(247): loaded module php4_module Program received signal SIGSEGV, Segmentation fault. 0x in ?? () (gdb) bt #0 0x in ?? () #1 0x407f9cec in db_open () from /lib/libnss_db.so.2 #2 0x407f9dac in internal_setent () from /lib/libnss_db.so.2 #3 0x407f85dd in _nss_db_endprotoent () from /lib/libnss_db.so.2 #4 0x407f8887 in _nss_db_getprotobyname_r () from /lib/libnss_db.so.2 #5 0x403fd080 in getprotobyname_r () from /lib/libc.so.6 #6 0x403fcf31 in getprotobyname () from /lib/libc.so.6 #7 0x40551484 in zm_startup_sockets (type=1, module_number=4) at /uxd/temp/php-4.3.9/ext/sockets/sockets.c:461 #8 0x405f59b3 in zend_startup_module (module=0x406fa040) at /uxd/temp/php-4.3.9/Zend/zend_API.c:1005 #9 0x405c9294 in php_startup_extensions (ptr=0x40705908, count=19) at /uxd/temp/php-4.3.9/main/main.c:1044 #10 0x4060e54f in php_startup_internal_extensions () at main/internal_functions.c:81 #11 0x405c9845 in php_module_startup (sf=0x407055e0, additional_modules=0x407058c0, num_additional_modules=1) at /uxd/temp/php-4.3.9/main/main.c:1216 #12 0x4060c1e6 in php_apache2_startup (sapi_module=0x407055e0) at /uxd/temp/php-4.3.9/sapi/apache2handler/sapi_apache2.c:289 #13 0x4060c34d in php_apache_server_startup (pconf=0x80a5090, plog=0x80d9160, ptemp=0x80f7958, s=0x80a9198) at /uxd/temp/php-4.3.9/sapi/apache2handler/sapi_apache2.c:388 #14 0x0806eaa1 in ap_run_post_config (pconf=0x80a5090, plog=0x80d9160, ptemp=0x80f7958, s=0x80a9198) at config.c:87 #15 0x0807364c in main (argc=7, argv=0xb854) at main.c:606 #16 0x4033117d in __libc_start_main () from /lib/libc.so.6 [2004-10-26 14:47:25] [EMAIL PROTECTED] Can you try with -X added to the flags passed to run in gdb, to try a single-process startup. [2004-10-26 13:21:32] david at donpiso dot com Description: Apache simply fails to start after loading all modules, it seems it exits after loading, probably following initialization phase of the modules. No error neither at console nor log files. This happens since Apache 2.0.48 + PHP 4.3.4 in this machine, but I succeeded to start Apache 2.0.49 + PHP 4.3.6 in a different machine. Now tried Apache 2.0.52 + PHP 4.3.9 and still doesn't work. This is PHP configure: ./configure --with-apxs2=/usr/local/apache-server2/bin/apxs --enable-ctype --with-gd --enable-gd-native-ttf --with-jpeg-dir=/usr --with-png --with-gmp --with-pgsql --enable-shmop --enable-memory-limit --enable-shared --disable-debug --with-zlib=/usr --disable-cgi --disable-path-info-check --enable-safe-mode --with-openssl --with-bz2 --enable-calendar --enable-exif --enable-ftp --enable-sockets --without-mysql This are Apache modules: Server version: Apache/2.0.52 Server built: Oct 25 2004 18:59:00 Server's Module Magic Number: 20020903:9 Architecture: 32-bit Server compiled with -D APACHE_MPM_DIR=server/mpm/prefork -D APR_HAS_SENDFILE -D APR_HAS_MMAP -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled) -D APR_USE_SYSVSEM_SERIALIZE -D APR_USE_PTHREAD_SERIALIZE -D
#30340 [Opn-Bgs]: libphp4.so do not produce
ID: 30340 Updated by: [EMAIL PROTECTED] Reported By: orlowscy at hotpop dot com -Status: Open +Status: Bogus Bug Type: Compile Failure Operating System: RedHat 7.2 PHP Version: 4.3.9 New Comment: orlowscy at hotpop: this is a misconfiguration, you have entered: ./configure with-apxs2=/usr/local/apache2/bin/apxs ... rather than ./configure --with-apxs2=/usr/local/apache2/bin/apxs ... note the -- before the with-apxs2. Anyone else seeing this issue, check the configure output carefully for errors. Previous Comments: [2004-10-25 19:49:07] will_jetlabs at hotmail dot com Upgrading from 4.3.2, I had the same problem (I have compiled PHP many times with a similar procedure in the past and this is the first time it's done this to me). After piling through the generated files and config/ build outputs, noticed that config.sub was unhappy during the configure stage - my machine host type was not being added to the command like it is supposed to be. Adding the following at the end of my configure command: `/bin/sh config.guess` (this forces the approprate host to be given to config.sub) - presumably this propagates down to the part that deals with libtool so that it is aware that the system can cope with shared libraries. Check your configure output for any errors to do with config.sub (it came up quite early - possibly the first line output from ./configure) - if you have one, try appending your host type string (either use the output config.guess or just type it in if you know what it should be) and see if that helps. Why I now need to do this, I don't know, but apparently, it's not a bug ;-) William Adjei [2004-10-14 17:29:16] orlowscy at hotpop dot com [EMAIL PROTECTED] thank you for your interest in my problem. On http://diamond.cympak.com/php4/ you can see 3 files: configure-options configure-output libtool I downgraded apache to 2.0.44 *according to some helps on google apache 2.0.44 was supposed to work with PHP 4.3.x. [2004-10-13 23:03:25] [EMAIL PROTECTED] If the generated libtool script has build_libtool_libs=no PHP can't build shared libraries. I suggest you look at the configure output to see why libtool is refusing to support shared libraries, or upload it somewhere and I'll look. [2004-10-12 20:45:37] scymerman at comcast dot net Derick, What constitutes a bug to you? Just so you know where Im coming from, my definition of a bug is not an issue with software that has not been corrected nor has a solution to get around it. I dont know if for some weird reason you are not supporting older RH Versions or what. Im also having the same exact problem and do not know where to go from here. From reading what Slawomir has posted, it seems like this is also an issue with older versions of php. Im just looking for some clarification on where I should go in regards to the say issue. Thanks. -Scott [2004-10-12 15:31:36] orlowscy at hotpop dot com I have downgraded PHP to 4.3.0 configured apache 2.0.44 : ./configure --prefix=/usr/local/apache2 \ --enable-so configured older php 4.3.0: ./configure \ --with-apxs2=/usr/local/apache2/bin/apxs \ --with-mysql=/usr/local/mysql \ --prefix=/usr/local/apache2/php \ --with-config-file-path=/usr/local/apache2/php unfortunately libphp4.so still was not created but this time libphp4.a was created even directive --with-apxs2 was used to create DSO library. It does not make sense - to compile static library I have to have compiled apache - (apxs from apache was used). To use static library apache would have to be compiled. So it is vicious circle. Maybe even older PHP 4.2 would produce libphp4.so - do anybody have any suggestions 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/30340 -- Edit this bug report at http://bugs.php.net/?id=30340edit=1
#25570 [Opn-Fbk]: Error with file upload
ID: 25570 Updated by: [EMAIL PROTECTED] -Summary: Interpreter crashes reproducibly (2) Reported By: robert at profundis dot se -Status: Open +Status: Feedback Bug Type: Apache2 related -Operating System: WinXP SP1 +Operating System: SLES 8.0 zSeries s390 IBM -PHP Version: 5CVS-2004-04-22 (dev) +PHP Version: 4.3.9RC3 -Assigned To: +Assigned To: jorton New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip I've committed a possible fix for this to 5.0 and 5.1, please apply: http://cvs.apache.org/~jorton/php_abort.diff or wait for a 5.0-dev or 5.1-dev snapshot to show up with this applied. Previous Comments: [2004-10-20 10:47:31] [EMAIL PROTECTED] Ah, good call. The interesting exit(-1) call is in Zend: _zend_bailout to be specific. And in fact zend_bailout is called from php_handle_aborted_connection, which can be called outside the zend_first_try/zend_end_try block in the 2.0 SAPI, so that looks like the bug. [2004-10-17 18:55:56] mwhitlock at whitsoftdev dot com Unsigned 4294967295 is the same as -1 in 32-bit two's complement signed math. It looks to me as if we're not encountering a segfault (since that would generate a different message in httpd.log) but rather an error trap somewhere that is calling exit(-1). Calling exit(..) from a dynamic link library kills the host process, which in this case would be the Apache child process. Seems like the solution is just finding where PHP is calling exit(-1) and changing it to somehow more gracefully aborting the request rather than forcefully exiting the process. Exiting the process wouldn't be a problem for the CLI since a separate process is created to handle every request, but as an Apache module, exit(..) is simply wrong. [2004-10-15 14:42:37] jonathan at schwarzelan dot de Sorry guys - got to correct the above said... With outputting results in the 4294967295 Crash - without it results to 3221225477 Apache crash shame on me... [2004-10-15 14:40:29] jonathan at schwarzelan dot de Some extra Information on the Bug (sorry no traces-) Not only outputting stuff leads to this error - Just having a loop of 140 doing querys on mysql and without saving data from those querys filling an array like $arr[$i][0]= crashes Apache with said logfile occurence - Found with Win2k, Php 5.1.0-dev and 2.0.50 Apache and XPSP1, Php 5.0.2 release and 2.0.50 Apache [2004-10-14 20:34:48] robert at profundis dot se Can you get a backtrace of the crash? Eek, not easily. This is Windows :( Not saying one can't make a backtrace on Windows, but I'm not sure how to go about doing it. Last time around I had a test machine to tinker with, not so this time. My guess is that it is a thread issue, since it occurs when two requests (threads) are inside the handler, and one of them is aborted (according to my investigations last time). I'm not too familiar with the code, but maybe some overlooked global related to aborted connections? I can also add that I can't say for sure it ever was fixed. I don't remember if the version I've been running was the one I modified myself or a cvs snapshot. 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/25570 -- Edit this bug report at http://bugs.php.net/?id=25570edit=1
#30405 [Opn-Bgs]: Error with file upload
ID: 30405
Updated by: [EMAIL PROTECTED]
-Summary: Parent: child process exited with status 4294967295 --
Restarting.
Reported By: joel at preacherboy dot net
-Status: Open
+Status: Bogus
Bug Type: Apache2 related
-Operating System: Windows 2003
+Operating System: SLES 8.0 zSeries s390 IBM
-PHP Version: 5.0.2
+PHP Version: 4.3.9RC3
-Assigned To:
+Assigned To: jorton
New Comment:
Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same.
Thank you for your interest in PHP.
This looks like a duplicate of bug 25570, please try the patch
referenced there.
Previous Comments:
[2004-10-20 21:15:32] aaron at gwmicro dot com
I can consistenly reproduce this problem.
[Wed Oct 20 14:08:43 2004] [notice] Parent: child process exited with
status 4294967295 -- Restarting.
Here's how we're duplicating it under Windows Server 2003, running
Apache/2.0.52 (Win32) DAV/2 mod_ssl/2.0.52 OpenSSL/0.9.7d
PHP/5.1.0-dev:
?
$filename = c:\\demo\\demo.exe;
$fileInfo = stat($filename);
$length = $fileInfo[7];
header(Content-Length: $length);
header(Content-Type:application/octet-stream);
header(Cache-Control: no-cache, must-revalidate);
header(Connection: close);
header(Content-Length: $length);
header(Content-Type:application/octet-stream);
header(Content-Disposition: inline; filename=demo.exe);
header(Pragma: no-cache);
$fh = fopen($filename, rb);
while (!feof($fh))
{
$buffer = fread($fh, 1024);
print $buffer;
}
fclose($fh);
header(Connection: close);
?
The demo file is about 35MB, and if you cancel the download half-way
through, you'll consistently get this error in the apache log, and the
child restarting process will happen. The line right before the restart
is:
[Wed Oct 20 14:08:42 2004] [info] (OS 10054)An existing connection was
forcibly closed by the remote host. : core_output_filter: writing data
to the network
I can duplicate this problem 100% of the time.
[2004-10-12 23:24:44] joel at preacherboy dot net
Here's what you'll see in the \log\error_log for Apache2:
[Mon Oct 11 09:35:20 2004] [notice] Parent: child process exited with
status 4294967295 -- Restarting.
[Mon Oct 11 09:35:22 2004] [notice] Parent: Created child process 4004
[Mon Oct 11 09:35:22 2004] [notice] Disabled use of AcceptEx() WinSock2
API
[Mon Oct 11 09:35:23 2004] [notice] Child 4004: Child process is
running
[Mon Oct 11 09:35:23 2004] [notice] Child 4004: Acquired the start
mutex.
[Mon Oct 11 09:35:23 2004] [notice] Child 4004: Starting 250 worker
threads.
[Mon Oct 11 09:35:23 2004] [notice] Child 4004: Listening on port 443.
[Mon Oct 11 09:35:23 2004] [notice] Child 4004: Listening on port 80.
[Mon Oct 11 09:35:23 2004] [notice] Child 4004: Listening on port 80.
After some more time, the above will loop. I see 2 other people have
voted that they are able to reproduce the issue. Is there anything
else you need to regress the bug?
[2004-10-12 16:26:44] joel at preacherboy dot net
I can't think what else I would need to do in explaining how to regress
this bug. It happens quite easily. Have you even tried my suggestions?
Do you need something else like my httpd.conf to get started? This bug
seems identical to what was mentioned in bug #25570.
[2004-10-12 09:07:39] [EMAIL PROTECTED]
I don't know what details I want, it's that Windows is simply
impossible to debug. You'll have to come up with some really good
pointers, otherwise we can just as well delete this bugreport.
[2004-10-12 08:41:40] joel at preacherboy dot net
You're going to have to ask what details you're looking for. I've
already read that page. There aren't any specific steps to get this
error to occur and existing information is available in the links I
provided,but I'll do my best to make this a step-by-step process
1. Install Apache 2.0.52 / PHP 5.0.2 on Windows 2003.
2. Create a website of pages linking each other.
3. View these pages, clicking through links like crazy, using another
system.
After a few clicks, Apache2 will restart itself.
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/30405
--
Edit this bug report at http://bugs.php.net/?id=30405edit=1
#25570 [Fbk]: Some requests cause Apache to crash/restart
ID: 25570 Updated by: [EMAIL PROTECTED] -Summary: Error with file upload Reported By: robert at profundis dot se Status: Feedback Bug Type: Apache2 related -Operating System: SLES 8.0 zSeries s390 IBM +Operating System: WinXP SP1 -PHP Version: 4.3.9RC3 +PHP Version: 5CVS-2004-04-22 (dev) Assigned To: jorton New Comment: Fixing Version/OS/Summary... Previous Comments: [2004-10-21 10:28:17] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip I've committed a possible fix for this to 5.0 and 5.1, please apply: http://cvs.apache.org/~jorton/php_abort.diff or wait for a 5.0-dev or 5.1-dev snapshot to show up with this applied. [2004-10-20 10:47:31] [EMAIL PROTECTED] Ah, good call. The interesting exit(-1) call is in Zend: _zend_bailout to be specific. And in fact zend_bailout is called from php_handle_aborted_connection, which can be called outside the zend_first_try/zend_end_try block in the 2.0 SAPI, so that looks like the bug. [2004-10-17 18:55:56] mwhitlock at whitsoftdev dot com Unsigned 4294967295 is the same as -1 in 32-bit two's complement signed math. It looks to me as if we're not encountering a segfault (since that would generate a different message in httpd.log) but rather an error trap somewhere that is calling exit(-1). Calling exit(..) from a dynamic link library kills the host process, which in this case would be the Apache child process. Seems like the solution is just finding where PHP is calling exit(-1) and changing it to somehow more gracefully aborting the request rather than forcefully exiting the process. Exiting the process wouldn't be a problem for the CLI since a separate process is created to handle every request, but as an Apache module, exit(..) is simply wrong. [2004-10-15 14:42:37] jonathan at schwarzelan dot de Sorry guys - got to correct the above said... With outputting results in the 4294967295 Crash - without it results to 3221225477 Apache crash shame on me... [2004-10-15 14:40:29] jonathan at schwarzelan dot de Some extra Information on the Bug (sorry no traces-) Not only outputting stuff leads to this error - Just having a loop of 140 doing querys on mysql and without saving data from those querys filling an array like $arr[$i][0]= crashes Apache with said logfile occurence - Found with Win2k, Php 5.1.0-dev and 2.0.50 Apache and XPSP1, Php 5.0.2 release and 2.0.50 Apache 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/25570 -- Edit this bug report at http://bugs.php.net/?id=25570edit=1
#30405 [Bgs]: Parent: child process exited with status 4294967295 -- Restarting
ID: 30405
Updated by: [EMAIL PROTECTED]
-Summary: Error with file upload
Reported By: joel at preacherboy dot net
Status: Bogus
Bug Type: Apache2 related
-Operating System: SLES 8.0 zSeries s390 IBM
+Operating System: Windows 2003
-PHP Version: 4.3.9RC3
+PHP Version: 5.0.2
Assigned To: jorton
New Comment:
Fixing OS/Version/Summary here too.
Previous Comments:
[2004-10-21 10:29:26] [EMAIL PROTECTED]
Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same.
Thank you for your interest in PHP.
This looks like a duplicate of bug 25570, please try the patch
referenced there.
[2004-10-20 21:15:32] aaron at gwmicro dot com
I can consistenly reproduce this problem.
[Wed Oct 20 14:08:43 2004] [notice] Parent: child process exited with
status 4294967295 -- Restarting.
Here's how we're duplicating it under Windows Server 2003, running
Apache/2.0.52 (Win32) DAV/2 mod_ssl/2.0.52 OpenSSL/0.9.7d
PHP/5.1.0-dev:
?
$filename = c:\\demo\\demo.exe;
$fileInfo = stat($filename);
$length = $fileInfo[7];
header(Content-Length: $length);
header(Content-Type:application/octet-stream);
header(Cache-Control: no-cache, must-revalidate);
header(Connection: close);
header(Content-Length: $length);
header(Content-Type:application/octet-stream);
header(Content-Disposition: inline; filename=demo.exe);
header(Pragma: no-cache);
$fh = fopen($filename, rb);
while (!feof($fh))
{
$buffer = fread($fh, 1024);
print $buffer;
}
fclose($fh);
header(Connection: close);
?
The demo file is about 35MB, and if you cancel the download half-way
through, you'll consistently get this error in the apache log, and the
child restarting process will happen. The line right before the restart
is:
[Wed Oct 20 14:08:42 2004] [info] (OS 10054)An existing connection was
forcibly closed by the remote host. : core_output_filter: writing data
to the network
I can duplicate this problem 100% of the time.
[2004-10-12 23:24:44] joel at preacherboy dot net
Here's what you'll see in the \log\error_log for Apache2:
[Mon Oct 11 09:35:20 2004] [notice] Parent: child process exited with
status 4294967295 -- Restarting.
[Mon Oct 11 09:35:22 2004] [notice] Parent: Created child process 4004
[Mon Oct 11 09:35:22 2004] [notice] Disabled use of AcceptEx() WinSock2
API
[Mon Oct 11 09:35:23 2004] [notice] Child 4004: Child process is
running
[Mon Oct 11 09:35:23 2004] [notice] Child 4004: Acquired the start
mutex.
[Mon Oct 11 09:35:23 2004] [notice] Child 4004: Starting 250 worker
threads.
[Mon Oct 11 09:35:23 2004] [notice] Child 4004: Listening on port 443.
[Mon Oct 11 09:35:23 2004] [notice] Child 4004: Listening on port 80.
[Mon Oct 11 09:35:23 2004] [notice] Child 4004: Listening on port 80.
After some more time, the above will loop. I see 2 other people have
voted that they are able to reproduce the issue. Is there anything
else you need to regress the bug?
[2004-10-12 16:26:44] joel at preacherboy dot net
I can't think what else I would need to do in explaining how to regress
this bug. It happens quite easily. Have you even tried my suggestions?
Do you need something else like my httpd.conf to get started? This bug
seems identical to what was mentioned in bug #25570.
[2004-10-12 09:07:39] [EMAIL PROTECTED]
I don't know what details I want, it's that Windows is simply
impossible to debug. You'll have to come up with some really good
pointers, otherwise we can just as well delete this bugreport.
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/30405
--
Edit this bug report at http://bugs.php.net/?id=30405edit=1
#25570 [Opn-Fbk]: Some requests cause Apache to crash/restart
ID: 25570 Updated by: [EMAIL PROTECTED] Reported By: robert at profundis dot se -Status: Open +Status: Feedback Bug Type: Apache2 related Operating System: WinXP SP1 PHP Version: 5CVS-2004-04-22 (dev) Assigned To: jorton New Comment: If you test the patch (it should apply to 4.3.x just the same) and tell me it works, yes! Previous Comments: [2004-10-21 11:00:05] robert at profundis dot se Will the fix be applied to 4.x.x as well? I'm not really ready for the leap to v5 for production just yet. [2004-10-21 10:48:20] [EMAIL PROTECTED] Fixing Version/OS/Summary... [2004-10-21 10:28:17] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip I've committed a possible fix for this to 5.0 and 5.1, please apply: http://cvs.apache.org/~jorton/php_abort.diff or wait for a 5.0-dev or 5.1-dev snapshot to show up with this applied. [2004-10-20 10:47:31] [EMAIL PROTECTED] Ah, good call. The interesting exit(-1) call is in Zend: _zend_bailout to be specific. And in fact zend_bailout is called from php_handle_aborted_connection, which can be called outside the zend_first_try/zend_end_try block in the 2.0 SAPI, so that looks like the bug. [2004-10-17 18:55:56] mwhitlock at whitsoftdev dot com Unsigned 4294967295 is the same as -1 in 32-bit two's complement signed math. It looks to me as if we're not encountering a segfault (since that would generate a different message in httpd.log) but rather an error trap somewhere that is calling exit(-1). Calling exit(..) from a dynamic link library kills the host process, which in this case would be the Apache child process. Seems like the solution is just finding where PHP is calling exit(-1) and changing it to somehow more gracefully aborting the request rather than forcefully exiting the process. Exiting the process wouldn't be a problem for the CLI since a separate process is created to handle every request, but as an Apache module, exit(..) is simply wrong. 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/25570 -- Edit this bug report at http://bugs.php.net/?id=25570edit=1
#29681 [Opn-Fbk]: Parent: child process exited with status 3221225477
ID: 29681 Updated by: [EMAIL PROTECTED] Reported By: tony at marston-home dot demon dot co dot uk -Status: Open +Status: Feedback Bug Type: Apache2 related Operating System: WindowsXP PHP Version: 5.0.1 New Comment: 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. There is nothing at that URL any more, please include a minimal reproduction script. Previous Comments: [2004-10-11 19:07:26] joel at preacherboy dot net I'm seeing this occur with Apache 2.0.52, PHP 5.0.2, and Windows 2003. I'm not doing anything particularly special in the PHP. Most of the hosted files are 100% HTML going through PHP. [2004-08-14 18:36:27] tony at marston-home dot demon dot co dot uk Description: I am using the Windows binaries for 5.0.1 with MySQL 4.1.3b and Apache 2.0.50 as my development PC. I have a script which runs OK the first time, but if I repeat it straight away it causes Apache to crash and restart. I have stepped through with debug and found the place where it crashes (it is always the same place) but all it is doing is accessing the properties within an object, properties which I have set in a previous call to the same object. I found it impossible to reproduce the bug in 20 lines of code, but what I have done is to isolate the single script and its included modules and gradually removed code until the error disappeared. I have put this code into a zip file for convenience. You can download this zip file at http://www.tonymarston.co.uk/error.zip Reproduce code: --- http://www.tonymarston.co.uk/error.zip -- Edit this bug report at http://bugs.php.net/?id=29681edit=1
#25570 [Fbk-Csd]: Some requests cause Apache to crash/restart
ID: 25570 Updated by: [EMAIL PROTECTED] Reported By: robert at profundis dot se -Status: Feedback +Status: Closed Bug Type: Apache2 related Operating System: WinXP SP1 PHP Version: 5CVS-2004-04-22 (dev) Assigned To: jorton New Comment: 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. Thanks for testing it out. The fix has been included in the 4.3 branch now too so it should be included in the next 4.3.x and 5.0.x releases. Previous Comments: [2004-10-21 20:53:51] aaron at gwmicro dot com Sorry about the double post in 30405. With the latest 5.1.X CVS build (Oct 21, 2004 18:30 GMT), this problem has been resolved for me. Thank you. [2004-10-21 16:35:24] joel at preacherboy dot net So what version of 5.x will have this fix? The latest public release is 5.0.2, which is affected by this problem. [2004-10-21 11:31:50] [EMAIL PROTECTED] If you test the patch (it should apply to 4.3.x just the same) and tell me it works, yes! [2004-10-21 11:00:05] robert at profundis dot se Will the fix be applied to 4.x.x as well? I'm not really ready for the leap to v5 for production just yet. [2004-10-21 10:48:20] [EMAIL PROTECTED] Fixing Version/OS/Summary... 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/25570 -- Edit this bug report at http://bugs.php.net/?id=25570edit=1
#29690 [Opn-Bgs]: pathinfo() reports wrong directory name
ID: 29690 Updated by: [EMAIL PROTECTED] Reported By: ressourceweb at hotmail dot com -Status: Open +Status: Bogus Bug Type: Apache2 related Operating System: Windows XP Home Edition PHP Version: 5.0.0 New Comment: This is not a PHP issue, see: http://issues.apache.org/bugzilla/show_bug.cgi?id=10775 Previous Comments: [2004-08-16 17:09:05] ressourceweb at hotmail dot com First of all, my bug report example should have been ?php $pathdata=pathinfo($SCRIPT_NAME); echo $pathdata[dirname]; ? instead of ?php $pathdata=pathinfo($SCRIPT_FILENAME); echo $pathdata[dirname]; ? also, i noticed that the pathinfo() function behaves correctly. it is the variable SCRIPT_NAME that contains wrong information [2004-08-15 22:54:23] ressourceweb at hotmail dot com Description: Steps to reproduce the problem : - Apache HTTPd Server 2.0.50 - PHP 5.0.0 - MultiViews ENABLED Trying to use the pathinfo($SCRIPT_FILENAME); command on a script called using double slashes in the URL (like http://localhost/php/test/pathinfo/argument/http//url) will return wrong directory information Reproduce code: --- ?php /* * File name : pathinfo.php * Directory : /php/test/ * Script filename : /php/test/pathinfo.php * Called in browser the following way : * http://localhost/php/test/pathinfo/argument/http//url */ $pathdata=pathinfo($SCRIPT_FILENAME); echo $pathdata[dirname]; ? Expected result: /php/test/ Actual result: -- /php/test/argument/http// -- Edit this bug report at http://bugs.php.net/?id=29690edit=1
#30515 [Opn-WFx]: unstandard mod_version/program_version signature in the apache modules
ID: 30515 Updated by: [EMAIL PROTECTED] Reported By: mancini at users dot sourceforge dot net -Status: Open +Status: Wont fix Bug Type: Apache2 related Operating System: win2000 PHP Version: Irrelevant New Comment: But there is no separate mod_phpN project, there is just PHP. It's useful to know both what version of mod_perl and what version of Perl is being used, hence the two version components. But you're not going to be using mod_php/4.3.9 PHP/5.0.2 exactly :) So, - wontfix is appropriate for this. Previous Comments: [2004-10-21 18:16:58] mancini at users dot sourceforge dot net Description: all the apache php modules have allways printed only the program version as it's signature under the http server the standard for all apache modules that are part of another software is the folowing format : mod_[name]/[modversion](space)[programname]/[programversion] the format php uses is only : [programname]/[programversion] for example the version 5.0.2 modules should show : mod_php5/5.0.2 PHP/5.0.2 but it shows only PHP/5.0.2 i take it that the version of the mod is the same as the one of the php release but that is not a reason for not compying for this facto standard and here are some examples : mod_perl/1.99_13-dev Perl/v5.8.3 mod_python/3.1.3 Python/2.3.2 mod_ssl/2.0.52 OpenSSL/0.9.7d Reproduce code: --- only the files mod_php5.c (line 902) and config.w32 (line 19) would need changing -- Edit this bug report at http://bugs.php.net/?id=30515edit=1
#29603 [Opn-Fbk]: Apache crash when trying to include non-existant files
ID: 29603 Updated by: [EMAIL PROTECTED] Reported By: ressourceweb at hotmail dot com -Status: Open +Status: Feedback Bug Type: Apache2 related Operating System: Windows XP Home Edition PHP Version: 5.0.0 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.0-win32-latest.zip Please try 5.0.2 or a release snapshot, I can't reproduce this here (5.0.2 with the apache2handler on 2.0.52 on Linux, anyway). Previous Comments: [2004-08-10 17:55:04] ressourceweb at hotmail dot com Description: Every time I tried to include into a PHP script, by accident, a file that didn't exist, Apache crashed and displayed a dialog box saying «Apache2 caused an unhandled exception error. Do you wish to debug?» instead of logging the error in the PHP error log. This error did not happen when I tried to include a file that existed. I tried to correct the problem by disabling, one by one, my php extensions and I discovered that php_pspell.dll was causing the repeated crashes. I am using PHP 5.0.0 with Apache Web Server 2.0.50 on Windows XP Home Edition, Service Pack 1. Extensions used by PHP php_bz2.dll, php_cpdf.dll, php_curl.dll, php_dba.dll, php_dbx.dll, php_fdf.dll, php_gd2.dll, php_gettext.dll, php_imap.dll, php_ldap.dll, php_mbstring.dll, php_mcrypt.dll, php_mhash.dll, php_ming.dll, php_mysql.dll, php_pdf.dll, php_snmp.dll, php_sockets.dll, php_tidy.dll, php_xmlrpc.dll, php_xsl.dll, php_zip.dll, php_perl.dll, php_xmlreader.dll, php_pspell.dll, php_lzf.dll, php_mailparse.dll Reproduce code: --- ?php include(nonexistent.inc.php); ? Expected result: PHP Warning : Cannot include file nonexistent.inc.php (or something similar) Actual result: -- «Apache2 caused an unhandled exception error. Do you wish to debug?» -- Edit this bug report at http://bugs.php.net/?id=29603edit=1
#25570 [Opn]: Some requests cause Apache to crash/restart
ID: 25570 Updated by: [EMAIL PROTECTED] Reported By: robert at profundis dot se Status: Open Bug Type: Apache2 related Operating System: Windows XP Professional SP1 PHP Version: 4.3.8 New Comment: Ah, good call. The interesting exit(-1) call is in Zend: _zend_bailout to be specific. And in fact zend_bailout is called from php_handle_aborted_connection, which can be called outside the zend_first_try/zend_end_try block in the 2.0 SAPI, so that looks like the bug. Previous Comments: [2004-10-17 18:55:56] mwhitlock at whitsoftdev dot com Unsigned 4294967295 is the same as -1 in 32-bit two's complement signed math. It looks to me as if we're not encountering a segfault (since that would generate a different message in httpd.log) but rather an error trap somewhere that is calling exit(-1). Calling exit(..) from a dynamic link library kills the host process, which in this case would be the Apache child process. Seems like the solution is just finding where PHP is calling exit(-1) and changing it to somehow more gracefully aborting the request rather than forcefully exiting the process. Exiting the process wouldn't be a problem for the CLI since a separate process is created to handle every request, but as an Apache module, exit(..) is simply wrong. [2004-10-15 14:42:37] jonathan at schwarzelan dot de Sorry guys - got to correct the above said... With outputting results in the 4294967295 Crash - without it results to 3221225477 Apache crash shame on me... [2004-10-15 14:40:29] jonathan at schwarzelan dot de Some extra Information on the Bug (sorry no traces-) Not only outputting stuff leads to this error - Just having a loop of 140 doing querys on mysql and without saving data from those querys filling an array like $arr[$i][0]= crashes Apache with said logfile occurence - Found with Win2k, Php 5.1.0-dev and 2.0.50 Apache and XPSP1, Php 5.0.2 release and 2.0.50 Apache [2004-10-14 20:34:48] robert at profundis dot se Can you get a backtrace of the crash? Eek, not easily. This is Windows :( Not saying one can't make a backtrace on Windows, but I'm not sure how to go about doing it. Last time around I had a test machine to tinker with, not so this time. My guess is that it is a thread issue, since it occurs when two requests (threads) are inside the handler, and one of them is aborted (according to my investigations last time). I'm not too familiar with the code, but maybe some overlooked global related to aborted connections? I can also add that I can't say for sure it ever was fixed. I don't remember if the version I've been running was the one I modified myself or a cvs snapshot. [2004-10-14 18:38:13] [EMAIL PROTECTED] Can you get a backtrace of the crash? 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/25570 -- Edit this bug report at http://bugs.php.net/?id=25570edit=1
#25570 [Opn]: Some requests cause Apache to crash/restart
ID: 25570 Updated by: [EMAIL PROTECTED] Reported By: robert at profundis dot se Status: Open Bug Type: Apache2 related Operating System: Windows XP Professional SP1 PHP Version: 4.3.8 New Comment: Can you get a backtrace of the crash? Previous Comments: [2004-10-14 17:20:44] robert at profundis dot se The only change in the code that seems to be related at a first glance is in rev 1.1.2.32: http://cvs.php.net/diff.php/php-src/sapi/apache2handler/sapi_apache2.c?r1=1.1.2.31r2=1.1.2.32ty=u The original problem seems to be triggered when calling php_handle_aborted_connection() on some occasions. The above revision change the condition when this function is called. I have not tested the versions inbetween 4.3.4-dev and 4.3.8, so I cannot confirm that this particular revision is the cause. (I also changed this bug's version number) [2004-10-14 17:09:09] robert at profundis dot se I change this to Open again. As Christopher said, this bug seems to have resurfaced. I checked back in my error log, and I see this same error started happening again the 3rd of september. Checking my notes, I upgraded this server to PHP 4.3.8 a few days earlier. The previous version was 4.3.4-dev (I had been lazy). [2004-10-14 16:52:55] christopher_theunissen at hotmail dot com This bug is definitely not fixed or has resurfaced, as I have the same problem in Windows 2000 with Apache 2.0.52 (51, 40, 49, 48) and the following PHP versions: 5.0.2 5.0.1 4.3.9 4.3.8 4.3.4 4.3.3 The server restarts with status 4294967295 every few hours. It has been running fine for 24 hours so far with PHP 4.3.2. [2003-09-18 20:43:21] [EMAIL PROTECTED] This bug has been fixed in CVS. In case this was a PHP problem, 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/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. [2003-09-18 08:54:13] robert at profundis dot se By changing three lines in sapi/apache2handler/sapi_apache2.c, back to how they were in rev. 1.1.2.17, it would not crash anymore on overlapping requests. Ie: // in 1.1.2.18 if (ap_pass_brigade(r-output_filters, brigade) != APR_SUCCESS || r-connection-aborted) // in 1.1.2.17 if (ap_pass_brigade(r-output_filters, brigade) != APR_SUCCESS) I cannot really guess what implications that change has, but I assume the extra expression had a purpose. However, with this change I cannot generate a crash anymore. 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/25570 -- Edit this bug report at http://bugs.php.net/?id=25570edit=1
#30128 [Opn]: segmentation fault in the child class catch
ID: 30128
Updated by: [EMAIL PROTECTED]
Reported By: dankab at infinito dot it
Status: Open
-Bug Type: Apache2 related
+Bug Type: Zend Engine 2 problem
Operating System: linux
PHP Version: 5.0.1
New Comment:
Not Apache-specific. Here's the backtrace into Zend from the cli:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 182931956288 (LWP 3400)]
zend_std_read_property (object=0x8db218, member=0x8e5680,
type=9213224)
at /local/jorton/php/HEAD64/Zend/zend_object_handlers.c:222
222 use_get = (zobj-ce-__get !zobj-in_get);
(gdb) where
#0 zend_std_read_property (object=0x8db218, member=0x8e5680,
type=9213224)
at /local/jorton/php/HEAD64/Zend/zend_object_handlers.c:222
#1 0x005cae4e in execute (op_array=0x7fbfff56d8) at
zend_vm_handlers.h:1469
#2 0x005d49ea in execute (op_array=0x7ac168) at
zend_vm_handlers.h:2242
#3 0x00589db4 in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at /local/jorton/php/HEAD64/Zend/zend.c:1053
#4 0x0055762f in php_execute_script
(primary_file=0x7fbfffb630)
at /local/jorton/php/HEAD64/main/main.c:1635
#5 0x005f104d in main (argc=3, argv=0x7fbfffb798)
at /local/jorton/php/HEAD64/sapi/cli/php_cli.c:943
(gdb) backtrace full
#0 zend_std_read_property (object=0x8db218, member=0x8e5680,
type=9213224)
at /local/jorton/php/HEAD64/Zend/zend_object_handlers.c:222
zobj = (zend_object *) 0x
tmp_member = {value = {lval = 1, dval =
4.9406564584124654e-324, str = {
val = 0x1 Address 0x1 out of bounds, len = 2}, ht = 0x1, obj =
{handle = 1,
handlers = 0x2}}, refcount = 0, type = 0 '\0', is_ref = 0 '\0'}
retval = (zval **) 0x58f2b7
rv = (zval *) 0x0
property_info = (zend_property_info *) 0x
silent = 0
use_get = 0 '\0'
#1 0x005cae4e in execute (op_array=0x7fbfff56d8) at
zend_vm_handlers.h:1469
tmp = {value = {lval = 548682035520, dval =
2.7108494424067858e-312, str = {
val = 0x7fbfff7140 \030#65533;\n\226*, len = 5723912}, ht =
0x7fbfff7140, obj = {
handle = 3221188928, handlers = 0x575708}}, refcount = 8044200,
type = 0 '\0',
is_ref = 0 '\0'}
execute_data = {opline = 0x8e5630, function_state =
{function_symbol_table = 0x8c7758,
function = 0x8e3da8, reserved = {0x2a962e6758, 0x8e3ed0,
0x2a962e66c0, 0x58}}, fbc = 0x0,
fbc_constructor = 0x8e0430, op_array = 0x8e3da8, object = 0x0, Ts =
0x7fbfff5660,
CVs = 0x7fbfff5650, original_in_execution = 1 '\001', calling_scope =
0x0,
symbol_table = 0x8c7688, prev_execute_data = 0x7fbfff8ff0}
binary_op = (int (*)(zval *, zval *, zval *)) 0
incdec_op = 0
prop_dim = 9328176
type = 0
#2 0x005d49ea in execute (op_array=0x7ac168) at
zend_vm_handlers.h:2242
calling_symbol_table = (HashTable *) 0x7ac168
execute_data = {opline = 0x8e0430, function_state =
{function_symbol_table = 0x8c7688,
function = 0x8e3da8, reserved = {0x56f660, 0x0, 0x2a962e66c0,
0x58}}, fbc = 0x8e3da8,
fbc_constructor = 0x8e3da8, op_array = 0x8dbd48, object = 0x8db218,
Ts = 0x7fbfff7300,
CVs = 0x7fbfff72f0, original_in_execution = 0 '\0', calling_scope =
0x8e3788,
symbol_table = 0x7ac168, prev_execute_data = 0x0}
binary_op = (int (*)(zval *, zval *, zval *)) 0
incdec_op = 0
prop_dim = 9307184
type = 0
#3 0x00589db4 in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at /local/jorton/php/HEAD64/Zend/zend.c:1053
files = {{gp_offset = 40, fp_offset = 48, overflow_arg_area =
0x7fbfff9280,
reg_save_area = 0x7fbfff9190}}
i = 1
file_handle = (zend_file_handle *) 0x7fbfffb630
orig_op_array = (zend_op_array *) 0x0
local_retval = (zval *) 0x0
#4 0x0055762f in php_execute_script
(primary_file=0x7fbfffb630)
at /local/jorton/php/HEAD64/main/main.c:1635
orig_bailout = {{__jmpbuf = {7993760, 0, 4469120, 0, 0, 0,
548682052688, 6228305},
__mask_was_saved = 0, __saved_mask = {__val = {0 repeats 16
times
orig_bailout_set = 1 '\001'
prepend_file_p = (zend_file_handle *) 0x0
append_file_p = (zend_file_handle *) 0x0
prepend_file = {type = 0 '\0', filename = 0x0, opened_path =
0x0, handle = {fd = 0,
fp = 0x0, stream = {handle = 0x0, reader = 0, closer = 0,
interactive = 0}},
free_filename = 0 '\0'}
append_file = {type = 0 '\0', filename = 0x0, opened_path =
0x0, handle = {fd = 0,
fp = 0x0, stream = {handle = 0x0, reader = 0, closer = 0,
interactive = 0}},
free_filename = 0 '\0'}
old_cwd = 0x7fbfff9288
old_primary_file_path = 0x7fbfffeaa4 ../bug30128.php
retval = 0
#5 0x005f104d in main (argc=3, argv=0x7fbfffb798)
at /local/jorton/php/HEAD64/sapi/cli/php_cli.c:943
orig_bailout = {{__jmpbuf = {0, 0, 0, 0, 0, 0, 0, 0
#30340 [Opn]: libphp4.so do not produce
ID: 30340 Updated by: [EMAIL PROTECTED] Reported By: orlowscy at hotpop dot com Status: Open -Bug Type: Apache2 related +Bug Type: Compile Failure Operating System: RedHat 7.2 PHP Version: 4.3.9 New Comment: If the generated libtool script has build_libtool_libs=no PHP can't build shared libraries. I suggest you look at the configure output to see why libtool is refusing to support shared libraries, or upload it somewhere and I'll look. Previous Comments: [2004-10-12 20:45:37] scymerman at comcast dot net Derick, What constitutes a bug to you? Just so you know where Im coming from, my definition of a bug is not an issue with software that has not been corrected nor has a solution to get around it. I dont know if for some weird reason you are not supporting older RH Versions or what. Im also having the same exact problem and do not know where to go from here. From reading what Slawomir has posted, it seems like this is also an issue with older versions of php. Im just looking for some clarification on where I should go in regards to the say issue. Thanks. -Scott [2004-10-12 15:31:36] orlowscy at hotpop dot com I have downgraded PHP to 4.3.0 configured apache 2.0.44 : ./configure --prefix=/usr/local/apache2 \ --enable-so configured older php 4.3.0: ./configure \ --with-apxs2=/usr/local/apache2/bin/apxs \ --with-mysql=/usr/local/mysql \ --prefix=/usr/local/apache2/php \ --with-config-file-path=/usr/local/apache2/php unfortunately libphp4.so still was not created but this time libphp4.a was created even directive --with-apxs2 was used to create DSO library. It does not make sense - to compile static library I have to have compiled apache - (apxs from apache was used). To use static library apache would have to be compiled. So it is vicious circle. Maybe even older PHP 4.2 would produce libphp4.so - do anybody have any suggestions [2004-10-09 15:42:33] [EMAIL PROTECTED] . [2004-10-08 18:00:17] orlowscy at hotpop dot com after runing configuration ./configure with-apx2=/usr/local/apache/bin/apxs ... libtool file is created and build_libtool_libs=no is set up. But even correcting it by hand (as suggested by some ) to build_libtool_libs=yes is not solving problem. libphp4.so would not produce under ../sapi/cli/.libs or any other place for that matter. [2004-10-07 15:10:32] [EMAIL PROTECTED] No bug, contact one of the mailinglists that are listed at http://php.net/support.php. 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/30340 -- Edit this bug report at http://bugs.php.net/?id=30340edit=1
#28110 [Opn]: Interpreter crashes reproducibly (2)
ID: 28110
Updated by: [EMAIL PROTECTED]
-Summary: Apache2 crashes reproducibly (2)
Reported By: cpuidle at gmx dot de
Status: Open
Bug Type: Reproducible crash
Operating System: WinXP SP1
PHP Version: 5CVS-2004-04-22 (dev)
New Comment:
This has nothing to do with Apache since it's a crash in Zend.
Previous Comments:
[2004-10-11 19:05:30] joel at preacherboy dot net
I'm seeing this occur with Apache 2.0.52, PHP 5.0.2, and Windows 2003.
I'm not doing anything particularly special in the PHP. Most of the
hosted files are 100% HTML going through PHP.
[2004-06-28 23:20:06] chris at leftbrained dot org
I, too, am getting that same error message in the apache error log, but
I can duplicate it differently.
Every call to bcmul(), I tried various values, and various values for
bcscale), where either of the arguments is 0 will produce this error.
$fStepX = '0.0075';
bcmul($fStepX,0);
The system:
PHP 5.0, RC3 (Module, Pre-compiled , downloaded from php.net[Hurricane
Electric mirror])
Windows 2000 Pro, SP4 [5.00.2195]
Apache 2.0.49 (Pre-compiled, downloaded from apache.org, No SSL)
Error message in Apache error log:
[Mon Jun 28 13:52:23 2004] [notice] Parent: child process exited with
status 3221225477 -- Restarting.
[Mon Jun 28 13:52:23 2004] [notice] Parent: Created child process 2000
I wasn't sure whether I should give this a new bug report, or tack it
on to one of the exisitings ones. I chose this one because it was the
only relevant open report I could find.
[2004-06-03 14:27:07] messju at lammfellpuschen dot de
event simpler code that reproduces this crash:
?php
function foo() {
$obj-plugins['function']['counter'][0]();
}
?
note: the function doesn't need to be called. it already
crashes during parsing.
with php-5.0.0RC3RC2 on linux i get:
(gdb) r
Starting
program: /mnt/debbie/home/messju/build/php-5.0.0RC3RC2/sapi/cli/php
/usr/local/httpd/messju/foo.php
[Thread debugging using libthread_db enabled]
[New Thread 1078702752 (LWP 14190)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1078702752 (LWP 14190)]
0x08207bb3 in zend_binary_strcasecmp (s1=0x0, len1=7,
s2=0x83ad53c __clone, len2=7)
at ctype.h:192
192 {
(gdb) bt
#0 0x08207bb3 in zend_binary_strcasecmp (s1=0x0, len1=7,
s2=0x83ad53c __clone, len2=7)
at ctype.h:192
#1 0x081f7b0f in zend_do_begin_method_call
(left_bracket=0xbfffc0bc)
at
/home/messju/debbie/build/php-5.0.0RC3RC2/Zend/zend_compile.c:1203
#2 0x081ed16b in zendparse () at
Zend/zend_language_parser.c:3229
#3 0x081ee671 in compile_file (file_handle=0x2, type=2)
at Zend/zend_language_scanner.c:3141
#4 0x0820a6bb in zend_execute_scripts (type=8,
retval=0x0, file_count=3)
at /home/messju/debbie/build/php-5.0.0RC3RC2/Zend/zend.c:1057
#5 0x081d049f in php_execute_script
(primary_file=0xb4d0)
at /home/messju/debbie/build/php-5.0.0RC3RC2/main/main.c:1627
#6 0x082350ae in main (argc=2, argv=0xb594)
at /home/messju/debbie/build/php-5.0.0RC3RC2/sapi/cli/php_cli.c:943
[2004-04-22 18:43:40] cpuidle at gmx dot de
Not sure the two are related, but I've also found bug 28108, please
cross-check.
[2004-04-22 18:42:44] cpuidle at gmx dot de
Description:
Apache crashes reporducibly with the following long file entry:
Parent: child process exited with status 3221225477 -- Restarting
Same thing happens with Apache 2.0.48 and PHP5RC1.
This happens without client firewall being installed.
Reproduce code:
---
The code to reproduce is part of the code that smarty generates from
one of my templates:
?php
echo $this-_plugins['function']['counter'][0](array('start' =
0,'print' = false,'name' = 'videocount'), $this) ;
?
Even if the code were wrong- it shouldn't crash apache, right?
Expected result:
no crash...
--
Edit this bug report at http://bugs.php.net/?id=28110edit=1
#30315 [Opn]: big integers don't overflow
ID: 30315 Updated by: [EMAIL PROTECTED] Reported By: tokul at users dot sourceforge dot net Status: Open Bug Type: Variables related Operating System: Linux PHP Version: 5.0.2 New Comment: PHP never guaranteed that integers larger than 2^31 wrap negative. It has never been true on a 64-bit platform, for example; there, your code will have always printed 3725722773. I don't think this is a PHP bug. Previous Comments: [2004-10-04 10:03:43] [EMAIL PROTECTED] You didn't mention that before ;-) So no, then this is ofcourse a bug. [2004-10-04 08:58:11] tokul at users dot sourceforge dot net Have you checked php behaviour in other php versions? I have also tested 4.1.2, 4.3.9 and 5.0.1. This happens only on 5.0.2. I just need to know, if this is a bug or default behaviour in future php versions. [2004-10-04 08:39:49] [EMAIL PROTECTED] 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. Thank you for your interest in PHP. . [2004-10-03 21:35:01] tokul at users dot sourceforge dot net Description: If big number (2500072158) is converted to integer, php 5.0.2 does not overflow and uses max integer value (2147483647). OS details: Linux Debian Sarge PHP compilation details (vanilla php-5.0.2.tar.bz2): ./configure --disable-debug --with-apxs=/somepath/apache/bin/apxs --prefix=/somepath/php --with-config-file-path=/somepath/ --with-pcre-regex --enable-mbstring --enable-session --disable-all --with-gettext=shared,/usr php.ini details: error_reporting=E_ALL display_errors=on register_globals=off asp_tags=on short_tags=off Is this standard future php behaviour or just some error in my config? Reproduce code: --- echo (int)0xde120495; Expected result: -569244523 Actual result: -- 2147483647 -- Edit this bug report at http://bugs.php.net/?id=30315edit=1
#30315 [Opn]: big integers don't overflow
ID: 30315 Updated by: [EMAIL PROTECTED] Reported By: tokul at users dot sourceforge dot net Status: Open Bug Type: Variables related Operating System: Linux PHP Version: 5.0.2 New Comment: I would argue that backwards compatibility is about making guarantees and not breaking them. It's not about simply ensuring that all behaviour remains exactly the same forever, otherwise you can't change anything at all. But no guarantee was broken in this change. Previous Comments: [2004-10-05 14:48:28] [EMAIL PROTECTED] But it's still breaking backward compatibility, and that is also important. IMO this should just work like it did before. [2004-10-05 14:43:30] [EMAIL PROTECTED] PHP never guaranteed that integers larger than 2^31 wrap negative. It has never been true on a 64-bit platform, for example; there, your code will have always printed 3725722773. I don't think this is a PHP bug. [2004-10-04 10:03:43] [EMAIL PROTECTED] You didn't mention that before ;-) So no, then this is ofcourse a bug. [2004-10-04 08:58:11] tokul at users dot sourceforge dot net Have you checked php behaviour in other php versions? I have also tested 4.1.2, 4.3.9 and 5.0.1. This happens only on 5.0.2. I just need to know, if this is a bug or default behaviour in future php versions. [2004-10-04 08:39:49] [EMAIL PROTECTED] 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. Thank you for your interest in PHP. . 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/30315 -- Edit this bug report at http://bugs.php.net/?id=30315edit=1
#30093 [Asn-Fbk]: Error with file upload
ID: 30093 Updated by: [EMAIL PROTECTED] Reported By: marcus dot stolzenberg at kgrz-kassel dot de -Status: Assigned +Status: Feedback Bug Type: HTTP related Operating System: SLES 8.0 zSeries s390 IBM PHP Version: 4.3.9RC3 Assigned To: jorton New Comment: Screwups in POST body handling can happen if you use the apache2filter SAPI and you have it configured badly. Things to try: 1) switch to apache2handler 2) remove any SetInputFilter PHP statements from your apache configuration, if you also have AddType application/x-httpd-php .php. The AddType is sufficient for the apache2filter to work correctly. If you have both, it screws up. 2.0.51 + 4.3.9 (apache2handler) work fine on an s390x box here. (running RHEL not SLES) Previous Comments: [2004-09-29 14:55:19] [EMAIL PROTECTED] Joe, do you have any idea about this? I'd say it's just an Apache problem... [2004-09-29 12:13:21] marcus dot stolzenberg at kgrz-kassel dot de Hi, I' m really sorry... but I was wrong! I did some test the last days with different php versions (4.3.6 - 4.3.9). I found out that the problem is not the php release. The problem is using Apache 2.0.50 together with any (4.3.6 - 4.3.9) PHP release. Using Apache/2.0.46 every version of PHP works fine... Outout with 4.3.9: Array ( [file] = Array ( [name] = Test.exe [type] = application/octet-stream [tmp_name] = /uploadkds/phpAZU372 [error] = 0 [size] = 1999592 ) ) Array ( ) 1999592 = original file size :)) But now I did not know is the problem in apache or in php running together with apache 2.0.50... Is there a possibility to find this out so that I have to post the bug to apache group? Thanks, Marcus [2004-09-28 23:05:10] [EMAIL PROTECTED] Have you tried PHP 4.3.8 ? Or 4.3.7 ? (would help us to know when this bug appeared first time) [2004-09-17 12:27:41] marcus dot stolzenberg at kgrz-kassel dot de Hi, I did the test with the: PHP Version 4.3.9RC4-dev / STABLE-200409161030 Same problem: Array ( [file] = Array ( [name] = daemon347.exe [type] = application/octet-stream [tmp_name] = /uploadkds/phpg9gWFe [error] = 0 [size] = 1004032 ) ) Array ( ) 1004032 Marcus [2004-09-16 09:41:26] marcus dot stolzenberg at kgrz-kassel dot de Hi, Yes I have some linux partitions on our IBM mainframe with php... We are running Suse Linux Enterprice Server 8.0 on 31 bit zSeries s390 / zOS I send a make test with 4.3.9rc3 yesterday to: [EMAIL PROTECTED] maybee it helps. I think I will try the HEAD version this evening and than I will report... Marcus 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/30093 -- Edit this bug report at http://bugs.php.net/?id=30093edit=1
#30169 [Opn]: PHP loses POST data when HTTP authentication is used
ID: 30169 Updated by: [EMAIL PROTECTED] Reported By: hcg26 at cam dot ac dot uk Status: Open Bug Type: Variables related Operating System: Linux vnm2 2.4.27 #4 SMP PHP Version: 4.3.8 New Comment: This sounds like the 1.3.31 regression in request body handling. Try this patch: http://cvs.apache.org/viewcvs.cgi/apache-1.3/src/main/http_request.c?r1=1.174r2=1.175 Previous Comments: [2004-09-20 15:29:02] hcg26 at cam dot ac dot uk My .htaccess is bog standard: AuthType basic AuthName Test AuthUserFile /home/www/.../htdocs/v1/smsin/.htpasswd require valid-user [2004-09-20 15:26:28] hcg26 at cam dot ac dot uk Description: On a Linux Apache server (1.3.31), PHP loses request variables when they were sent using the POST method and the script is protected via .htaccess authentication (bug produced with user password authentication). The form data are nowhere to be found, not in $_REQUEST or $_POST. My $_SERVER is as follows: ( [CONTENT_LENGTH] = 21 [CONTENT_TYPE] = application/x-www-form-urlencoded [DOCUMENT_ROOT] = /home/www/host name/htdocs [HTTP] = :--- [HTTP] = - --- [HTTP_ACCEPT] = image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, application/x-shockwave-flash, */* [HTTP_ACCEPT_LANGUAGE] = de [HTTP_CACHE_CONTROL] = no-cache [HTTP_CONNECTION] = Keep-Alive [HTTP_HOST] = host name [HTTP_USER_AGENT] = Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; iOpus-I-M) [PATH] = /sbin:/bin:/usr/sbin:/usr/bin [REMOTE_ADDR] = 217.236.36.198 [REMOTE_PORT] = 2029 [SCRIPT_FILENAME] = /home/www/host name/htdocs/v1/phpbug/test.php [SCRIPT_URI] = http://host name/v1/phpbug/test.php [SCRIPT_URL] = /v1/phpbug/test.php [SERVER_ADDR] = 81.3.18.152 [SERVER_ADMIN] = removed [SERVER_NAME] = host name [SERVER_PORT] = 80 [SERVER_SIGNATURE] = [SERVER_SOFTWARE] = Apache/1.3.31 (Unix) mod_ssl/2.8.19 OpenSSL/0.9.7d PHP/4.3.8 [UNIQUE_ID] = QU7XaH8AAAEAAASeDko [GATEWAY_INTERFACE] = CGI/1.1 [SERVER_PROTOCOL] = HTTP/1.1 [REQUEST_METHOD] = POST [QUERY_STRING] = [REQUEST_URI] = /v1/phpbug/test.php [SCRIPT_NAME] = /v1/phpbug/test.php [PATH_TRANSLATED] = /home/www/host name/htdocs/v1/phpbug/test.php [PHP_SELF] = /v1/phpbug/test.php ) Reproduce code: --- -- html input form form action=phpbug/test.php method=post POST input type=text name=a input type=submit hr form action=phpbug/test.php method=get GET input type=text name=a input type=submit --php script ?php echo pre; print_r($_POST); echo --; print_r($_REQUEST); echo --; print_r($_SERVER); ? Expected result: Array ( [a] = dfdsfds ) --Array ( [a] = dfdsfds ) [as obtained when using the GET method] Actual result: -- Array ( [a] = ) --Array ( [a] = ) NOTE: the $_SERVER[CONTENT_LENGTH] is correct. -- Edit this bug report at http://bugs.php.net/?id=30169edit=1
#29939 [Opn-Bgs]: HTTP streams not functioning as expected running through web server.
ID: 29939 Updated by: [EMAIL PROTECTED] Reported By: testwicks17543 at yahoo dot com -Status: Open +Status: Bogus Bug Type: HTTP related Operating System: RedHat ES 3 PHP Version: 4.3.8 New Comment: Please file bugs in the RHEL php package at https://bugzilla.redhat.com/bugzilla/. PHP socket handling is not reliable and may cause segfaults or hangs if you push the fd numbers over 1024. This is a duplicate of #24189. Previous Comments: [2004-09-01 23:43:29] testwicks17543 at yahoo dot com Description: We are currently experiencing issues with HTTP streams within PHP scripts being run through Apache (using the php4_module). We are not experiencing the issues if we run the php script from the command line. System info: System is running RedHat ES 3 with all the latest patches applied. The system has approx 512 virtual web sites configured in Apache. The Apache startup script changes the max file descriptors to a number higher than the RedHat default of 1024 (the number is currently set too 409600; we have also tried lower numbers such as 8192; please, note that Apache opens more than 1024 files upon startup and that the default setting is no longer an option; each virtual site has its own access log and error log). RPM list: kernel-smp-2.4.21-15.0.4.EL httpd-2.0.46-32.ent.3 php-4.3.2-11.1.ent php-mysql-4.3.2-11.1.ent PHP specifics: './configure' '--host=i386-redhat-linux' '--build=i386-redhat-linux' '--target=i386-redhat-linux-gnu' '--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib' '--libexecdir=/usr/libexec' '--localstatedir=/var' '--sharedstatedir=/usr/com' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--cache-file=../config.cache' '--with-config-file-path=/etc' '--with-config-file-scan-dir=/etc/php.d' '--enable-force-cgi-redirect' '--disable-debug' '--enable-pic' '--disable-rpath' '--enable-inline-optimization' '--with-bz2' '--with-db4=/usr' '--with-curl' '--with-dom=/usr' '--with-exec-dir=/usr/bin' '--with-freetype-dir=/usr' '--with-png-dir=/usr' '--with-gd' '--enable-gd-native-ttf' '--with-ttf' '--with-gettext' '--with-ncurses' '--with-gmp' '--with-iconv' '--with-jpeg-dir=/usr' '--with-openssl' '--with-png' '--with-pspell' '--with-regex=system' '--with-xml' '--with-expat-dir=/usr' '--with-pcre-regex=/usr' '--with-zlib' '--with-layout=GNU' '--enable-bcmath' '--enable-exif' '--enable-ftp' '--enable-magic-quotes' '--enable-safe-mode' '--enable-sockets' '--enable-sysvsem' '--enable-sysvshm' '--enable-discard-path' '--enable-track-vars' '--enable-trans-sid' '--enable-yp' '--enable-wddx' '--enable-mbstring' '--enable-mbstr-enc-trans' '--enable-mbregex' '--without-oci8' '--with-pear=/usr/share/pear' '--with-imap=shared' '--with-imap-ssl' '--with-kerberos=/usr/kerberos' '--with-ldap=shared' '--with-mysql=shared,/usr' '--with-pgsql=shared' '--with-unixODBC=shared' '--enable-memory-limit' '--enable-bcmath' '--enable-shmop' '--enable-versioning' '--enable-calendar' '--enable-dbx' '--enable-dio' '--enable-mcal' '--with-apxs2filter=/usr/sbin/apxs' We would like to know how to further troubleshoot this error to determine the reason why this error message started happening. We have other web servers configured identically (same version of RedHat distribution, same version of Apache, PHP etc.), with fewer web sites that are not experiencing this issue. Please, let us know if there is any additional information needed. Thank you, Reproduce code: --- Code that produces errors: ?php fopen(http://somewebhost.domain.gTLD/index.html;, r); $httpfile = file_get_contents(http://somewebhost.domain.gTLD/index.html;); include 'http://somewebhost.domain.gTLD/index.html'; ? Expected result: The contents of index.html. Actual result: -- Errors: Warning: fopen(http://somewebhost.domain.gTLD): failed to open stream: HTTP request failed! in /www/localwebhost.domain.gTLD/htdocs/test.php on line 2 Warning: file_get_contents(http://somewebhost.domain.gTLD/index.html): failed to open stream: HTTP request failed! Ø ` in /www/localwebhost.domain.gTLD/htdocs/test.php on line 3 Warning: main(http://somewebhost.domain.gTLD/index.html): failed to open stream: HTTP request failed! 0vÿ¿Øc xÀN1a1þ: in /www/localwebhost.domain.gTLD/htdocs/test.php on line 4 Warning: main(): Failed opening 'http://somewebhost.domain.gTLD/index.html' for inclusion (include_path='.') in /www/localwebhost.domain.gTLD/htdocs/test.php on line 4 -- Edit this bug report at http://bugs.php.net/?id=29939edit=1
#24189 [Com]: big problem on stream function
ID: 24189 Comment by: jorton at redhat dot com Reported By: anton at valuehost dot ru Status: Bogus Bug Type: Sockets related Operating System: FreeBSD 4.8 PHP Version: 4.3.2 New Comment: This is a real bug. The issue is that fd_set is a fixed-size array, and if FD_SET is passed an fd number greater than FD_SETSIZE, it has undefined behaviour, i.e. it overruns the array and corrupts memory. All uses of select() in PHP look to be unsafe because of this. The proper fix is to use poll() on platforms where it is available, and to always check that fd FD_SETSIZE before using FD_SET. Previous Comments: [2003-06-15 16:34:13] [EMAIL PROTECTED] let's keep this bogus.. [2003-06-15 11:02:43] anton at valuehost dot ru Do not want to help well and it is not necessary, in backtrace I and itself can understand. [2003-06-15 10:58:08] [EMAIL PROTECTED] Not enough information - bogus. (get rid of the zendoptimizer on some machine and provide a backtrace, otherwise - not bug) [2003-06-15 10:55:20] anton at valuehost dot ru In it that all and the problem, on dev server to us was not possible to receive this mistake. The problem arises on production a level what from scripts of users of her causes to understand not really, we hold over 25000 sites. We at once find out any mistakes and we celebrate them quickly enough, and this of us has led up a blind alley :( But I can tell precisely, that all functions which work with socket cease to work, what that restriction on work mod_php is imposed. [2003-06-15 10:25:52] [EMAIL PROTECTED] You should have a dev machine to test this on. Just leave ZendOptimizer out. If you can't do this and can't provide decent backtrace, we can't fix anything. 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/24189 -- Edit this bug report at http://bugs.php.net/?id=24189edit=1
#28635 [Com]: POST-ed data unavailable from a Keep-Alive request
ID: 28635 Comment by: jorton at redhat dot com Reported By: e-nagya at eol dot hu Status: Open Bug Type: Apache related Operating System: Debian Linux, Apache 1.3.31 PHP Version: 4.3.6 New Comment: This is an Apache 1.3 bug not a PHP bug: http://issues.apache.org/bugzilla/show_bug.cgi?id=29257 Previous Comments: [2004-06-05 01:30:07] e-nagya at eol dot hu Description: When used together with Basic Authentication, in some cases the POST-ed data is lost, so it's not available for the php script. Reproduce code: --- Situation when it occurs: You have a directory structure like this: / +-.htaccess | +-source/ | `-- index.html `-target/ `-- target.php In the root directory you place a .htaccess file with the basic authentication setup. In the source directory you have page (eg a .html file), with a form inside, wich uses the post method to send the data to a php script in the target directory. In the target directory you have a script wich does nothing just prints $_POST. The user enters at source/index.html, enters the password for the basic authentication, fills in the form, posts it, and then the script at target dir shows that no post data arrived. It's important, that the user doesn't visit the root directory before doing so. Expected result: You should get the data what you've posted. Actual result: -- What happens is the following: 1) browser requests the index.html, but the server answares 401 Authorization Required 2) browser requests the index.html, now with the authentication data also, wich succeeds now. 3) after the user fills in the form, browser tries to send it 4) target/target.php is requested, but without any authentication information (since it's out of the scope, where the authentication was made at step 2) 5) server answares 401, and keeps the connection open 6) browser this time tries to be smart, and sends the authentication data with the form data also. (In the same connection) 7) now the server accepts the request, and passes it to the php, but it doesn't recognize the posted data. WORKAROUND: If you disable the Keep-Alive in the server or in the browser, it works fine. This bug doesn't exist in lower php and apache versions, like Apache 1.3.29 + php 4.3.4 -- Edit this bug report at http://bugs.php.net/?id=28635edit=1
#27810 [Com]: Apache-2.0.49 crashes on graceful/restart
ID: 27810 Comment by: jorton at redhat dot com Reported By: renato at galle dot com dot br Status: Open Bug Type: Apache2 related Operating System: FreeBSD-5.2.1-RELEASE-p4 PHP Version: 4.3.5 New Comment: php dot 5 dot bluemonster at xoxy dot net, can you get a core dump and backtrace? If it's only triggered by use of mod_ssl, it sounds like a different bug. Previous Comments: [2004-04-22 22:40:58] php dot 5 dot bluemonster at xoxy dot net I continue to have a problem on graceful restart when using the alternative patch. No error is logged but Apache stops responding after `apachectl graceful' or sending HUP. It does seem to work with a normal stop/ startssl. I'm on FreeBSD 5.2.1, whereas the others, for whom it's working, are on Linux. I've reverted to a backup of 4.3.4 and am looking into FastCGI as an alternative. [2004-04-22 16:33:37] sugihara at gix dot or dot jp OS: VineLinux2.6r4(kernel2.4.22) Apache: 2.0.49 PHP : 4.3.6 I tried jorton's alternative patch too. With or without SSL Apache behave properly when it catch 'HUP' or 'USR1' signal. [2004-04-22 01:22:24] danu at drydog dot com I tried jorton's alternative patch with PHP 4.3.6 and Apache 2.0.49 (with SSL) on an otherwise standard RedHat 9 on Intel. I can confirm it works (that is, I can restart Apache) on 2 different systems. YEAH!! Previous to patching, it did not work (that is, Apache errored out with these messages in the Apache error log: [Wed Mar 31 17:14:43 2004] [notice] SIGHUP received. Attempting to restart [Wed Mar 31 17:14:43 2004] [notice] seg fault or similar nasty error detected in the parent process [Wed Mar 31 17:14:48 2004] [warn] pid file /var/run/httpd.pid overwritten -- Unclean shutdown of previous Apache run? [2004-04-22 00:26:07] jorton at redhat dot com Can you try this alternative patch: http://www.apache.org/~jorton/php-4.3.6-pcrealloc.patch [2004-04-21 15:58:16] php dot 5 dot bluemonster at xoxy dot net I continue to have problems with this, on FreeBSD 5.2.1 using ale's patched port for 4.3.6 and apache 2.0.49. apache seems to survive a graceful restart when I start it without SSL, but if I stop apache it leaves behind a bunch of httpd processes that I have to kill. If I start apache with SSL then it does not survive the graceful restart. 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/27810 -- Edit this bug report at http://bugs.php.net/?id=27810edit=1
#27810 [Com]: Apache-2.0.49 crashes on graceful/restart
ID: 27810
Comment by: jorton at redhat dot com
Reported By: renato at galle dot com dot br
Status: Open
Bug Type: Apache2 related
Operating System: FreeBSD-5.2.1-RELEASE-p4
PHP Version: 4.3.5
New Comment:
Can you try this alternative patch:
http://www.apache.org/~jorton/php-4.3.6-pcrealloc.patch
Previous Comments:
[2004-04-21 15:58:16] php dot 5 dot bluemonster at xoxy dot net
I continue to have problems with this, on FreeBSD 5.2.1
using ale's patched port for 4.3.6 and apache 2.0.49.
apache seems to survive a graceful restart when I start
it without SSL, but if I stop apache it leaves behind a
bunch of httpd processes that I have to kill.
If I start apache with SSL then it does not survive the
graceful restart.
[2004-04-21 07:46:57] sugihara at gix dot or dot jp
OS: VineLinux2.6r4(kernel2.4.22)
Apache: 2.0.49
PHP : 4.3.6
FreeBSD port works fine on Linux too.
Without patch, 4.3.6 also caused Apache's segfault error. So Apache
crashed everytime log files were rotated by cron.
Thank you so much.
[2004-04-20 16:49:04] paul at vanbrouwershaven dot com
Same problem here with the lasted stable release PHP 4.3.6
[2004-04-19 19:09:19] renato at galle dot com dot br
Here is the patch to fix it on php-4.3.6:
--- ext/pcre/php_pcre.c.origFri Apr 16 09:21:14 2004
+++ ext/pcre/php_pcre.c Fri Apr 16 09:23:36 2004
@@ -106,15 +106,6 @@
REGISTER_LONG_CONSTANT(PREG_SPLIT_DELIM_CAPTURE,
PREG_SPLIT_DELIM_CAPTURE, CONST_CS | CONST_PERSISTENT);
REGISTER_LONG_CONSTANT(PREG_SPLIT_OFFSET_CAPTURE,
PREG_SPLIT_OFFSET_CAPTURE, CONST_CS | CONST_PERSISTENT);
REGISTER_LONG_CONSTANT(PREG_GREP_INVERT, PREG_GREP_INVERT, CONST_CS
| CONST_PERSISTENT);
-
- pcre_malloc = php_pcre_malloc;
- pcre_free = php_pcre_free;
-
-#ifdef NO_RECURSE
- pcre_stack_malloc = php_pcre_malloc;
- pcre_stack_free = php_pcre_free;
-#endif
-
return SUCCESS;
}
/* }}} */
@@ -130,6 +121,16 @@
}
/* }}} */
+/* {{{ PHP_RINIT_FUNCTION(pcre) */
+static PHP_RINIT_FUNCTION(pcre)
+{
+ pcre_malloc = php_pcre_malloc;
+ pcre_free = php_pcre_free;
+
+ return SUCCESS;
+}
+/* }}} */
+
/* {{{ pcre_get_compiled_regex
*/
PHPAPI pcre* pcre_get_compiled_regex(char *regex, pcre_extra **extra,
int *preg_options) {
@@ -1527,7 +1528,7 @@
pcre_functions,
PHP_MINIT(pcre),
PHP_MSHUTDOWN(pcre),
- NULL,
+ PHP_RINIT(pcre),
NULL,
PHP_MINFO(pcre),
NO_VERSION_YET,
[2004-04-19 19:09:19] renato at galle dot com dot br
Here is the patch to fix it on php-4.3.6:
--- ext/pcre/php_pcre.c.origFri Apr 16 09:21:14 2004
+++ ext/pcre/php_pcre.c Fri Apr 16 09:23:36 2004
@@ -106,15 +106,6 @@
REGISTER_LONG_CONSTANT(PREG_SPLIT_DELIM_CAPTURE,
PREG_SPLIT_DELIM_CAPTURE, CONST_CS | CONST_PERSISTENT);
REGISTER_LONG_CONSTANT(PREG_SPLIT_OFFSET_CAPTURE,
PREG_SPLIT_OFFSET_CAPTURE, CONST_CS | CONST_PERSISTENT);
REGISTER_LONG_CONSTANT(PREG_GREP_INVERT, PREG_GREP_INVERT, CONST_CS
| CONST_PERSISTENT);
-
- pcre_malloc = php_pcre_malloc;
- pcre_free = php_pcre_free;
-
-#ifdef NO_RECURSE
- pcre_stack_malloc = php_pcre_malloc;
- pcre_stack_free = php_pcre_free;
-#endif
-
return SUCCESS;
}
/* }}} */
@@ -130,6 +121,16 @@
}
/* }}} */
+/* {{{ PHP_RINIT_FUNCTION(pcre) */
+static PHP_RINIT_FUNCTION(pcre)
+{
+ pcre_malloc = php_pcre_malloc;
+ pcre_free = php_pcre_free;
+
+ return SUCCESS;
+}
+/* }}} */
+
/* {{{ pcre_get_compiled_regex
*/
PHPAPI pcre* pcre_get_compiled_regex(char *regex, pcre_extra **extra,
int *preg_options) {
@@ -1527,7 +1528,7 @@
pcre_functions,
PHP_MINIT(pcre),
PHP_MSHUTDOWN(pcre),
- NULL,
+ PHP_RINIT(pcre),
NULL,
PHP_MINFO(pcre),
NO_VERSION_YET,
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/27810
--
Edit this bug report at http://bugs.php.net/?id=27810edit=1
#24853 [Com]: General extensions load fails for undefined symbols
ID: 24853 Comment by: jorton at redhat dot com Reported By: alietss at yahoo dot com Status: Bogus Bug Type: Apache2 related Operating System: Linux RedHat 9.0 PHP Version: 4CVS-2003-07-29 (stable) New Comment: This bug was due to use of the --enable-versioning flag, which is in principle not compatible with using loadable modules. In practice it works with libtool 1.4 and earlier, since those versions don't implement the -export-symbols flag correctly. Upgrade to libtool 1.5 and -export-symbols does what you tell it, and PHP can't load modules any more. This bug is in no way specific to the apache2handler or filter; it would affect the apache 1.3 SAPI module as well, or any SAPI which is built as a DSO on Unix. Previous Comments: [2003-07-29 10:51:36] [EMAIL PROTECTED] you are using unofficial patches to PHP? Not our prob. Also, you use certain configure options that you should not use, like --enable-versioning, --with-regex=system.. Try with this configure line: ./configure --disable-all --with-apxs2...and only ONE shared extension. This works fine for me, no bug. [2003-07-29 09:09:48] [EMAIL PROTECTED] What process model are you using with your apache? [2003-07-29 08:53:12] alietss at yahoo dot com Description: Hi people: I'm testing php-4.3.3 on RedHat 9.0 with httpd-2.0.47-3 added unixd.h and related headers files and used redhat patches to prevent the load of extensions when exists undefined symbols, I built php as a handler, when I start apache the extensions fails to load with this errors on apache error log... PHP Warning: Unknown(): Unable to load dynamic library '/usr/lib/php4/imap.so' - /usr/lib/php4/imap.so: undefined symbol: file_globals in Unknown on line 0 PHP Warning: Unknown(): Unable to load dynamic library '/usr/lib/php4/ldap.so' - /usr/lib/php4/ldap.so: undefined symbol: OnUpdateInt in Unknown on line 0 PHP Warning: Unknown(): Unable to load dynamic library '/usr/lib/php4/mcal.so' - /usr/lib/php4/mcal.so: undefined symbol: convert_to_array in Unknown on line 0 PHP Warning: Unknown(): Unable to load dynamic library '/usr/lib/php4/mcrypt.so' - /usr/lib/php4/mcrypt.so: undefined symbol: OnUpdateString in Unknown on line 0 PHP Warning: Unknown(): Unable to load dynamic library '/usr/lib/php4/mhash.so' - /usr/lib/php4/mhash.so: undefined symbol: zend_register_long_constant in Unknown on line 0 PHP Warning: Unknown(): Unable to load dynamic library '/usr/lib/php4/mssql.so' - /usr/lib/php4/mssql.so: undefined symbol: OnUpdateBool in Unknown on line 0 PHP Warning: Unknown(): Unable to load dynamic library '/usr/lib/php4/mysql.so' - /usr/lib/php4/mysql.so: undefined symbol: OnUpdateInt in Unknown on line 0 PHP Warning: Unknown(): Unable to load dynamic library '/usr/lib/php4/odbc.so' - /usr/lib/php4/odbc.so: undefined symbol: OnUpdateInt in Unknown on line 0 PHP Warning: Unknown(): Unable to load dynamic library '/usr/lib/php4/pdf.so' - /usr/lib/php4/pdf.so: undefined symbol: core_globals in Unknown on line 0 PHP Warning: Unknown(): Unable to load dynamic library '/usr/lib/php4/pgsql.so' - /usr/lib/php4/pgsql.so: undefined symbol: OnUpdateBool in Unknown on line 0 PHP Warning: Unknown(): Unable to load dynamic library '/usr/lib/php4/snmp.so' - /usr/lib/php4/snmp.so: undefined symbol: zend_get_parameters_ex in Unknown on line 0 PHP Warning: Unknown(): Unable to load dynamic library '/usr/lib/php4/xslt.so' - /usr/lib/php4/xslt.so: undefined symbol: executor_globals in Unknown on line 0 Here my configure line './configure' '--host=i686-pc-linux-gnu' '--build=i686-pc-linux-gnu' '--target=i686-redhat-linux-gnu' '--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib' '--libexecdir=/usr/libexec' '--localstatedir=/var' '--sharedstatedir=/usr/com' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--cache-file=../config.cache' '--with-config-file-path=/etc' '--with-config-file-scan-dir=/etc/php.d' '--enable-force-cgi-redirect' '--disable-debug' '--enable-pic' '--disable-rpath' '--enable-inline-optimization' '--with-bz2' '--with-db4=/usr' '--with-curl' '--with-dom=/usr' '--with-exec-dir=/usr/bin' '--with-freetype-dir=/usr' '--with-png-dir=/usr' '--with-gd' '--enable-gd-native-ttf' '--with-ttf' '--with-gdbm' '--with-gettext' '--with-pdflib=shared' '--with-tiff-dir=/usr' '--with-ncurses' '--with-gmp' '--with-iconv' '--enable-xslt=shared' '--with-jpeg-dir=/usr' '--with-openssl' '--with-png' '--with-pspell' '--with-regex=system' '--with-xml' '--with-xmlrpc' '--with-expat-dir=/usr' '--with-zlib' '--with-layout=GNU' '--enable-bcmath' '--enable-exif
#18648 [Com]: Single entry form POST gives incorrect variable content
ID: 18648 Comment by: jorton at redhat dot com Reported By: ms at ecs dot soton dot ac dot uk Status: Bogus Bug Type: Apache2 related Operating System: All PHP Version: 5CVS-2003-01-29 (dev) / 4CVS-20020121 (stable) New Comment: The default configuration in Red Hat Linux has only the Files *.php* section. This bug appears to occur if the AddType x-httpd-php .php is added *as well* as the files *.php section. http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=76559 Previous Comments: [2003-02-20 09:43:34] apiset at hotmail dot com The default httpd configuration on RH8.0 use Files *.php SetOutputFilter PHP SetInputFilter PHP LimitRequestBody 524288 /Files so is this RedHat fault? I replace above lines with AddType application/x-httpd-php .php and it works!!! should tell redhat about this [2003-02-07 21:50:42] [EMAIL PROTECTED] First I made a typo in my previous comment. I mean application/x-httpd-php everywhere I wrote x-http-php. Anyway let me mark this as bogus... (The problem turned out to be a user fault.) [2003-02-07 19:33:06] j-blion at ifrance dot com Apache 2.0.44 / PHP 4.3.1-dev (php4-STABLE-200302071830) No more problem. Neither sessions, neither forms Good job ! [2003-02-06 03:57:54] rep at devdomain dot com That's it. [2003-02-04 20:49:40] laday at chollian dot net Thanks... It works ok. 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/18648 -- Edit this bug report at http://bugs.php.net/?id=18648edit=1
#19292 [Com]: random error: open_basedir restriction in effect. File is in wrong directory
ID: 19292 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Critical Bug Type: Apache related Operating System: linux PHP Version: 4.3.0-dev,4.2.3 New Comment: I wrote regression tests for safe mode recently which trigger this bug reliably when upgrading to 4.3.0 from 4.2.2 on Apache 2.0.40. In the Apache config I use: (erring on the side of verbosity) Directory /local/qa/perl-framework/t/htdocs/php/safemode php_admin_value safe_mode 1 php_admin_value safe_mode_exec_dir /bin php_admin_value open_basedir / php_admin_value display_errors 0 php_admin_value log_errors 1 php_admin_value safe_mode_allowed_env_vars FOO_ php_admin_value safe_mode_protected_env_vars FOO_FEE /Directory Then: /local/qa/perl-framework/t/htdocs/php/safemode/readfile.php contains: ?php readfile(/etc/passwd); ? The server error log gets this output for the script: PHP Warning: Unknown(): open_basedir restriction in effect. File(/local/qa/perl-framework/t/htdocs/php/safemode/readfile.php) is not within the allowed path(s): (/) in Unknown on line 0 PHP Warning: Unknown(/local/qa/perl-framework/t/htdocs/php/safemode/readfile.php): failed to create stream: Operation not permitted in Unknown on line 0 PHP Warning: Unknown(): Failed opening '/local/qa/perl-framework/t/htdocs/php/safemode/readfile.php' for inclusion (include_path='.:/usr/share/pear') in Unknown on line 0 Previous Comments: [2003-01-06 11:29:06] [EMAIL PROTECTED] Getting totally wrong dir in the output of the error mess open_basedir restriction in effect. File(index.php) is not within the allowed path(s): (/home/userB) Getting this error when surfing to userA which has open_basedir set to /home/userA in apache virthost, one gets that access to userB home isn't granted. This might not be a fault in the open_basedir code, but for some reason it get's the wrong open_basedir dir from the calling function. If someone could take a deeper look at this it would be nice, hard to explain to all customers that this problem is out of our hands to fix. [2003-01-06 10:33:12] [EMAIL PROTECTED] Bug confirmed on FreeBSD 4.6 with php 4.3.0. Totally random it seems. [2003-01-01 10:11:49] [EMAIL PROTECTED] i have the same problem after i upgrade from 4.2.2 to 4.3.0(release version) pls update bug version No. it's _NOT_ fixed in php-4.3.0 it seems php may not re-initize correctly cause there's an un-relative bug: http://bugs.php.net/?id=21306 but i'm just guessing [2002-11-12 16:06:18] [EMAIL PROTECTED] Same problem here on FreeBSD 4.7-STABLE + Apache and it's really a showstoppper. PHP is today's 4.3.0-dev snapshot, but a 4.2.3 release had the same behavior. Sometimes the error message reports the open_basedir of another unrelated virtualhost. The problem _never_ showed up on OpenBSD 3.1/3.2 + Zeus + PHP 4.2.3 with FastCGI on a very similar setup. There's definitely an off-by-one or some kind of memory corruption somewhere. [2002-11-11 08:43:36] [EMAIL PROTECTED] We randomly gets this error even if virtual server has this option switched off. (but other virtual servers has this option on) 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/19292 -- Edit this bug report at http://bugs.php.net/?id=19292edit=1
#18648 [Com]: Single entry form POST gives incorrect variable content
ID: 18648 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: No Feedback Bug Type: HTTP related Operating System: Tru64 PHP Version: 4.2.2 New Comment: I can't reproduce this problem using identical RPMs on Red Hat Linux 8.0 - this bug seems hard to trigger. [EMAIL PROTECTED] - any further insight would be appreciated. I can't find anything on the CVS logs about fixes for Tru64. There is one fix to main/php_variables.c: 2002-09-07 Yasuo Ohgaki [EMAIL PROTECTED] ... * main/php_variables.c: Fixed POST/GET/COOKIE var handling but this seems to concern NUL-terminated strings in field values, unles I'm mistaken. Previous Comments: [2002-11-18 13:16:23] [EMAIL PROTECTED] I also get the same problem with Linux RH8.0 I'm running apache 2.0.40-8 and php-4.2.2-8.0.5 form action=test.php method=post Test: input type=text name=id value=bar input type=submit /form I tested this workaround by inserting into one of my forms and it works: input type=hidden name=spoof [2002-10-23 08:30:10] [EMAIL PROTECTED] Hi, I get the same problem with Linux RH8.0 using the default RPMs (which includes apache part deux). As a workaround I am adding: input type=hidden name=spoof into my one field forms. thanks, josh. [2002-09-11 11:49:02] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to Open. Thank you. [2002-08-15 23:09:06] [EMAIL PROTECTED] Tested this with latest snapshot and Apache 1.3.26 on Tru64, seems to work fine. So Jani might be right with his Apache2-Guess. [2002-08-15 07:15:47] [EMAIL PROTECTED] Common for both cases seems to be Apache2..please try with Apache 1.3.26 (and the latest snapshot from today, url above). Apache2 support is experimental btw. 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/18648 -- Edit this bug report at http://bugs.php.net/?id=18648edit=1
