#21006 [Opn->Bgs]: $_Server variables are not global
ID: 21006 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: IIS related Operating System: win 200 server PHP Version: 4.3.0RC3 New Comment: RC3 seems to have fixed it weird character ahowing up in front of $ Previous Comments: [2002-12-14 01:26:40] [EMAIL PROTECTED] On my IIS Server, now running 4.3.0RC3 ( i just installed and tested it, started writing issue with RC2), $_Server variables are not global, they don't work inside functions specifically $agent = $_SERVER["HTTP_USER_AGENT"]; I hear that *nix machines do not have this issue. The following does not work, there is no variable set for the user agent and i get an error. Parse error: parse error, unexpected T_VARIABLE in c:\ inetpub\wwwroot\admin\index.php on line 26 PHP Parse error: parse error, unexpected T_VARIABLE in c:\ inetpub\wwwroot\admin\index.php on line 26 Basically the variable is not set. This does work outside the function however (i coded this to explain issue more simply, originally got help at http://www.webmasterworld.com/forum13/1766.htm which has more specific details, example code and the like) $_SERVER["HTTP_USER_AGENT"]; is global in scope but is not accessable in my installation inside a function. I now use define to pass variable down to my function and avoid any more issues personally. I have a feeling it has to do with my using release candidate 2 but do not wish to test with previous versions of php at this time. This seems like an IIS quirk as the forum moderator seemed not to have this issue and agreed $_SERVER variables are global in scope, as is my understanding from was what i read in the manual. info from my phpinfo() PHP Version 4.3.0RC2 System Windows NT localhost 5.0 build 2195 Build Date Nov 27 2002 21:11:38 Server API CGI/FastCGI register globals is also on for the time being, (seems like this is always asked) -- Edit this bug report at http://bugs.php.net/?id=21006&edit=1
#21006 [NEW]: $_Server variables are not global
From: [EMAIL PROTECTED] Operating system: win 200 server PHP version: 4.3.0RC3 PHP Bug Type: IIS related Bug description: $_Server variables are not global On my IIS Server, now running 4.3.0RC3 ( i just installed and tested it, started writing issue with RC2), $_Server variables are not global, they don't work inside functions specifically $agent = $_SERVER["HTTP_USER_AGENT"]; I hear that *nix machines do not have this issue. The following does not work, there is no variable set for the user agent and i get an error. Parse error: parse error, unexpected T_VARIABLE in c:\ inetpub\wwwroot\admin\index.php on line 26 PHP Parse error: parse error, unexpected T_VARIABLE in c:\ inetpub\wwwroot\admin\index.php on line 26 Basically the variable is not set. This does work outside the function however (i coded this to explain issue more simply, originally got help at http://www.webmasterworld.com/forum13/1766.htm which has more specific details, example code and the like) $_SERVER["HTTP_USER_AGENT"]; is global in scope but is not accessable in my installation inside a function. I now use define to pass variable down to my function and avoid any more issues personally. I have a feeling it has to do with my using release candidate 2 but do not wish to test with previous versions of php at this time. This seems like an IIS quirk as the forum moderator seemed not to have this issue and agreed $_SERVER variables are global in scope, as is my understanding from was what i read in the manual. info from my phpinfo() PHP Version 4.3.0RC2 System Windows NT localhost 5.0 build 2195 Build Date Nov 27 2002 21:11:38 Server API CGI/FastCGI register globals is also on for the time being, (seems like this is always asked) -- Edit bug report at http://bugs.php.net/?id=21006&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21006&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21006&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21006&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21006&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21006&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21006&r=support Expected behavior: http://bugs.php.net/fix.php?id=21006&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21006&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21006&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21006&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21006&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21006&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21006&r=isapi
#20703 [Fbk->NoF]: session object's array is restored corruptly
ID: 20703
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: No Feedback
Bug Type: Session related
Operating System: debian woody latest
PHP Version: 4.2.2
New Comment:
No feedback was provided for this bug for over 2 weeks, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
Previous Comments:
[2002-11-29 00:57:17] [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.
[2002-11-28 13:57:59] [EMAIL PROTECTED]
I'am not sure, if this is a in bug php, could be in my code, but I have
looked my code over and over and could not find anything...
So I describe my problem:
I have a session object, and it has an array variable.
In the code I do some array_shift, and array_push on one of the
elements of this array, wich is also an array. And I do something like
this:
"get" return by reference from the session objects array:
$keyArray=&$object->get("key");
then I do array_shift, and array_push to maintain a FIFO like thing to
store the previous pagenames.
Now the problem:
normally this works in a number of pages, but in case of one page it
acts strangely: for some reason an extra element into the array appears
like this:
normally the array values should change when going from page5 to page6
from (now I am on page5):
page1
page2
page3
page4
page5
into (here there is a request for a new page: page6):
page2
page3
page4
page5
page6
but instead !!! it changes to:
page1
page5
page1
page6
page1
I tried to track down where this happens, and I found out, that is
happening between the __sleep and __wakeup methods, which would mean,
that serialize, and unserialize does not work correctly.
Another wery strange thing is that this work perfecly on the local
development server, which runs the same version of php...
so that's it... I am going mad now! bye..
--
Edit this bug report at http://bugs.php.net/?id=20703&edit=1
#21005 [NEW]: libpng 1.2.5; segfault while loading png image
From: [EMAIL PROTECTED] Operating system: Linux 2.4.18 PHP version: 4.2.3 PHP Bug Type: GD related Bug description: libpng 1.2.5; segfault while loading png image After recompiling php 4.2.3 with the gd image functions, I've found that libpng 1.2.5 is not compatible with php 4.2.3. While loading a png file using ImageCreateFromPNG($img); where $img is the filename, php would segfault. After recompiling php multiple times, i've still had the same problem. I gave the stable version of php in the development stage a try, and still recieved a segfault. So then i used the strace function at the command line along with the php cli to figure out that it would segfault when the png image was loaded. When i viewed the libpng website, i found the following... "The current public release, libpng 1.2.5, has a new API (since 1.0.x) for dynamically enabling and disabling certain optimizations (currently limited to MMX code--which is compiled into GNU C versions only if PNG_THREAD_UNSAFE_OK is defined, due to the gcc code's use of static global variables to work around addressing limitations). As a consequence of this and some other changes, its DLL and shared-library (.so) numbers were bumped from 2 to 3." After reading this, i've decided to downgrade to libpng1.0.15 and recompiled php. After doing this, the segfault would not appear again. Hopes this helps... -- Edit bug report at http://bugs.php.net/?id=21005&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21005&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21005&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21005&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21005&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21005&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21005&r=support Expected behavior: http://bugs.php.net/fix.php?id=21005&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21005&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21005&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21005&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21005&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21005&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21005&r=isapi
#17897 [Com]: POST form variables are empty
ID: 17897 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Apache2 related Operating System: Linux PHP Version: 4.2.1 New Comment: I think the problem is PHP4. Because I installed PHP on both Apache and IIS of W2k. I got the same problem. The following are the test program (test.php). TEST I always get empty Arrays. I never imagine that such simple function have bugs in PHP, or I know to little about the PHP settings! Who can HELP!!! My system cannot progress!!! Previous Comments: [2002-11-18 03:03:47] [EMAIL PROTECTED] ok the solution to my problem is simple - I am using AddOutputFilter PHP;INCLUDES .php so the post variables are missing - thats because you need also to set AddInputFilter PHP .php otherwise Apache2 will not forward the POST vars! [2002-09-21 02:20:42] [EMAIL PROTECTED] Thanks [EMAIL PROTECTED]! Adding "AddType application/x-httpd-php .php" to the conf file worked for me. PHP 4.2.3 APACHE 2.0.40 on WindowsXP [2002-09-06 14:12:36] [EMAIL PROTECTED] this helped me... LoadModule php4_module php4apache2.dll AddType application/x-httpd-php .php this doen't work #LoadModule php4_module php4apache2.dll # #SetOutputFilter PHP # [2002-09-06 14:05:20] [EMAIL PROTECTED] Untitled both echo are empty... oh yea and file is called t.php... and i have gloabal = on and populoating varibles with post data... help... [2002-07-09 18:22:00] [EMAIL PROTECTED] Not really bug (in PHP). If '/' is not added, then a redirection is done to the / address..and of course the post data is lost. Using that kind of urls in "action" field is not very wise.. 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/17897 -- Edit this bug report at http://bugs.php.net/?id=17897&edit=1
#20985 [Com]: heavy load = Segmentation fault
ID: 20985 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Reproducible crash Operating System: Redhat Linux 7.3 & 8 PHP Version: 4.3.0RC3 New Comment: If php is built into apache, where should I then be able to find a core file? apache is here: /usr/local/apache/bin Previous Comments: [2002-12-13 16:53:39] [EMAIL PROTECTED] Go to the php directory, inside that directory edit a file called config.nice, one line above the line, which contains "$@" add the following line: '--enable-debug' \ now do: rm config.cache; make clean; ./config.nice; make; make install You've now compiled & installed PHP that contains debugging symbols, when a crash occurs you should be able to see more detailed information when analyzing core files generated due to crash in PHP. To see data at a certain step use gdb command such as frame 5, which will take you to a particular frame, list command, which will show the source code at this point and then p command to print the values of various variables & pointers. [2002-12-13 16:40:34] [EMAIL PROTECTED] > Could you please compile your PHP with --enable-debug I have done so. > If you are able to do that then go the step #5 > (free_zend_constant) and see what data the various > pointers contains. > I am especially interested in seeing what constant is > being freed and if it is the same one everytime. Could you instruct me on how to do this? My knowledge only covers compiling and the information from here: http://bugs.php.net/bugs-generating-backtrace.php [2002-12-13 09:56:09] [EMAIL PROTECTED] Could you please compile your PHP with --enable-debug, this will make you backtrace contain a lot more information. If you are able to do that then go the step #5 (free_zend_constant) and see what data the various pointers contains. I am especially interested in seeing what constant is being freed and if it is the same one everytime. [2002-12-13 09:53:03] [EMAIL PROTECTED] I have also submitted a bug report to Redhat: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=79561 I hope that's ok. [2002-12-13 09:47:25] [EMAIL PROTECTED] I have now tested with RPMs from Redhat: apache-1.3.27-2.i386.rpm php-4.1.2-7.3.6.i386.rpm php-mysql-4.1.2-7.3.6.i386.rpm And these from MySQL: MySQL-shared-3.23.54-1.i386.rpm MySQL-4.0.5-0.i386.rpm And i get the same error: [Fri Dec 13 16:45:25 2002] [notice] child pid 1273 exit signal Segmentation fault (11) 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/20985 -- Edit this bug report at http://bugs.php.net/?id=20985&edit=1
#21004 [NEW]: Header Location Fails
From: [EMAIL PROTECTED] Operating system: NetBSD/Alpha (64bit) - 1.6 PHP version: 4CVS-2002-12-13 (stable) PHP Bug Type: URL related Bug description: Header Location Fails RE: Bug #19754 shouldn't be closed because CVS-2002-12-13 still exihibit this problem. index.php: http://".$_SERVER['HTTP_HOST']; $location.= dirname($_SERVER['PHP_SELF'])."/"."index2.php"; header($location); ?> --- index2.php: You have been redirected"; ?> --- calling index.php should redir to index2.php and echo out: You have been redirected Instead both Mozzila 1.2b and IE 6.x show a blank page. -- Edit bug report at http://bugs.php.net/?id=21004&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21004&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21004&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21004&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21004&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21004&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21004&r=support Expected behavior: http://bugs.php.net/fix.php?id=21004&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21004&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21004&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21004&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21004&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21004&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21004&r=isapi
#17098 [Com]: apache sending 304 - not modified header
ID: 17098
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Analyzed
Bug Type: Apache2 related
Operating System: linux
PHP Version: 4.0CVS-2002-10-17
New Comment:
This bug is _NOT_ fixed in 4.3.0 rc3!
In 4.3.0, the apache2 support should not be experimental anymore, so I
think, this is a real showstopper IMHO.
I think, it's time to fix this issue now, it's so annoying and
unneccessary. If this patch has any known drawbacks that I'm not aware
of, then it's NOT the correct solution to simply ignore this subject as
whole.
Daniel
Here is the patch again as diff against php 4.3.0 rc 3:
--- sapi/apache2filter/sapi_apache2.c.old Thu Dec 12 21:48:58
2002
+++ sapi/apache2filter/sapi_apache2.c Thu Dec 12 21:50:43 2002
@@ -619,14 +619,24 @@
return OK;
}
+static int includes_setup(ap_filter_t *f)
+{
+/* We will ALWAYS set the no_local_copy value to 1 so
+ * that we will not send 304s.
+ */
+f->r->no_local_copy = 1;
+
+return OK;
+}
+
static void php_register_hook(apr_pool_t *p)
{
ap_hook_pre_config(php_pre_config, NULL, NULL,
APR_HOOK_MIDDLE);
ap_hook_post_config(php_apache_server_startup, NULL, NULL,
APR_HOOK_MIDDLE);
ap_hook_insert_filter(php_insert_filter, NULL, NULL,
APR_HOOK_MIDDLE);
ap_hook_post_read_request(php_post_read_request, NULL, NULL,
APR_HOOK_MIDDLE);
- ap_register_output_filter("PHP", php_output_filter, NULL,
AP_FTYPE_RESOURCE);
- ap_register_input_filter("PHP", php_input_filter, NULL,
AP_FTYPE_RESOURCE);
+ ap_register_output_filter("PHP", php_output_filter,
includes_setup, AP_FTYPE_RESOURCE);
+ ap_register_input_filter("PHP", php_input_filter,
includes_setup, AP_FTYPE_RESOURCE);
}
AP_MODULE_DECLARE_DATA module php4_module = {
Previous Comments:
[2002-12-03 09:28:16] [EMAIL PROTECTED]
Maybe I missed something. What patch? Is this still a php bug? I
have Apache 2.0.40 and php-4.4-2.
[2002-10-18 06:34:46] [EMAIL PROTECTED]
I tried a patch submited by [EMAIL PROTECTED]
and it seems to solve the problem. I don't know to what extent, but the
logic of it seems ok to me...
[2002-10-18 05:43:08] [EMAIL PROTECTED]
Ok. We should do something about this bug, I suppose.
Mail from Ryou Takagi
= BEGIN
Yasuo Ohgaki wrote:
> Ilia A. wrote:
> >>Summary: Apache2 sending 304 - not modified header
> >>http://bugs.php.net/bug.php?id=17098
> >>
> >>This is serious problem for serious sites.
> >>(Serious sites shouldn't use Apache2, though)
> >
> >
> > This looks like an Apache 2 bug, rather then aPHP one. I am
guessing the fix
> > they made did not work properly.
>
> Great!
> Then we can just wait their fix :)
I am afraid this is not the case. This is the report of the status.
As from Apache 2.0.40, the API of the filter registration functions
has changed. The changelog says:
--- From Apache Changelog: in section "Changes with Apache 2.0.40" ---
*) Add a filter_init parameter to the filter registration functions
so that a filter can execute arbitrary code before the handlers
are invoked. This resolves a problem where mod_include requests
would incorrectly return a 304. [Justin Erenkrantz]
--- End quotation from Apache Changelog ---
And the current mod_include.c in Apache 2.0.43 source tree uses this
API like this:
--- From modules/filters/mod_include.c in Apache 2.0.43 source tree
---
static int includes_setup(ap_filter_t *f)
{
include_dir_config *conf =
(include_dir_config
*)ap_get_module_config(f->r->per_dir_config,
&include_module);
/* When our xbithack value isn't set to full or our platform isn't
* providing group-level protection bits or our group-level bits do
not
* have group-execite on, we will set the no_local_copy value to 1
so
* that we will not send 304s.
*/
if ((*conf->xbithack != xbithack_full)
|| !(f->r->finfo.valid & APR_FINFO_GPROT)
|| !(f->r->finfo.protection & APR_GEXECUTE)) {
f->r->no_local_copy = 1;
}
return OK;
}
/* Note from TAKAGI: several lines omitted */
static void register_hooks(apr_pool_t *p)
{
APR_REGISTER_OPTIONAL_FN(ap_ssi_get_tag_and_value);
APR_REGISTER_OPTIONAL_FN(ap_ssi_parse_string);
APR_REGISTER_OPTIONAL_FN(ap_register_include_handler);
ap_hook_post_config(include_post_config, NULL, NULL,
APR_HOOK_REALLY_FIRST);
ap_hook_fixups(include_fixup, NULL, NULL, APR_HOOK_LAST);
ap_register_output_filter("INCLUDES", includes_filter,
includes_setup,
#21001 [Opn->Fbk]: After installation of 4.2.3 phpinfo displays 4.2.1
ID: 21001 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: *General Issues Operating System: WindowXP PHP Version: 4.2.3 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. Previous Comments: [2002-12-13 16:24:20] [EMAIL PROTECTED] After installing of php-4.2.3-Win32.zip PHPINFO still displays "PHP Version 4.2.1" -- Edit this bug report at http://bugs.php.net/?id=21001&edit=1
#20998 [Bgs]: Link line too long
ID: 20998 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Compile Failure Operating System: Solaris 2.7 PHP Version: 4.3.0RC3 New Comment: Quite correct. The version mentioned in the other bug report is a CVS version so it was not picked up in my search for 4.3. It was also marked bogus, and I did not notice that I had left the status as open, so it was not found in my attempts to search the database. Sorry about that. I will try to work the search form better next time. Previous Comments: [2002-12-13 14:40:35] [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. Because of this, we hope you add your comments to the existing bug instead. Thank you for your interest in PHP. http://bugs.php.net/19533 [2002-12-13 14:29:50] [EMAIL PROTECTED] % ./configure --with-mysql=/opt/mysql --prefix=/opt --with-gdbm --with-ndbm --without-msql --enable-sysvsem --enable-sysvshm --enable-force-cgi-redirect --enable-discard-path --with-ftp --with-gd --with-jpeg-dir=/opt/lib --with-tiff-dir=/opt/lib --with-png-dir=/opt/lib --with-xpm=/opt --with-zlib-dir=/opt/lib --enable-sockets --with-zlib --with-oracle --with-apxs=/opt/web/apache/bin/apxs --enable-discard-path % apxs -q CFLAGS -DSOLARIS2=270 -DMOD_SSL=206106 -I/opt/src/apache_build/php-4.0.4 -I/opt/src/apache_build/php-4.0.4/main -I/opt/src/apache_build/php-4.0.4/main -I/opt/src/apache_build/php-4.0.4/Zend -I/opt/src/apache_build/php-4.0.4/Zend -I/opt/src/apache_build/php-4.0.4/TSRM -I/opt/src/apache_build/php-4.0.4/TSRM -I/opt/src/apache_build/php-4.0.4 -DMOD_PERL -DUSE_PERL_SSI -I/opt/src/apache_build/mod_perl-1.24_01/src -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DEAPI -DUSE_EXPAT -I../lib/expat-lite Apache 1.3.12 Problem: at the conclusion of all the compilation, the link line comes out too long. libtool blows up with: Output line too long. Output line too long. Output line too long. The link line is not linking in libraries, but instead links in every object file on the final link line. Maybe it was libgd that did it? (I tried to configure against the gd 2.0.9 installed on my system, but that does not have gdImageCreateFromXpm in it.) Anyway, I will go back to 4.2 to get my users up and running with gd, but I am assuming this should be fixed at some point. I can try to repair it, but I would have to understand how you have structured your build environment now, and is probably easier for a maintainer to fix it. Thanks very much. -- Edit this bug report at http://bugs.php.net/?id=20998&edit=1
#20985 [Fbk]: heavy load = Segmentation fault
ID: 20985 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Reproducible crash Operating System: Redhat Linux 7.3 & 8 PHP Version: 4.3.0RC3 New Comment: Go to the php directory, inside that directory edit a file called config.nice, one line above the line, which contains "$@" add the following line: '--enable-debug' \ now do: rm config.cache; make clean; ./config.nice; make; make install You've now compiled & installed PHP that contains debugging symbols, when a crash occurs you should be able to see more detailed information when analyzing core files generated due to crash in PHP. To see data at a certain step use gdb command such as frame 5, which will take you to a particular frame, list command, which will show the source code at this point and then p command to print the values of various variables & pointers. Previous Comments: [2002-12-13 16:40:34] [EMAIL PROTECTED] > Could you please compile your PHP with --enable-debug I have done so. > If you are able to do that then go the step #5 > (free_zend_constant) and see what data the various > pointers contains. > I am especially interested in seeing what constant is > being freed and if it is the same one everytime. Could you instruct me on how to do this? My knowledge only covers compiling and the information from here: http://bugs.php.net/bugs-generating-backtrace.php [2002-12-13 09:56:09] [EMAIL PROTECTED] Could you please compile your PHP with --enable-debug, this will make you backtrace contain a lot more information. If you are able to do that then go the step #5 (free_zend_constant) and see what data the various pointers contains. I am especially interested in seeing what constant is being freed and if it is the same one everytime. [2002-12-13 09:53:03] [EMAIL PROTECTED] I have also submitted a bug report to Redhat: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=79561 I hope that's ok. [2002-12-13 09:47:25] [EMAIL PROTECTED] I have now tested with RPMs from Redhat: apache-1.3.27-2.i386.rpm php-4.1.2-7.3.6.i386.rpm php-mysql-4.1.2-7.3.6.i386.rpm And these from MySQL: MySQL-shared-3.23.54-1.i386.rpm MySQL-4.0.5-0.i386.rpm And i get the same error: [Fri Dec 13 16:45:25 2002] [notice] child pid 1273 exit signal Segmentation fault (11) [2002-12-13 08:52:40] [EMAIL PROTECTED] I use files as my session handler. Have also tried with mm, but I think the same happens here. 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/20985 -- Edit this bug report at http://bugs.php.net/?id=20985&edit=1
#20985 [Com]: heavy load = Segmentation fault
ID: 20985 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Reproducible crash Operating System: Redhat Linux 7.3 & 8 PHP Version: 4.3.0RC3 New Comment: > Could you please compile your PHP with --enable-debug I have done so. > If you are able to do that then go the step #5 > (free_zend_constant) and see what data the various > pointers contains. > I am especially interested in seeing what constant is > being freed and if it is the same one everytime. Could you instruct me on how to do this? My knowledge only covers compiling and the information from here: http://bugs.php.net/bugs-generating-backtrace.php Previous Comments: [2002-12-13 09:56:09] [EMAIL PROTECTED] Could you please compile your PHP with --enable-debug, this will make you backtrace contain a lot more information. If you are able to do that then go the step #5 (free_zend_constant) and see what data the various pointers contains. I am especially interested in seeing what constant is being freed and if it is the same one everytime. [2002-12-13 09:53:03] [EMAIL PROTECTED] I have also submitted a bug report to Redhat: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=79561 I hope that's ok. [2002-12-13 09:47:25] [EMAIL PROTECTED] I have now tested with RPMs from Redhat: apache-1.3.27-2.i386.rpm php-4.1.2-7.3.6.i386.rpm php-mysql-4.1.2-7.3.6.i386.rpm And these from MySQL: MySQL-shared-3.23.54-1.i386.rpm MySQL-4.0.5-0.i386.rpm And i get the same error: [Fri Dec 13 16:45:25 2002] [notice] child pid 1273 exit signal Segmentation fault (11) [2002-12-13 08:52:40] [EMAIL PROTECTED] I use files as my session handler. Have also tried with mm, but I think the same happens here. [2002-12-13 08:42:34] [EMAIL PROTECTED] Are you using PHP sessions, if so what session handler 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/20985 -- Edit this bug report at http://bugs.php.net/?id=20985&edit=1
#21002 [NEW]: Unaligned Access
From: [EMAIL PROTECTED] Operating system: NetBSD/Alpha (64bit) - 1.6 PHP version: 4CVS-2002-12-13 (stable) PHP Bug Type: Compile Warning Bug description: Unaligned Access Related bug: 20433 (closed) The above bug shouldn't have been closed as the Unaligned Access is still being reported using 12/13 snap. The patch posted in bug 20433 (toward the end) does resolve these issues. Here is the URL again: ftp://codon.genopole-lille.fr/pub/php-4.3.0RC2-stat+onupdateint+zendparam.patch -- Edit bug report at http://bugs.php.net/?id=21002&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21002&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21002&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21002&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21002&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21002&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21002&r=support Expected behavior: http://bugs.php.net/fix.php?id=21002&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21002&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21002&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21002&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21002&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21002&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21002&r=isapi
#21001 [NEW]: After installation of 4.2.3 phpinfo displays 4.2.1
From: [EMAIL PROTECTED] Operating system: WindowXP PHP version: 4.2.3 PHP Bug Type: *General Issues Bug description: After installation of 4.2.3 phpinfo displays 4.2.1 After installing of php-4.2.3-Win32.zip PHPINFO still displays "PHP Version 4.2.1" -- Edit bug report at http://bugs.php.net/?id=21001&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21001&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21001&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21001&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21001&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21001&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21001&r=support Expected behavior: http://bugs.php.net/fix.php?id=21001&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21001&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21001&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21001&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21001&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21001&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21001&r=isapi
#21000 [Fbk->Opn]: can not set register_globals=off
ID: 21000 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: PHP options/info functions Operating System: solaris 8 -PHP Version: 4.3.0RC3 +PHP Version: 4.3.0RC2 New Comment: the php.ini path shows as /opt/sfw/lib/php.ini whihc is the same as /usr/local/lib/php.ini because we have a symbolink link to /usr/local/ in /opt/sfw. Previous Comments: [2002-12-13 16:19:07] [EMAIL PROTECTED] What's the ini path reported in phpinfo()? [2002-12-13 15:30:56] [EMAIL PROTECTED] I was always able to change the register_globals settings in /usr/local/php.ini file (which is a copy of the php.ini-dist) and chenge the setting to on. Now eventhough I have register_globals=On in my php.ini The phpinfo function shows that it is set to Off and as a result non of my php pages are working. -- Edit this bug report at http://bugs.php.net/?id=21000&edit=1
#21000 [Opn->Fbk]: can not set register_globals=off
ID: 21000 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: PHP options/info functions Operating System: solaris 8 PHP Version: 4.3.0RC3 New Comment: What's the ini path reported in phpinfo()? Previous Comments: [2002-12-13 15:30:56] [EMAIL PROTECTED] I was always able to change the register_globals settings in /usr/local/php.ini file (which is a copy of the php.ini-dist) and chenge the setting to on. Now eventhough I have register_globals=On in my php.ini The phpinfo function shows that it is set to Off and as a result non of my php pages are working. -- Edit this bug report at http://bugs.php.net/?id=21000&edit=1
#20997 [Opn->Csd]: ncianca@lightbulb.com
ID: 20997 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: *Configuration Issues Operating System: Mac OSX 10.2.2 Server / DARWIN PHP Version: 4.3.0RC3 New Comment: No need to :) http://bugs.php.net/20751 RC2 was built with autoconf-2.53. RC3 is correct again. Previous Comments: [2002-12-13 15:55:34] [EMAIL PROTECTED] I built php using the "default" OSX configuration, i.e. ./configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-apxs However, upon further examination it does appear that RC3 is working correctly. I will test this more over the weekend. [2002-12-13 14:11:51] [EMAIL PROTECTED] Are you sure this is with the RC3 release? Or did you use the "buildconf" script and have autoconf-2.53 installed? [2002-12-13 13:42:39] [EMAIL PROTECTED] On a MacOSX 10.2 Server the configure command does not seem to find /usr/sbin/sendmail even though it is present. This results in mail() being an undefined function in a built php installation. A work around is to set the environment variable ac_cv_path_PROG_SENDMAIL prior to running configure. # in tcsh setenv ac_cv_path_PROG_SENDMAIL /usr/sbin/sendmail We have had this problem building 4.3.0RC2 and RC3 on several 10.2.2 servers. This didn't appear to be a problem with 4.3.0pre1 -- Edit this bug report at http://bugs.php.net/?id=20997&edit=1
#20997 [Fbk->Opn]: ncianca@lightbulb.com
ID: 20997 User updated by: [EMAIL PROTECTED] -Summary: Sendmail not being enabled in Configure Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: *Configuration Issues Operating System: Mac OSX 10.2.2 Server / DARWIN PHP Version: 4.3.0RC3 New Comment: I built php using the "default" OSX configuration, i.e. ./configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-apxs However, upon further examination it does appear that RC3 is working correctly. I will test this more over the weekend. Previous Comments: [2002-12-13 14:11:51] [EMAIL PROTECTED] Are you sure this is with the RC3 release? Or did you use the "buildconf" script and have autoconf-2.53 installed? [2002-12-13 13:42:39] [EMAIL PROTECTED] On a MacOSX 10.2 Server the configure command does not seem to find /usr/sbin/sendmail even though it is present. This results in mail() being an undefined function in a built php installation. A work around is to set the environment variable ac_cv_path_PROG_SENDMAIL prior to running configure. # in tcsh setenv ac_cv_path_PROG_SENDMAIL /usr/sbin/sendmail We have had this problem building 4.3.0RC2 and RC3 on several 10.2.2 servers. This didn't appear to be a problem with 4.3.0pre1 -- Edit this bug report at http://bugs.php.net/?id=20997&edit=1
#21000 [NEW]: can not set register_globals=off
From: [EMAIL PROTECTED] Operating system: solaris 8 PHP version: 4.3.0RC3 PHP Bug Type: PHP options/info functions Bug description: can not set register_globals=off I was always able to change the register_globals settings in /usr/local/php.ini file (which is a copy of the php.ini-dist) and chenge the setting to on. Now eventhough I have register_globals=On in my php.ini The phpinfo function shows that it is set to Off and as a result non of my php pages are working. -- Edit bug report at http://bugs.php.net/?id=21000&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21000&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21000&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21000&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21000&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21000&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21000&r=support Expected behavior: http://bugs.php.net/fix.php?id=21000&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21000&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21000&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21000&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21000&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21000&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21000&r=isapi
#20995 [Com]: gd.c:1345: structure has no member named `free'
ID: 20995
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: Compile Failure
Operating System: NetBSD/Alpha (64bit) - 1.6
PHP Version: 4CVS-2002-12-13 (stable)
New Comment:
config.nice:
'./configure' \
'--prefix=/usr/local_install/php-4.2.2' \
'--with-config-file-path=/usr/local/etc' \
'--with-gd=shared,/usr/local' \
'--with-curl=shared,/usr/local' \
'--with-system-regex' \
'--with-gettext=shared,/usr/pkg' \
'--with-pgsql=shared,/usr/local' \
'--with-mysql=shared,/usr/pkg' \
'--with-mcrypt=shared,/usr/pkg' \
'--with-pcre-regex' \
'--with-tiff-dir=/usr/pkg' \
'--with-jpeg-dir=/usr/pkg' \
'--with-png-dir=/usr/pkg' \
'--with-xpm-dir' \
'--with-ttf=/usr/pkg' \
'--with-freetype-dir=/usr/pkg' \
'--with-zlib-dir=shared,/usr' \
'--enable-dbase' \
'--enable-gd-native-ttf' \
'--enable-sysvsem' \
'--enable-sysvshm' \
'--enable-sockets' \
'--enable-xml' \
'--enable-trans-sid' \
'--enable-discard-path' \
'--enable-force-cgi-redirect' \
'--enable-memory-limit' \
'--enable-track-vars' \
'--without-t1lib' \
'--disable-static' \
'--enable-shared' \
Also note this snippet from 'configure':
27268 cat > conftest.$ac_ext <
27273 #include
27274
27275 int main() {
27276
27277 gdIOCtx *ctx;
27278 ctx = malloc(sizeof(gdIOCtx));
27279 ctx->gd_free = 1;
27280
27281 ; return 0; }
27282 EOF
---
27272 #include
my 'gd.h' is in '/usr/local/gd.h'. Seems like that include line is only
looking in the system include path. It's not even using the path that
was provided in --with-gd.
Previous Comments:
[2002-12-13 14:59:24] [EMAIL PROTECTED]
what's your configure line? (see config.nice)
[2002-12-13 14:53:22] [EMAIL PROTECTED]
checking config.log revealed:
configure:27284: gcc -c -g -O2 -I/usr/pkg/include conftest.c 1>&5
configure:27272: gd.h: No such file or directory
configure: failed program was:
#line 27270 "configure"
#include "confdefs.h"
#include
#include
int main() {
gdIOCtx *ctx;
ctx = malloc(sizeof(gdIOCtx));
ctx->gd_free = 1;
; return 0; }
seems like it can't find gd.h. very strange.
# locate gd.h
/usr/local/include/gd.h <<-- symlink
/usr/local_install/gd-2.0.7/include/gd.h
/usr/local_src/gd/gd-2.0.7/gd.h
/usr/local_src/php/php-4.2.2/ext/gd/php_gd.h
/usr/local_src/php/php4-STABLE-200212131430/ext/gd/libgd/gd.h
/usr/local_src/php/php4-STABLE-200212131430/ext/gd/php_gd.h
[2002-12-13 13:45:49] [EMAIL PROTECTED]
I just checked, there is only one install of gd-2.0.7 and one gd.h
('locate gd.h' confirmed that).
in /usr/local_src/php/php4-STABLE-200212131430/ext/gd/gd.c:1345:
#if HAVE_LIBGD204
io_ctx->gd_free(io_ctx);
#else
io_ctx->free(io_ctx); <<<-- 1345
#endif
If it's doing line 1345 that means that configured failed to detect
gd-2.0.7 being compatible with gd-2.0.4 to set the proper define.
[2002-12-13 13:25:13] [EMAIL PROTECTED]
I think the error you are seeing is due to your system having more then
one gd library. Old gd versions by default went to /usr, while the new
release go to /usr/local, the result is a header confusion responsible
for the error you are seeing. To confirm this see if you have more then
one copy of gd, by doing 'locate gd.h'.
[2002-12-13 13:22:43] [EMAIL PROTECTED]
I wished when you guys say that the bug was fixed in cvs, you should
supply the date of the cvs version.
In my case, I compiled from cvs snapshot last night. So unless it was
fixed this morning, I don't think it could be fixed in cvs.
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/20995
--
Edit this bug report at http://bugs.php.net/?id=20995&edit=1
#20995 [Fbk]: gd.c:1345: structure has no member named `free'
ID: 20995
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: Compile Failure
Operating System: NetBSD/Alpha (64bit) - 1.6
PHP Version: 4CVS-2002-12-13 (stable)
New Comment:
what's your configure line? (see config.nice)
Previous Comments:
[2002-12-13 14:53:22] [EMAIL PROTECTED]
checking config.log revealed:
configure:27284: gcc -c -g -O2 -I/usr/pkg/include conftest.c 1>&5
configure:27272: gd.h: No such file or directory
configure: failed program was:
#line 27270 "configure"
#include "confdefs.h"
#include
#include
int main() {
gdIOCtx *ctx;
ctx = malloc(sizeof(gdIOCtx));
ctx->gd_free = 1;
; return 0; }
seems like it can't find gd.h. very strange.
# locate gd.h
/usr/local/include/gd.h <<-- symlink
/usr/local_install/gd-2.0.7/include/gd.h
/usr/local_src/gd/gd-2.0.7/gd.h
/usr/local_src/php/php-4.2.2/ext/gd/php_gd.h
/usr/local_src/php/php4-STABLE-200212131430/ext/gd/libgd/gd.h
/usr/local_src/php/php4-STABLE-200212131430/ext/gd/php_gd.h
[2002-12-13 13:45:49] [EMAIL PROTECTED]
I just checked, there is only one install of gd-2.0.7 and one gd.h
('locate gd.h' confirmed that).
in /usr/local_src/php/php4-STABLE-200212131430/ext/gd/gd.c:1345:
#if HAVE_LIBGD204
io_ctx->gd_free(io_ctx);
#else
io_ctx->free(io_ctx); <<<-- 1345
#endif
If it's doing line 1345 that means that configured failed to detect
gd-2.0.7 being compatible with gd-2.0.4 to set the proper define.
[2002-12-13 13:25:13] [EMAIL PROTECTED]
I think the error you are seeing is due to your system having more then
one gd library. Old gd versions by default went to /usr, while the new
release go to /usr/local, the result is a header confusion responsible
for the error you are seeing. To confirm this see if you have more then
one copy of gd, by doing 'locate gd.h'.
[2002-12-13 13:22:43] [EMAIL PROTECTED]
I wished when you guys say that the bug was fixed in cvs, you should
supply the date of the cvs version.
In my case, I compiled from cvs snapshot last night. So unless it was
fixed this morning, I don't think it could be fixed in cvs.
[2002-12-13 13:15:14] [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. Because of this, we hope you add your comments
to the existing bug instead.
Thank you for your interest in PHP.
http://bugs.php.net/20083
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/20995
--
Edit this bug report at http://bugs.php.net/?id=20995&edit=1
#20995 [Com]: gd.c:1345: structure has no member named `free'
ID: 20995
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: Compile Failure
Operating System: NetBSD/Alpha (64bit) - 1.6
PHP Version: 4CVS-2002-12-13 (stable)
New Comment:
checking config.log revealed:
configure:27284: gcc -c -g -O2 -I/usr/pkg/include conftest.c 1>&5
configure:27272: gd.h: No such file or directory
configure: failed program was:
#line 27270 "configure"
#include "confdefs.h"
#include
#include
int main() {
gdIOCtx *ctx;
ctx = malloc(sizeof(gdIOCtx));
ctx->gd_free = 1;
; return 0; }
seems like it can't find gd.h. very strange.
# locate gd.h
/usr/local/include/gd.h <<-- symlink
/usr/local_install/gd-2.0.7/include/gd.h
/usr/local_src/gd/gd-2.0.7/gd.h
/usr/local_src/php/php-4.2.2/ext/gd/php_gd.h
/usr/local_src/php/php4-STABLE-200212131430/ext/gd/libgd/gd.h
/usr/local_src/php/php4-STABLE-200212131430/ext/gd/php_gd.h
Previous Comments:
[2002-12-13 13:45:49] [EMAIL PROTECTED]
I just checked, there is only one install of gd-2.0.7 and one gd.h
('locate gd.h' confirmed that).
in /usr/local_src/php/php4-STABLE-200212131430/ext/gd/gd.c:1345:
#if HAVE_LIBGD204
io_ctx->gd_free(io_ctx);
#else
io_ctx->free(io_ctx); <<<-- 1345
#endif
If it's doing line 1345 that means that configured failed to detect
gd-2.0.7 being compatible with gd-2.0.4 to set the proper define.
[2002-12-13 13:25:13] [EMAIL PROTECTED]
I think the error you are seeing is due to your system having more then
one gd library. Old gd versions by default went to /usr, while the new
release go to /usr/local, the result is a header confusion responsible
for the error you are seeing. To confirm this see if you have more then
one copy of gd, by doing 'locate gd.h'.
[2002-12-13 13:22:43] [EMAIL PROTECTED]
I wished when you guys say that the bug was fixed in cvs, you should
supply the date of the cvs version.
In my case, I compiled from cvs snapshot last night. So unless it was
fixed this morning, I don't think it could be fixed in cvs.
[2002-12-13 13:15:14] [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. Because of this, we hope you add your comments
to the existing bug instead.
Thank you for your interest in PHP.
http://bugs.php.net/20083
[2002-12-13 13:13:12] [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.
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/20995
--
Edit this bug report at http://bugs.php.net/?id=20995&edit=1
#20993 [Ver->Sus]: Element value changes without asking
ID: 20993
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Verified
+Status: Suspended
Bug Type: Variables related
Operating System: Any
PHP Version: 4.0CVS-2002-12-13
New Comment:
This bug has a lot to do with the bug reports mentioned below.
http://bugs.php.net/bug.php?id=6417
http://bugs.php.net/bug.php?id=7412
http://bugs.php.net/bug.php?id=15025
As a workaround, you can write as following to avoid this issue.
function theFunction($array) {
$array = unserialize(serialize($array));
$array[0] = 2;
}
Previous Comments:
[2002-12-13 12:50:26] [EMAIL PROTECTED]
Verified with 4.2.3
[2002-12-13 12:42:22] [EMAIL PROTECTED]
Verified and added testcase to CVS
[2002-12-13 12:01:33] [EMAIL PROTECTED]
I create an array an then a reference to an element of that array.
Then the array is passed to a function (by value!) which changes the
value of the element.
After that, the global array has also another value.
I would expect this behaviour if I passed the array by reference but I
do not.
';
theFunction($array);
echo $array[0], '';
function theFunction($array) {
$array[0] = 2;
}
?>
[2002-12-13 12:00:37] [EMAIL PROTECTED]
I create an array an then a reference to an element of that array.
Then the array is passed to a function (by value!) which changes the
value of the element.
After that, the global array has also another value.
I would expect this behaviour if I passed the array by reference but I
did not.
';
theFunction($array);
echo $array[0], '';
function theFunction($array) {
$array[0] = 2;
}
?>
--
Edit this bug report at http://bugs.php.net/?id=20993&edit=1
#20998 [Opn->Bgs]: Link line too long
ID: 20998 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Compile Failure Operating System: Solaris 2.7 PHP Version: 4.3.0RC3 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. Because of this, we hope you add your comments to the existing bug instead. Thank you for your interest in PHP. http://bugs.php.net/19533 Previous Comments: [2002-12-13 14:29:50] [EMAIL PROTECTED] % ./configure --with-mysql=/opt/mysql --prefix=/opt --with-gdbm --with-ndbm --without-msql --enable-sysvsem --enable-sysvshm --enable-force-cgi-redirect --enable-discard-path --with-ftp --with-gd --with-jpeg-dir=/opt/lib --with-tiff-dir=/opt/lib --with-png-dir=/opt/lib --with-xpm=/opt --with-zlib-dir=/opt/lib --enable-sockets --with-zlib --with-oracle --with-apxs=/opt/web/apache/bin/apxs --enable-discard-path % apxs -q CFLAGS -DSOLARIS2=270 -DMOD_SSL=206106 -I/opt/src/apache_build/php-4.0.4 -I/opt/src/apache_build/php-4.0.4/main -I/opt/src/apache_build/php-4.0.4/main -I/opt/src/apache_build/php-4.0.4/Zend -I/opt/src/apache_build/php-4.0.4/Zend -I/opt/src/apache_build/php-4.0.4/TSRM -I/opt/src/apache_build/php-4.0.4/TSRM -I/opt/src/apache_build/php-4.0.4 -DMOD_PERL -DUSE_PERL_SSI -I/opt/src/apache_build/mod_perl-1.24_01/src -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DEAPI -DUSE_EXPAT -I../lib/expat-lite Apache 1.3.12 Problem: at the conclusion of all the compilation, the link line comes out too long. libtool blows up with: Output line too long. Output line too long. Output line too long. The link line is not linking in libraries, but instead links in every object file on the final link line. Maybe it was libgd that did it? (I tried to configure against the gd 2.0.9 installed on my system, but that does not have gdImageCreateFromXpm in it.) Anyway, I will go back to 4.2 to get my users up and running with gd, but I am assuming this should be fixed at some point. I can try to repair it, but I would have to understand how you have structured your build environment now, and is probably easier for a maintainer to fix it. Thanks very much. -- Edit this bug report at http://bugs.php.net/?id=20998&edit=1
#20998 [NEW]: Link line too long
From: [EMAIL PROTECTED] Operating system: Solaris 2.7 PHP version: 4.3.0RC3 PHP Bug Type: Compile Failure Bug description: Link line too long % ./configure --with-mysql=/opt/mysql --prefix=/opt --with-gdbm --with-ndbm --without-msql --enable-sysvsem --enable-sysvshm --enable-force-cgi-redirect --enable-discard-path --with-ftp --with-gd --with-jpeg-dir=/opt/lib --with-tiff-dir=/opt/lib --with-png-dir=/opt/lib --with-xpm=/opt --with-zlib-dir=/opt/lib --enable-sockets --with-zlib --with-oracle --with-apxs=/opt/web/apache/bin/apxs --enable-discard-path % apxs -q CFLAGS -DSOLARIS2=270 -DMOD_SSL=206106 -I/opt/src/apache_build/php-4.0.4 -I/opt/src/apache_build/php-4.0.4/main -I/opt/src/apache_build/php-4.0.4/main -I/opt/src/apache_build/php-4.0.4/Zend -I/opt/src/apache_build/php-4.0.4/Zend -I/opt/src/apache_build/php-4.0.4/TSRM -I/opt/src/apache_build/php-4.0.4/TSRM -I/opt/src/apache_build/php-4.0.4 -DMOD_PERL -DUSE_PERL_SSI -I/opt/src/apache_build/mod_perl-1.24_01/src -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DEAPI -DUSE_EXPAT -I../lib/expat-lite Apache 1.3.12 Problem: at the conclusion of all the compilation, the link line comes out too long. libtool blows up with: Output line too long. Output line too long. Output line too long. The link line is not linking in libraries, but instead links in every object file on the final link line. Maybe it was libgd that did it? (I tried to configure against the gd 2.0.9 installed on my system, but that does not have gdImageCreateFromXpm in it.) Anyway, I will go back to 4.2 to get my users up and running with gd, but I am assuming this should be fixed at some point. I can try to repair it, but I would have to understand how you have structured your build environment now, and is probably easier for a maintainer to fix it. Thanks very much. -- Edit bug report at http://bugs.php.net/?id=20998&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20998&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20998&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20998&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20998&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20998&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20998&r=support Expected behavior: http://bugs.php.net/fix.php?id=20998&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20998&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20998&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20998&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20998&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20998&r=dst IIS Stability: http://bugs.php.net/fix.php?id=20998&r=isapi
#20997 [Opn->Fbk]: Sendmail not being enabled in Configure
ID: 20997 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: *Configuration Issues Operating System: Mac OSX 10.2.2 Server / DARWIN PHP Version: 4.3.0RC3 New Comment: Are you sure this is with the RC3 release? Or did you use the "buildconf" script and have autoconf-2.53 installed? Previous Comments: [2002-12-13 13:42:39] [EMAIL PROTECTED] On a MacOSX 10.2 Server the configure command does not seem to find /usr/sbin/sendmail even though it is present. This results in mail() being an undefined function in a built php installation. A work around is to set the environment variable ac_cv_path_PROG_SENDMAIL prior to running configure. # in tcsh setenv ac_cv_path_PROG_SENDMAIL /usr/sbin/sendmail We have had this problem building 4.3.0RC2 and RC3 on several 10.2.2 servers. This didn't appear to be a problem with 4.3.0pre1 -- Edit this bug report at http://bugs.php.net/?id=20997&edit=1
#20995 [Com]: gd.c:1345: structure has no member named `free'
ID: 20995
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: Compile Failure
Operating System: NetBSD/Alpha (64bit) - 1.6
PHP Version: 4CVS-2002-12-13 (stable)
New Comment:
I just checked, there is only one install of gd-2.0.7 and one gd.h
('locate gd.h' confirmed that).
in /usr/local_src/php/php4-STABLE-200212131430/ext/gd/gd.c:1345:
#if HAVE_LIBGD204
io_ctx->gd_free(io_ctx);
#else
io_ctx->free(io_ctx); <<<-- 1345
#endif
If it's doing line 1345 that means that configured failed to detect
gd-2.0.7 being compatible with gd-2.0.4 to set the proper define.
Previous Comments:
[2002-12-13 13:25:13] [EMAIL PROTECTED]
I think the error you are seeing is due to your system having more then
one gd library. Old gd versions by default went to /usr, while the new
release go to /usr/local, the result is a header confusion responsible
for the error you are seeing. To confirm this see if you have more then
one copy of gd, by doing 'locate gd.h'.
[2002-12-13 13:22:43] [EMAIL PROTECTED]
I wished when you guys say that the bug was fixed in cvs, you should
supply the date of the cvs version.
In my case, I compiled from cvs snapshot last night. So unless it was
fixed this morning, I don't think it could be fixed in cvs.
[2002-12-13 13:15:14] [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. Because of this, we hope you add your comments
to the existing bug instead.
Thank you for your interest in PHP.
http://bugs.php.net/20083
[2002-12-13 13:13:12] [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.
[2002-12-13 13:00:48] [EMAIL PROTECTED]
/bin/sh libtool --silent --mode=compile gcc -I/usr/local/include
-Iext/gd/ -I/usr/local_src
/php/php4-STABLE-200212131430/ext/gd/ -DPHP_ATOM_INC
-I/usr/local_src/php/php4-STABLE-20021
2131430/include -I/usr/local_src/php/php4-STABLE-200212131430/main
-I/usr/local_src/php/php
4-STABLE-200212131430
-I/usr/local_src/php/php4-STABLE-200212131430/Zend -I/usr/local/inclu
de -I/usr/pkg/include -I/usr/X11R6/include -I/usr/pkg/include/freetype2
-I/usr/pkg/include/
mysql -I/usr/local_src/php/php4-STABLE-200212131430/ext/xml/expat
-I/usr/pkg/include -I/us
r/local_src/php/php4-STABLE-200212131430/TSRM -g -O2 -prefer-pic -c
/usr/local_src/php/ph
p4-STABLE-200212131430/ext/gd/gd.c -o ext/gd/gd.lo
In file included from
/usr/local_src/php/php4-STABLE-200212131430/ext/gd/gd.c:89:
/usr/local_src/php/php4-STABLE-200212131430/ext/gd/gd_ctx.c: In
function `_php_image_output
_ctx':
/usr/local_src/php/php4-STABLE-200212131430/ext/gd/gd_ctx.c:73:
structure has no member nam
ed `free'
/usr/local_src/php/php4-STABLE-200212131430/ext/gd/gd_ctx.c:105:
structure has no member na
med `free'
/usr/local_src/php/php4-STABLE-200212131430/ext/gd/gd.c: In function
`_php_image_type':
/usr/local_src/php/php4-STABLE-200212131430/ext/gd/gd.c:1156: structure
has no member named
`free'
/usr/local_src/php/php4-STABLE-200212131430/ext/gd/gd.c:1163: structure
has no member named
`free'
/usr/local_src/php/php4-STABLE-200212131430/ext/gd/gd.c: In function
`_php_image_create_fro
m':
/usr/local_src/php/php4-STABLE-200212131430/ext/gd/gd.c:1345: structure
has no member named
`free'
gmake: *** [ext/gd/gd.lo] Error 1
---
I'm using gd-2.0.7
--
Edit this bug report at http://bugs.php.net/?id=20995&edit=1
#20997 [NEW]: Sendmail not being enabled in Configure
From: [EMAIL PROTECTED] Operating system: Mac OSX 10.2.2 Server / DARWIN PHP version: 4.3.0RC3 PHP Bug Type: *Configuration Issues Bug description: Sendmail not being enabled in Configure On a MacOSX 10.2 Server the configure command does not seem to find /usr/sbin/sendmail even though it is present. This results in mail() being an undefined function in a built php installation. A work around is to set the environment variable ac_cv_path_PROG_SENDMAIL prior to running configure. # in tcsh setenv ac_cv_path_PROG_SENDMAIL /usr/sbin/sendmail We have had this problem building 4.3.0RC2 and RC3 on several 10.2.2 servers. This didn't appear to be a problem with 4.3.0pre1 -- Edit bug report at http://bugs.php.net/?id=20997&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20997&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20997&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20997&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20997&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20997&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20997&r=support Expected behavior: http://bugs.php.net/fix.php?id=20997&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20997&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20997&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20997&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20997&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20997&r=dst IIS Stability: http://bugs.php.net/fix.php?id=20997&r=isapi
#20995 [Opn->Fbk]: gd.c:1345: structure has no member named `free'
ID: 20995 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Compile Failure Operating System: NetBSD/Alpha (64bit) - 1.6 PHP Version: 4CVS-2002-12-13 (stable) New Comment: I think the error you are seeing is due to your system having more then one gd library. Old gd versions by default went to /usr, while the new release go to /usr/local, the result is a header confusion responsible for the error you are seeing. To confirm this see if you have more then one copy of gd, by doing 'locate gd.h'. Previous Comments: [2002-12-13 13:22:43] [EMAIL PROTECTED] I wished when you guys say that the bug was fixed in cvs, you should supply the date of the cvs version. In my case, I compiled from cvs snapshot last night. So unless it was fixed this morning, I don't think it could be fixed in cvs. [2002-12-13 13:15:14] [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. Because of this, we hope you add your comments to the existing bug instead. Thank you for your interest in PHP. http://bugs.php.net/20083 [2002-12-13 13:13:12] [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. [2002-12-13 13:00:48] [EMAIL PROTECTED] /bin/sh libtool --silent --mode=compile gcc -I/usr/local/include -Iext/gd/ -I/usr/local_src /php/php4-STABLE-200212131430/ext/gd/ -DPHP_ATOM_INC -I/usr/local_src/php/php4-STABLE-20021 2131430/include -I/usr/local_src/php/php4-STABLE-200212131430/main -I/usr/local_src/php/php 4-STABLE-200212131430 -I/usr/local_src/php/php4-STABLE-200212131430/Zend -I/usr/local/inclu de -I/usr/pkg/include -I/usr/X11R6/include -I/usr/pkg/include/freetype2 -I/usr/pkg/include/ mysql -I/usr/local_src/php/php4-STABLE-200212131430/ext/xml/expat -I/usr/pkg/include -I/us r/local_src/php/php4-STABLE-200212131430/TSRM -g -O2 -prefer-pic -c /usr/local_src/php/ph p4-STABLE-200212131430/ext/gd/gd.c -o ext/gd/gd.lo In file included from /usr/local_src/php/php4-STABLE-200212131430/ext/gd/gd.c:89: /usr/local_src/php/php4-STABLE-200212131430/ext/gd/gd_ctx.c: In function `_php_image_output _ctx': /usr/local_src/php/php4-STABLE-200212131430/ext/gd/gd_ctx.c:73: structure has no member nam ed `free' /usr/local_src/php/php4-STABLE-200212131430/ext/gd/gd_ctx.c:105: structure has no member na med `free' /usr/local_src/php/php4-STABLE-200212131430/ext/gd/gd.c: In function `_php_image_type': /usr/local_src/php/php4-STABLE-200212131430/ext/gd/gd.c:1156: structure has no member named `free' /usr/local_src/php/php4-STABLE-200212131430/ext/gd/gd.c:1163: structure has no member named `free' /usr/local_src/php/php4-STABLE-200212131430/ext/gd/gd.c: In function `_php_image_create_fro m': /usr/local_src/php/php4-STABLE-200212131430/ext/gd/gd.c:1345: structure has no member named `free' gmake: *** [ext/gd/gd.lo] Error 1 --- I'm using gd-2.0.7 -- Edit this bug report at http://bugs.php.net/?id=20995&edit=1
#20995 [Bgs->Opn]: gd.c:1345: structure has no member named `free'
ID: 20995 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Bogus +Status: Open Bug Type: Compile Failure Operating System: NetBSD/Alpha (64bit) - 1.6 PHP Version: 4CVS-2002-12-13 (stable) New Comment: I wished when you guys say that the bug was fixed in cvs, you should supply the date of the cvs version. In my case, I compiled from cvs snapshot last night. So unless it was fixed this morning, I don't think it could be fixed in cvs. Previous Comments: [2002-12-13 13:15:14] [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. Because of this, we hope you add your comments to the existing bug instead. Thank you for your interest in PHP. http://bugs.php.net/20083 [2002-12-13 13:13:12] [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. [2002-12-13 13:00:48] [EMAIL PROTECTED] /bin/sh libtool --silent --mode=compile gcc -I/usr/local/include -Iext/gd/ -I/usr/local_src /php/php4-STABLE-200212131430/ext/gd/ -DPHP_ATOM_INC -I/usr/local_src/php/php4-STABLE-20021 2131430/include -I/usr/local_src/php/php4-STABLE-200212131430/main -I/usr/local_src/php/php 4-STABLE-200212131430 -I/usr/local_src/php/php4-STABLE-200212131430/Zend -I/usr/local/inclu de -I/usr/pkg/include -I/usr/X11R6/include -I/usr/pkg/include/freetype2 -I/usr/pkg/include/ mysql -I/usr/local_src/php/php4-STABLE-200212131430/ext/xml/expat -I/usr/pkg/include -I/us r/local_src/php/php4-STABLE-200212131430/TSRM -g -O2 -prefer-pic -c /usr/local_src/php/ph p4-STABLE-200212131430/ext/gd/gd.c -o ext/gd/gd.lo In file included from /usr/local_src/php/php4-STABLE-200212131430/ext/gd/gd.c:89: /usr/local_src/php/php4-STABLE-200212131430/ext/gd/gd_ctx.c: In function `_php_image_output _ctx': /usr/local_src/php/php4-STABLE-200212131430/ext/gd/gd_ctx.c:73: structure has no member nam ed `free' /usr/local_src/php/php4-STABLE-200212131430/ext/gd/gd_ctx.c:105: structure has no member na med `free' /usr/local_src/php/php4-STABLE-200212131430/ext/gd/gd.c: In function `_php_image_type': /usr/local_src/php/php4-STABLE-200212131430/ext/gd/gd.c:1156: structure has no member named `free' /usr/local_src/php/php4-STABLE-200212131430/ext/gd/gd.c:1163: structure has no member named `free' /usr/local_src/php/php4-STABLE-200212131430/ext/gd/gd.c: In function `_php_image_create_fro m': /usr/local_src/php/php4-STABLE-200212131430/ext/gd/gd.c:1345: structure has no member named `free' gmake: *** [ext/gd/gd.lo] Error 1 --- I'm using gd-2.0.7 -- Edit this bug report at http://bugs.php.net/?id=20995&edit=1
#20995 [Csd->Bgs]: gd.c:1345: structure has no member named `free'
ID: 20995 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Closed +Status: Bogus Bug Type: Compile Failure Operating System: NetBSD/Alpha (64bit) - 1.6 PHP Version: 4CVS-2002-12-13 (stable) 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. Because of this, we hope you add your comments to the existing bug instead. Thank you for your interest in PHP. http://bugs.php.net/20083 Previous Comments: [2002-12-13 13:13:12] [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. [2002-12-13 13:00:48] [EMAIL PROTECTED] /bin/sh libtool --silent --mode=compile gcc -I/usr/local/include -Iext/gd/ -I/usr/local_src /php/php4-STABLE-200212131430/ext/gd/ -DPHP_ATOM_INC -I/usr/local_src/php/php4-STABLE-20021 2131430/include -I/usr/local_src/php/php4-STABLE-200212131430/main -I/usr/local_src/php/php 4-STABLE-200212131430 -I/usr/local_src/php/php4-STABLE-200212131430/Zend -I/usr/local/inclu de -I/usr/pkg/include -I/usr/X11R6/include -I/usr/pkg/include/freetype2 -I/usr/pkg/include/ mysql -I/usr/local_src/php/php4-STABLE-200212131430/ext/xml/expat -I/usr/pkg/include -I/us r/local_src/php/php4-STABLE-200212131430/TSRM -g -O2 -prefer-pic -c /usr/local_src/php/ph p4-STABLE-200212131430/ext/gd/gd.c -o ext/gd/gd.lo In file included from /usr/local_src/php/php4-STABLE-200212131430/ext/gd/gd.c:89: /usr/local_src/php/php4-STABLE-200212131430/ext/gd/gd_ctx.c: In function `_php_image_output _ctx': /usr/local_src/php/php4-STABLE-200212131430/ext/gd/gd_ctx.c:73: structure has no member nam ed `free' /usr/local_src/php/php4-STABLE-200212131430/ext/gd/gd_ctx.c:105: structure has no member na med `free' /usr/local_src/php/php4-STABLE-200212131430/ext/gd/gd.c: In function `_php_image_type': /usr/local_src/php/php4-STABLE-200212131430/ext/gd/gd.c:1156: structure has no member named `free' /usr/local_src/php/php4-STABLE-200212131430/ext/gd/gd.c:1163: structure has no member named `free' /usr/local_src/php/php4-STABLE-200212131430/ext/gd/gd.c: In function `_php_image_create_fro m': /usr/local_src/php/php4-STABLE-200212131430/ext/gd/gd.c:1345: structure has no member named `free' gmake: *** [ext/gd/gd.lo] Error 1 --- I'm using gd-2.0.7 -- Edit this bug report at http://bugs.php.net/?id=20995&edit=1
#20995 [Opn->Csd]: gd.c:1345: structure has no member named `free'
ID: 20995 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Compile Failure Operating System: NetBSD/Alpha (64bit) - 1.6 PHP Version: 4CVS-2002-12-13 (stable) New Comment: 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. Previous Comments: [2002-12-13 13:00:48] [EMAIL PROTECTED] /bin/sh libtool --silent --mode=compile gcc -I/usr/local/include -Iext/gd/ -I/usr/local_src /php/php4-STABLE-200212131430/ext/gd/ -DPHP_ATOM_INC -I/usr/local_src/php/php4-STABLE-20021 2131430/include -I/usr/local_src/php/php4-STABLE-200212131430/main -I/usr/local_src/php/php 4-STABLE-200212131430 -I/usr/local_src/php/php4-STABLE-200212131430/Zend -I/usr/local/inclu de -I/usr/pkg/include -I/usr/X11R6/include -I/usr/pkg/include/freetype2 -I/usr/pkg/include/ mysql -I/usr/local_src/php/php4-STABLE-200212131430/ext/xml/expat -I/usr/pkg/include -I/us r/local_src/php/php4-STABLE-200212131430/TSRM -g -O2 -prefer-pic -c /usr/local_src/php/ph p4-STABLE-200212131430/ext/gd/gd.c -o ext/gd/gd.lo In file included from /usr/local_src/php/php4-STABLE-200212131430/ext/gd/gd.c:89: /usr/local_src/php/php4-STABLE-200212131430/ext/gd/gd_ctx.c: In function `_php_image_output _ctx': /usr/local_src/php/php4-STABLE-200212131430/ext/gd/gd_ctx.c:73: structure has no member nam ed `free' /usr/local_src/php/php4-STABLE-200212131430/ext/gd/gd_ctx.c:105: structure has no member na med `free' /usr/local_src/php/php4-STABLE-200212131430/ext/gd/gd.c: In function `_php_image_type': /usr/local_src/php/php4-STABLE-200212131430/ext/gd/gd.c:1156: structure has no member named `free' /usr/local_src/php/php4-STABLE-200212131430/ext/gd/gd.c:1163: structure has no member named `free' /usr/local_src/php/php4-STABLE-200212131430/ext/gd/gd.c: In function `_php_image_create_fro m': /usr/local_src/php/php4-STABLE-200212131430/ext/gd/gd.c:1345: structure has no member named `free' gmake: *** [ext/gd/gd.lo] Error 1 --- I'm using gd-2.0.7 -- Edit this bug report at http://bugs.php.net/?id=20995&edit=1
#20996 [Opn->Bgs]: unserting from a for
ID: 20996
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Bogus
Bug Type: *Database Functions
Operating System: win 2k pro
PHP Version: 4.2.3
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
Previous Comments:
[2002-12-13 13:04:32] [EMAIL PROTECTED]
this is what i'm doing:
for ($i=0; $i<$howmany; $i++){
// Insertar Datos
$premio[$i] = $form_data['premio[$i]'];
$description[$i] = $form_data['description[$i]'];
$bil[$i] = $form_data['bil[$i]'];
$myquery[$i] = "INSERT INTO PREMIO ( premio, description, bil)
VALUES ('$premio[$i]', '$description[$i]', '$bil[$i]')";
$result = mysql_query($myquery[$i], $mysql);
if (!$result) {
$error[$i] = "No se logro realizar la inserción";
return ($error[$i]);
}
}
it does the insert but whitout the data, empty;
what am i doing wrong
--
Edit this bug report at http://bugs.php.net/?id=20996&edit=1
#20996 [NEW]: unserting from a for
From: [EMAIL PROTECTED]
Operating system: win 2k pro
PHP version: 4.2.3
PHP Bug Type: *Database Functions
Bug description: unserting from a for
this is what i'm doing:
for ($i=0; $i<$howmany; $i++){
// Insertar Datos
$premio[$i] = $form_data['premio[$i]'];
$description[$i] = $form_data['description[$i]'];
$bil[$i] = $form_data['bil[$i]'];
$myquery[$i] = "INSERT INTO PREMIO ( premio, description, bil)
VALUES
('$premio[$i]', '$description[$i]', '$bil[$i]')";
$result = mysql_query($myquery[$i], $mysql);
if (!$result) {
$error[$i] = "No se logro realizar la inserción";
return ($error[$i]);
}
}
it does the insert but whitout the data, empty;
what am i doing wrong
--
Edit bug report at http://bugs.php.net/?id=20996&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=20996&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=20996&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=20996&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=20996&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=20996&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=20996&r=support
Expected behavior: http://bugs.php.net/fix.php?id=20996&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=20996&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=20996&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=20996&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20996&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=20996&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=20996&r=isapi
#20995 [NEW]: gd.c:1345: structure has no member named `free'
From: [EMAIL PROTECTED] Operating system: NetBSD/Alpha (64bit) - 1.6 PHP version: 4CVS-2002-12-13 (stable) PHP Bug Type: Compile Failure Bug description: gd.c:1345: structure has no member named `free' /bin/sh libtool --silent --mode=compile gcc -I/usr/local/include -Iext/gd/ -I/usr/local_src /php/php4-STABLE-200212131430/ext/gd/ -DPHP_ATOM_INC -I/usr/local_src/php/php4-STABLE-20021 2131430/include -I/usr/local_src/php/php4-STABLE-200212131430/main -I/usr/local_src/php/php 4-STABLE-200212131430 -I/usr/local_src/php/php4-STABLE-200212131430/Zend -I/usr/local/inclu de -I/usr/pkg/include -I/usr/X11R6/include -I/usr/pkg/include/freetype2 -I/usr/pkg/include/ mysql -I/usr/local_src/php/php4-STABLE-200212131430/ext/xml/expat -I/usr/pkg/include -I/us r/local_src/php/php4-STABLE-200212131430/TSRM -g -O2 -prefer-pic -c /usr/local_src/php/ph p4-STABLE-200212131430/ext/gd/gd.c -o ext/gd/gd.lo In file included from /usr/local_src/php/php4-STABLE-200212131430/ext/gd/gd.c:89: /usr/local_src/php/php4-STABLE-200212131430/ext/gd/gd_ctx.c: In function `_php_image_output _ctx': /usr/local_src/php/php4-STABLE-200212131430/ext/gd/gd_ctx.c:73: structure has no member nam ed `free' /usr/local_src/php/php4-STABLE-200212131430/ext/gd/gd_ctx.c:105: structure has no member na med `free' /usr/local_src/php/php4-STABLE-200212131430/ext/gd/gd.c: In function `_php_image_type': /usr/local_src/php/php4-STABLE-200212131430/ext/gd/gd.c:1156: structure has no member named `free' /usr/local_src/php/php4-STABLE-200212131430/ext/gd/gd.c:1163: structure has no member named `free' /usr/local_src/php/php4-STABLE-200212131430/ext/gd/gd.c: In function `_php_image_create_fro m': /usr/local_src/php/php4-STABLE-200212131430/ext/gd/gd.c:1345: structure has no member named `free' gmake: *** [ext/gd/gd.lo] Error 1 --- I'm using gd-2.0.7 -- Edit bug report at http://bugs.php.net/?id=20995&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20995&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20995&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20995&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20995&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20995&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20995&r=support Expected behavior: http://bugs.php.net/fix.php?id=20995&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20995&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20995&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20995&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20995&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20995&r=dst IIS Stability: http://bugs.php.net/fix.php?id=20995&r=isapi
#20993 [Ver]: Element value changes without asking
ID: 20993
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Verified
Bug Type: Variables related
Operating System: Any
PHP Version: 4.0CVS-2002-12-13
New Comment:
Verified with 4.2.3
Previous Comments:
[2002-12-13 12:42:22] [EMAIL PROTECTED]
Verified and added testcase to CVS
[2002-12-13 12:01:33] [EMAIL PROTECTED]
I create an array an then a reference to an element of that array.
Then the array is passed to a function (by value!) which changes the
value of the element.
After that, the global array has also another value.
I would expect this behaviour if I passed the array by reference but I
do not.
';
theFunction($array);
echo $array[0], '';
function theFunction($array) {
$array[0] = 2;
}
?>
[2002-12-13 12:00:37] [EMAIL PROTECTED]
I create an array an then a reference to an element of that array.
Then the array is passed to a function (by value!) which changes the
value of the element.
After that, the global array has also another value.
I would expect this behaviour if I passed the array by reference but I
did not.
';
theFunction($array);
echo $array[0], '';
function theFunction($array) {
$array[0] = 2;
}
?>
--
Edit this bug report at http://bugs.php.net/?id=20993&edit=1
#20993 [Opn->Ver]: Element value changes without asking
ID: 20993
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Verified
Bug Type: Variables related
-Operating System: Windows 2002
+Operating System: Any
-PHP Version: 4.3.0RC3
+PHP Version: 4.0CVS-2002-12-13
New Comment:
Verified and added testcase to CVS
Previous Comments:
[2002-12-13 12:01:33] [EMAIL PROTECTED]
I create an array an then a reference to an element of that array.
Then the array is passed to a function (by value!) which changes the
value of the element.
After that, the global array has also another value.
I would expect this behaviour if I passed the array by reference but I
do not.
';
theFunction($array);
echo $array[0], '';
function theFunction($array) {
$array[0] = 2;
}
?>
[2002-12-13 12:00:37] [EMAIL PROTECTED]
I create an array an then a reference to an element of that array.
Then the array is passed to a function (by value!) which changes the
value of the element.
After that, the global array has also another value.
I would expect this behaviour if I passed the array by reference but I
did not.
';
theFunction($array);
echo $array[0], '';
function theFunction($array) {
$array[0] = 2;
}
?>
--
Edit this bug report at http://bugs.php.net/?id=20993&edit=1
#20994 [NEW]: int/long confusion in 64bits machine
From: [EMAIL PROTECTED] Operating system: Tru64 PHP version: 4.3.0RC3 PHP Bug Type: Reproducible crash Bug description: int/long confusion in 64bits machine There are locations in source where variables are declared int or long and are menipulated with long or int pointer respectively. - The function "OnUpdateInt" use long pointer (the case is already referenced in bug#20433 but I found more variables concerned). - In function "zend_parse_parameters()", the variable for token "l" should be a long and the 2nd variable for token "s" should be a int. The patch above try to fix the 2 cases : ftp://codon.genopole-lille.fr/pub/php-4.3.0RC2-onupdateint+zendparam.patch -- Julien -- Edit bug report at http://bugs.php.net/?id=20994&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20994&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20994&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20994&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20994&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20994&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20994&r=support Expected behavior: http://bugs.php.net/fix.php?id=20994&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20994&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20994&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20994&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20994&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20994&r=dst IIS Stability: http://bugs.php.net/fix.php?id=20994&r=isapi
#20993 [Opn]: Element value changes without asking
ID: 20993
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Variables related
Operating System: Windows 2002
PHP Version: 4.3.0RC3
New Comment:
I create an array an then a reference to an element of that array.
Then the array is passed to a function (by value!) which changes the
value of the element.
After that, the global array has also another value.
I would expect this behaviour if I passed the array by reference but I
do not.
';
theFunction($array);
echo $array[0], '';
function theFunction($array) {
$array[0] = 2;
}
?>
Previous Comments:
[2002-12-13 12:00:37] [EMAIL PROTECTED]
I create an array an then a reference to an element of that array.
Then the array is passed to a function (by value!) which changes the
value of the element.
After that, the global array has also another value.
I would expect this behaviour if I passed the array by reference but I
did not.
';
theFunction($array);
echo $array[0], '';
function theFunction($array) {
$array[0] = 2;
}
?>
--
Edit this bug report at http://bugs.php.net/?id=20993&edit=1
#20993 [NEW]: Element value changes without asking
From: [EMAIL PROTECTED]
Operating system: Windows 2002
PHP version: 4.3.0RC3
PHP Bug Type: Variables related
Bug description: Element value changes without asking
I create an array an then a reference to an element of that array.
Then the array is passed to a function (by value!) which changes the value
of the element.
After that, the global array has also another value.
I would expect this behaviour if I passed the array by reference but I did
not.
';
theFunction($array);
echo $array[0], '';
function theFunction($array) {
$array[0] = 2;
}
?>
--
Edit bug report at http://bugs.php.net/?id=20993&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=20993&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=20993&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=20993&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=20993&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=20993&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=20993&r=support
Expected behavior: http://bugs.php.net/fix.php?id=20993&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=20993&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=20993&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=20993&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20993&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=20993&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=20993&r=isapi
#20768 [WFx->]: MySql temp file error
ID: 20768 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Won\'t fix Bug Type: Compile Failure Operating System: Debian 3.0 Stable / Sparc PHP Version: 4.3.0RC2 New Comment: does it stop the build or is it the last warning IN the build? If it says "warning", there is no problem. Gcc 3.0x used to signal it as an error and was quickly corrected. I hope you're not saying it's status is back to "error" again, cause that would "not be very nice". It's not a PHP problem either, when the gcc people decide to classify a "MAY be used unsafe" statement, as an error. Previous Comments: [2002-12-13 10:39:23] [EMAIL PROTECTED] it may be a warning, and not an error, but it sure brings my build to a halt every time -- i'm not gcc genius, but how should we get around this? I'm using gcc 3.2.1, libtool 1.4.3, btw. [2002-12-02 13:26:55] [EMAIL PROTECTED] It's a warning, not an error. [2002-12-02 13:25:30] [EMAIL PROTECTED] It may be safe, but it stops the compile. I can't build with the code as is. [2002-12-02 13:23:31] [EMAIL PROTECTED] It's harmless; just ignore it. The MySQL library uses it in a safe way anyway. Derick [2002-12-02 13:19:49] [EMAIL PROTECTED] When building 4.3.0RC2 against apache 1.3.26 DSO I get an error stating that usage of tempnam() is insecure - line 103 of ext/mysql/libmysql/my_tempnam.c I replaced line 103 with the following code, which builds and should function identically. /* filespec will be dir + '/' + pfx + 'XX' + null */ res = malloc(strlen(dir) + strlen(pfx) + 8); res[0] = '\0'; strcat(res, dir); strcat(res, "/"); strcat(res, pfx); strcat(res, "XX"); mkstemp(res); /* res=tempnam((char *)dir, (my_string) pfx); */ Someone who knows the mysql code should check this if it's not a local build problem on my end. Other details: Linux Kernel 2.4.18 / sparc64 libc6 2.2.5-11.2 gcc 2.95.4 20011002 (Debian prerelease) ./configure --with-mysql --with-apxs --prefix=/usr --sysconfdir=/etc --localstatedir=/var/php --with-zlib --with-dom --with-gd --with-mysql --enable-sockets --with-jpeg-dir=/usr/lib --with-png-dir=/usr/lib --with-xpm-dir=/usr/X11R6/lib --with-freetype-dir=/usr/lib -- Edit this bug report at http://bugs.php.net/?id=20768&edit=1
#20992 [Opn->Bgs]: the use of `tempnam' is dangerous, better use `mkstemp'
ID: 20992 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Compile Failure Operating System: Gentoo Linux PHP Version: 4.3.0RC3 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. Because of this, we hope you add your comments to the existing bug instead. Thank you for your interest in PHP. Previous Comments: [2002-12-13 11:53:52] [EMAIL PROTECTED] [Processor: Intel PII 450Mhz] Php4.3.0RC3 configured just fine with the following config string: ./configure --with-apxs=/usr/local/apache/bin/apxs --enable-gd --with-png-dir=/usr/local --with-zlib-dir=/usr/local --with-mysql When I did 'make', however, It exited out with the following text: -lcrypt -lresolv -lm -ldl -lnsl -lcrypt -o sapi/cli/php ext/mysql/libmysql/my_tempnam.lo: In function `my_tempnam': /usr/local/src/php-4.3.0RC3/ext/mysql/libmysql/my_tempnam.c:103: the use of `tempnam' is dangerous, better use `mkstemp' The version of mysql I am using is mysql-3.23.49. -- Edit this bug report at http://bugs.php.net/?id=20992&edit=1
#20992 [NEW]: the use of `tempnam' is dangerous, better use `mkstemp'
From: [EMAIL PROTECTED] Operating system: Gentoo Linux PHP version: 4.3.0RC3 PHP Bug Type: Compile Failure Bug description: the use of `tempnam' is dangerous, better use `mkstemp' [Processor: Intel PII 450Mhz] Php4.3.0RC3 configured just fine with the following config string: ./configure --with-apxs=/usr/local/apache/bin/apxs --enable-gd --with-png-dir=/usr/local --with-zlib-dir=/usr/local --with-mysql When I did 'make', however, It exited out with the following text: -lcrypt -lresolv -lm -ldl -lnsl -lcrypt -o sapi/cli/php ext/mysql/libmysql/my_tempnam.lo: In function `my_tempnam': /usr/local/src/php-4.3.0RC3/ext/mysql/libmysql/my_tempnam.c:103: the use of `tempnam' is dangerous, better use `mkstemp' The version of mysql I am using is mysql-3.23.49. -- Edit bug report at http://bugs.php.net/?id=20992&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20992&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20992&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20992&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20992&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20992&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20992&r=support Expected behavior: http://bugs.php.net/fix.php?id=20992&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20992&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20992&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20992&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20992&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20992&r=dst IIS Stability: http://bugs.php.net/fix.php?id=20992&r=isapi
#20540 [Bgs]: PHP do not read PHP.INI
ID: 20540 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: PHP options/info functions Operating System: Windows XP Pro PHP Version: 4.2.0 New Comment: This really is bogus, please read the findings found at: http://bugs.php.net/bug.php?id=20753 It has to do with your windows settings, not PHP. If another person can confirm the findings in #20753 then this windows feature/bug will be documented as a . Previous Comments: [2002-12-13 02:33:17] [EMAIL PROTECTED] Hi Guys, I'm happy to see I'm not alone, and too much stupid :-) I found 2 workarounds that can work for you (I hope) 1) With Apache : I put php.ini in Apache Directory, I've deleted the one in ../system32/ I don't know why but... it worked... 2) Other solution : I have installed the Php version 4.3 RC0 These 2 solutions worked fine for me, hope this will help you as well Sincerely, Jean-Frederic [2002-12-12 20:01:01] [EMAIL PROTECTED] i am having the exact problem with my php.ini settings under winxp pro w/iis ... the ini_set function does work to fix it but i really dont feel like editing all the configs for things like phpbb, phorm, my own scripts and such itts just oo much of a hassle... any other suggestions would be greatly appreciated. I am confident you guys will find the solution to this bug eventually. thanks Andrew. [2002-12-01 18:56:41] [EMAIL PROTECTED] I've got an identical problem on php 4.2.3 (submitted as a new bug #20753) to make sure it returns to "open" status. [2002-12-01 16:48:20] [EMAIL PROTECTED] Thank you for taking the time to report a problem with PHP. Unfortunately you are not using a current version of PHP -- the problem might already be fixed. Please download a new PHP version from http://www.php.net/downloads.php If you are able to reproduce the bug with one of the latest versions of PHP, please change the PHP version on this bug report to the version you tested and change the status back to "Open". Again, thank you for your continued support of PHP. [2002-11-21 16:41:21] [EMAIL PROTECTED] You are using a relatively dated PHP, upgrading to 4.2.3 or better yet stable snapshot (avaliable from http://snaps.php.net) may solve your problem. 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/20540 -- Edit this bug report at http://bugs.php.net/?id=20540&edit=1
#20976 [Bgs]: rename openssl.cnf
ID: 20976 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Feature/Change Request Operating System: windows systems PHP Version: 4.3.0RC3 New Comment: I agree with your arguments, my one and only concern was to avoid upcoming bug reports about openssl.cnf refered in the docs, because it is not seen as openssl.conf. But forget it, it seems not to be worth to pay attention to. Regards Friedhelm Betz Previous Comments: [2002-12-13 11:28:31] [EMAIL PROTECTED] This behaviour was chosen as it is the same logic as that used in the openssl command line utility; this is advantageous as it allows "seamless" compatibility with existing openssl installations on all systems. Changing it just to work around a windows explorer "feature" that is not really a problem (you will only edit the .cnf file once or twice) doesn't seem like enough of a good reason. [2002-12-13 06:21:07] [EMAIL PROTECTED] Hi, I know the issues from mysql and their *.cnf files. I don't know how the openssl.cnf is bundeld and my suggestion was _not_ to make PHP search for an opennsl.txt or whatever extension to openssl config file. I was just asking, if it would be possible to rename the shipping openssl.cnf for the reason of easier editing for windows user. I personally have no problems with this issue, I know how to rename or edit and set the env variables:-) Regards Friedhelm Betz [2002-12-13 05:51:00] [EMAIL PROTECTED] mysql also has a similar issue with it's my.cnf file, although it will also search for my.ini in certain, not always useful, locations. [2002-12-13 02:37:35] [EMAIL PROTECTED] And you can btw, name it whatever you like, just set an environment variable called "OPENSSL_CONF" with the name. [2002-12-13 02:33:49] [EMAIL PROTECTED] Wrong place to report this, try openssl.org instead. 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/20976 -- Edit this bug report at http://bugs.php.net/?id=20976&edit=1
#20976 [Bgs]: rename openssl.cnf
ID: 20976 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Feature/Change Request Operating System: windows systems PHP Version: 4.3.0RC3 New Comment: This behaviour was chosen as it is the same logic as that used in the openssl command line utility; this is advantageous as it allows "seamless" compatibility with existing openssl installations on all systems. Changing it just to work around a windows explorer "feature" that is not really a problem (you will only edit the .cnf file once or twice) doesn't seem like enough of a good reason. Previous Comments: [2002-12-13 06:21:07] [EMAIL PROTECTED] Hi, I know the issues from mysql and their *.cnf files. I don't know how the openssl.cnf is bundeld and my suggestion was _not_ to make PHP search for an opennsl.txt or whatever extension to openssl config file. I was just asking, if it would be possible to rename the shipping openssl.cnf for the reason of easier editing for windows user. I personally have no problems with this issue, I know how to rename or edit and set the env variables:-) Regards Friedhelm Betz [2002-12-13 05:51:00] [EMAIL PROTECTED] mysql also has a similar issue with it's my.cnf file, although it will also search for my.ini in certain, not always useful, locations. [2002-12-13 02:37:35] [EMAIL PROTECTED] And you can btw, name it whatever you like, just set an environment variable called "OPENSSL_CONF" with the name. [2002-12-13 02:33:49] [EMAIL PROTECTED] Wrong place to report this, try openssl.org instead. [2002-12-12 17:08:32] [EMAIL PROTECTED] Hi, thanks for your efforts to make openssl extension more easy to use. The note in the openssl/README-ssl.txt adresses cleanly the problem with speeddial-links on windows system. To give more comfort to end-users - ok, renaming in a dos-box works - I suggest to ship this file with an .conf or txt file extension. It doesnt harm, is easy to edit, and will avoid upcoming bug-reports(IMHO). In the tradition to make PHP as easy to use for the end users it would be very kind to rename this file to openssl.conf or openssl.txt. And users who would like to have it named openssl.cnf could easily achieve this by renaming this file through the explorer interface (after editing). Regards Friedhelm Betz -- Edit this bug report at http://bugs.php.net/?id=20976&edit=1
#16411 [Com]: CGI application misbehaved by not returning a complete set of
ID: 16411 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: MSSQL related Operating System: Windows 2000 PHP Version: 4.1.2 New Comment: i'm also experiencing this error with win xp, mssql 2000, and php 4.3.0 rc3. is it a problem with php, or with the mssql libraries? Previous Comments: [2002-12-08 10:31:33] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-12-02 19:59:17] [EMAIL PROTECTED] Database connections are all transient. In the original code, I did not close the connections because php would do that at the end of script. But as I was in doubt, I later made a close right before calling the function header() but the same problem happened. I also made another test: in the script I just opened and immediately right after colsed it. The same bug happened. When I removed that tiny chunk of code, every thing worked just fine. [2002-12-02 19:57:52] [EMAIL PROTECTED] Database connections are all transient. In the original code, I did not close the connections because php would do that at the end of script. But as I was in doubt, I later made a close right before calling the function header() but the same problem happened. I also made another test: in the script I just opened and immediately right after colsed it. The same bug happened. When I removed that tiny chunk of code, every thing worked just fine. [2002-11-30 20:36:38] [EMAIL PROTECTED] What are you doing with your database connections? Are they persistant (mssql_pconnect) or transient (mssql_connect)? Do you close your connections explicitly (mssql_close) before the end of your script? vielina, your connections will be closed each time as you are running under the CGI. [2002-11-21 03:29:36] [EMAIL PROTECTED] I have this problem 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/16411 -- Edit this bug report at http://bugs.php.net/?id=16411&edit=1
#20939 [Com]: PHP stops executing script when using sax handlers
ID: 20939
Comment by: Bruno <[EMAIL PROTECTED]>
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: XSLT related
Operating System: Debian GNU/Linux 2.4.19
PHP Version: 4.2.3
New Comment:
We would like to avoid installing an unstable version of PHP ... and
removing --with-sablot didn't help either
Previous Comments:
[2002-12-11 12:37:43] [EMAIL PROTECTED]
1) remove --with-sablot from your configure line.
2) If iconv is linked in with Sablotron, then use --with-iconv-dir as
well.
3) This is most likely fixed already as this loop is actually a
segfault. (see my mail)
[2002-12-11 10:19:38] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-latest.zip
I cannot replicate this problem with PHP 4.3.0 & Sablotron 0.96. If you
try the snapshot and still experience problems please include the
Sablotron version you are using in your report.
[2002-12-11 09:31:50] [EMAIL PROTECTED]
When using xslt_set_sax_handlers, php stops executing after
xslt_process. Below a script that should reproduce the problem (I
tested it on 2 servers to be sure):
array('start_element','end_element')));
$aryArg['xml']=implode("\n",file(dirname(__FILE__).'/test.xml'));
$aryArg['xsl']=implode("\n",file(dirname(__FILE__).'/test.xsl'));
$strHTML = xslt_process($resXSL,'arg:xml','arg:xsl',NULL,$aryArg);
xslt_free($resXSL);
echo $strHTML;
function start_element($resParser,$strName,$aryAttribs) {
echo 'Start of '.$strName;
}
function end_element($resParser,$strName) {
echo 'End of '.$strName;
}
?>
When this is executed there is no output, when I comment the line where
I use xslt_set_sax_handlers, it works fine (the html is shown). When I
enable xslt logging sablotron seems to be in an endless loop:
Sablotron Message on line none, level log: Parsing 'arg:/xsl'...
Sablotron Message on line none, level log: Parse done in 0.002 seconds
Sablotron Message on line none, level log: Parsing 'arg:/xml'...
Sablotron Message on line none, level log: Parse done in 0.000 seconds
Sablotron Message on line none, level log: Executing stylesheet
'arg:/xsl'...
These lines are printed into the logfile about let's say 30 times, the
first time the message
Sablotron Message on line none, level log: Execution done in 0.002
seconds
appears, the other let's say 29 times not.
When I comment the xslt_set_sax_handlers line the logfile only shows
the 5 lines mentioned before and also the 'Execution don in
seconds' line as you would expect
My guess is that sablotron is stuck in a loop...
PHP is compiled with: --with-dom --with-sablot --with-expat
-with-dom-xslt --with-dom-exslt --enable-xslt' --with-xslt-sablot
If you want to get the xml/xsl files I used, you can get them at
http://bruno.webfx.be/xslt_test/
Thanks in advance,
Bruno
--
Edit this bug report at http://bugs.php.net/?id=20939&edit=1
#20768 [Com]: MySql temp file error
ID: 20768 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Won\'t fix Bug Type: Compile Failure Operating System: Debian 3.0 Stable / Sparc PHP Version: 4.3.0RC2 New Comment: it may be a warning, and not an error, but it sure brings my build to a halt every time -- i'm not gcc genius, but how should we get around this? I'm using gcc 3.2.1, libtool 1.4.3, btw. Previous Comments: [2002-12-02 13:26:55] [EMAIL PROTECTED] It's a warning, not an error. [2002-12-02 13:25:30] [EMAIL PROTECTED] It may be safe, but it stops the compile. I can't build with the code as is. [2002-12-02 13:23:31] [EMAIL PROTECTED] It's harmless; just ignore it. The MySQL library uses it in a safe way anyway. Derick [2002-12-02 13:19:49] [EMAIL PROTECTED] When building 4.3.0RC2 against apache 1.3.26 DSO I get an error stating that usage of tempnam() is insecure - line 103 of ext/mysql/libmysql/my_tempnam.c I replaced line 103 with the following code, which builds and should function identically. /* filespec will be dir + '/' + pfx + 'XX' + null */ res = malloc(strlen(dir) + strlen(pfx) + 8); res[0] = '\0'; strcat(res, dir); strcat(res, "/"); strcat(res, pfx); strcat(res, "XX"); mkstemp(res); /* res=tempnam((char *)dir, (my_string) pfx); */ Someone who knows the mysql code should check this if it's not a local build problem on my end. Other details: Linux Kernel 2.4.18 / sparc64 libc6 2.2.5-11.2 gcc 2.95.4 20011002 (Debian prerelease) ./configure --with-mysql --with-apxs --prefix=/usr --sysconfdir=/etc --localstatedir=/var/php --with-zlib --with-dom --with-gd --with-mysql --enable-sockets --with-jpeg-dir=/usr/lib --with-png-dir=/usr/lib --with-xpm-dir=/usr/X11R6/lib --with-freetype-dir=/usr/lib -- Edit this bug report at http://bugs.php.net/?id=20768&edit=1
#20909 [Opn->Csd]: Memory leak in shutdown_scanner
ID: 20909
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Closed
Bug Type: *General Issues
Operating System: ALL
PHP Version: 4.2.3
New Comment:
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.
Previous Comments:
[2002-12-12 02:50:04] [EMAIL PROTECTED]
the file to patch is: Zend/zend_language_scanner.l
[2002-12-09 09:32:25] [EMAIL PROTECTED]
There is a memory leak in the scanner stack:
A patch like this should work:
void shutdown_scanner(TSRMLS_D)
{
+ if (SCNG(yy_start_stack)) {
+ yy_flex_free(SCNG(yy_start_stack));
+ SCNG(yy_start_stack) = 0;
+ }
if (CG(heredoc)) {
efree(CG(heredoc));
CG(heredoc_len)=0;
}
}
--
Edit this bug report at http://bugs.php.net/?id=20909&edit=1
#20991 [Opn->Csd]: GD 2.0.1 lib problem?
ID: 20991 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Compile Failure Operating System: RH 7.3 PHP Version: 4.3.0RC3 New Comment: 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. Previous Comments: [2002-12-13 10:06:20] [EMAIL PROTECTED] System: P4-2G RAM: 1G OS: RH 7.3 PHP 4.3RC2 compile OK PHP 4.3RC3 compile FAIL using the same compile line. NOTE: gd lib version 2.0.1 (gif hacked) ./configure --with-apxs=/usr/local/apache/bin/apxs \ --with-config-file-path=/usr/local/apache/conf --enable-versioning \ --with-mysql --enable-ftp --enable-bcmath --enable-inline-optimization \ --disable-debug \ --enable-memory-limit=yes --enable-track-vars --enable-save-mode \ --enable-magic-quotes --with-gettext=/usr/bin \ --with-xml --with-imap=/usr/local/imap \ --with-curl=/usr/local --enable-mbstring --enable-mbstr-enc-trans \ --with-jpeg-dir=/usr --with-png-dir=/usr \ --with-zlib-dir=/usr/local --with-t1lib=/usr/local \ --with-gd=/usr --with-zlib=/usr/local --enable-gd-imgstrttf \ --enable-gd-native-ttf --with-freetype-dir=/usr \ --with-pdflib=/usr/local --with-openssl=/usr/local/openssl \ --enable-trans-sid --with-cpdflib --with-pgsql --with-ming=/usr \ --with-bz2 --enable-calendar --with-pspell \ --enable-tokenizer --with-iconv=/usr/local \ --with-gmp --with-mcrypt --with-ldap --with-mm \ --with-mbstring=all --enable-mbregex \ --enable-xslt --with-xslt-sablot \ --with-sablot-js --with-expat-dir=/usr/local \ Err Message: (by PHP 4.3RC3) /bin/sh libtool --silent --mode=compile gcc -I/usr/include -Iext/gd/ -I/www/compile/php-4.3.0RC3/ext/gd/ -DPHP_ATOM_INC -I/www/compile/php-4.3.0RC3/include -I/www/compile/php-4.3.0RC3/main -I/www/compile/php-4.3.0RC3 -I/www/compile/php-4.3.0RC3/Zend -I/usr/local/openssl/include -I/usr/local/include -I/usr/include/freetype2 -I/usr/local/imap/include -I/usr/include/pspell -DLINUX=22 -DMOD_SSL=208112 -DUSE_HSREGEX -DEAPI -DEAPI_MM -I/www/compile/php-4.3.0RC3/TSRM -g -O2 -prefer-pic -c /www/compile/php-4.3.0RC3/ext/gd/gd.c -o ext/gd/gd.lo /www/compile/php-4.3.0RC3/ext/gd/gd.c: In function `_php_image_create_from': /www/compile/php-4.3.0RC3/ext/gd/gd.c:1363: warning: assignment makes pointer from integer without a cast /www/compile/php-4.3.0RC3/ext/gd/gd.c: In function `zif_imagecreatefromxpm': /www/compile/php-4.3.0RC3/ext/gd/gd.c:1433: `gdImageCreateFromXpm' undeclared (first use in this function) /www/compile/php-4.3.0RC3/ext/gd/gd.c:1433: (Each undeclared identifier is reported only once /www/compile/php-4.3.0RC3/ext/gd/gd.c:1433: for each function it appears in.) make: *** [ext/gd/gd.lo] Error 1 thx Patrick Tsang -- Edit this bug report at http://bugs.php.net/?id=20991&edit=1
#20991 [NEW]: GD 2.0.1 lib problem?
From: [EMAIL PROTECTED] Operating system: RH 7.3 PHP version: 4.3.0RC3 PHP Bug Type: Compile Failure Bug description: GD 2.0.1 lib problem? System: P4-2G RAM: 1G OS: RH 7.3 PHP 4.3RC2 compile OK PHP 4.3RC3 compile FAIL using the same compile line. NOTE: gd lib version 2.0.1 (gif hacked) ./configure --with-apxs=/usr/local/apache/bin/apxs \ --with-config-file-path=/usr/local/apache/conf --enable-versioning \ --with-mysql --enable-ftp --enable-bcmath --enable-inline-optimization \ --disable-debug \ --enable-memory-limit=yes --enable-track-vars --enable-save-mode \ --enable-magic-quotes --with-gettext=/usr/bin \ --with-xml --with-imap=/usr/local/imap \ --with-curl=/usr/local --enable-mbstring --enable-mbstr-enc-trans \ --with-jpeg-dir=/usr --with-png-dir=/usr \ --with-zlib-dir=/usr/local --with-t1lib=/usr/local \ --with-gd=/usr --with-zlib=/usr/local --enable-gd-imgstrttf \ --enable-gd-native-ttf --with-freetype-dir=/usr \ --with-pdflib=/usr/local --with-openssl=/usr/local/openssl \ --enable-trans-sid --with-cpdflib --with-pgsql --with-ming=/usr \ --with-bz2 --enable-calendar --with-pspell \ --enable-tokenizer --with-iconv=/usr/local \ --with-gmp --with-mcrypt --with-ldap --with-mm \ --with-mbstring=all --enable-mbregex \ --enable-xslt --with-xslt-sablot \ --with-sablot-js --with-expat-dir=/usr/local \ Err Message: (by PHP 4.3RC3) /bin/sh libtool --silent --mode=compile gcc -I/usr/include -Iext/gd/ -I/www/compile/php-4.3.0RC3/ext/gd/ -DPHP_ATOM_INC -I/www/compile/php-4.3.0RC3/include -I/www/compile/php-4.3.0RC3/main -I/www/compile/php-4.3.0RC3 -I/www/compile/php-4.3.0RC3/Zend -I/usr/local/openssl/include -I/usr/local/include -I/usr/include/freetype2 -I/usr/local/imap/include -I/usr/include/pspell -DLINUX=22 -DMOD_SSL=208112 -DUSE_HSREGEX -DEAPI -DEAPI_MM -I/www/compile/php-4.3.0RC3/TSRM -g -O2 -prefer-pic -c /www/compile/php-4.3.0RC3/ext/gd/gd.c -o ext/gd/gd.lo /www/compile/php-4.3.0RC3/ext/gd/gd.c: In function `_php_image_create_from': /www/compile/php-4.3.0RC3/ext/gd/gd.c:1363: warning: assignment makes pointer from integer without a cast /www/compile/php-4.3.0RC3/ext/gd/gd.c: In function `zif_imagecreatefromxpm': /www/compile/php-4.3.0RC3/ext/gd/gd.c:1433: `gdImageCreateFromXpm' undeclared (first use in this function) /www/compile/php-4.3.0RC3/ext/gd/gd.c:1433: (Each undeclared identifier is reported only once /www/compile/php-4.3.0RC3/ext/gd/gd.c:1433: for each function it appears in.) make: *** [ext/gd/gd.lo] Error 1 thx Patrick Tsang -- Edit bug report at http://bugs.php.net/?id=20991&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20991&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20991&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20991&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20991&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20991&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20991&r=support Expected behavior: http://bugs.php.net/fix.php?id=20991&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20991&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20991&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20991&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20991&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20991&r=dst IIS Stability: http://bugs.php.net/fix.php?id=20991&r=isapi
#20985 [Opn->Fbk]: heavy load = Segmentation fault
ID: 20985 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Reproducible crash Operating System: Redhat Linux 7.3 & 8 PHP Version: 4.3.0RC3 New Comment: Could you please compile your PHP with --enable-debug, this will make you backtrace contain a lot more information. If you are able to do that then go the step #5 (free_zend_constant) and see what data the various pointers contains. I am especially interested in seeing what constant is being freed and if it is the same one everytime. Previous Comments: [2002-12-13 09:53:03] [EMAIL PROTECTED] I have also submitted a bug report to Redhat: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=79561 I hope that's ok. [2002-12-13 09:47:25] [EMAIL PROTECTED] I have now tested with RPMs from Redhat: apache-1.3.27-2.i386.rpm php-4.1.2-7.3.6.i386.rpm php-mysql-4.1.2-7.3.6.i386.rpm And these from MySQL: MySQL-shared-3.23.54-1.i386.rpm MySQL-4.0.5-0.i386.rpm And i get the same error: [Fri Dec 13 16:45:25 2002] [notice] child pid 1273 exit signal Segmentation fault (11) [2002-12-13 08:52:40] [EMAIL PROTECTED] I use files as my session handler. Have also tried with mm, but I think the same happens here. [2002-12-13 08:42:34] [EMAIL PROTECTED] Are you using PHP sessions, if so what session handler are you using? [2002-12-13 07:42:05] [EMAIL PROTECTED] [root@spinaker root]# gdb /usr/local/apache/bin/httpd GNU gdb Red Hat Linux (5.2-2) 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-redhat-linux"... (no debugging symbols found)... (gdb) run -X Starting program: /usr/local/apache/bin/httpd -X (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... Program received signal SIGSEGV, Segmentation fault. 0x401ac9af in memcpy () from /lib/libc.so.6 (gdb) bt #0 0x401ac9af in memcpy () from /lib/libc.so.6 #1 0x0810c512 in _mem_block_check () #2 0x0810c4d5 in _mem_block_check () #3 0x0810b72f in _efree () #4 0x0811af00 in _zval_dtor () #5 0x08111d0a in free_zend_constant () #6 0x0812167d in zend_hash_del_key_or_index () #7 0x08121f38 in zend_hash_reverse_apply () #8 0x08112113 in clean_non_persistent_constants () #9 0x0811290c in shutdown_executor () #10 0x0811c0c6 in zend_deactivate () #11 0x08079fbc in php_request_shutdown () #12 0x08127e82 in apache_php_module_main () #13 0x080774dc in php_restore_umask () #14 0x08077535 in php_restore_umask () #15 0x08149dc3 in ap_invoke_handler () #16 0x0815ed47 in ap_some_auth_required () #17 0x0815f16b in ap_internal_redirect () #18 0x0806bc3c in ap_get_server_built () #19 0x08149dc3 in ap_invoke_handler () #20 0x0815ed47 in ap_some_auth_required () #21 0x0815eda8 in ap_process_request () #22 0x08155be5 in ap_child_terminate () ---Type to continue, or q to quit--- #23 0x08155d90 in ap_child_terminate () #24 0x08155f04 in ap_child_terminate () #25 0x0815657c in ap_child_terminate () #26 0x08156ddf in main () #27 0x401481c4 in __libc_start_main () from /lib/libc.so.6 (gdb) 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/20985 -- Edit this bug report at http://bugs.php.net/?id=20985&edit=1
#20985 [Com]: heavy load = Segmentation fault
ID: 20985 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Reproducible crash Operating System: Redhat Linux 7.3 & 8 PHP Version: 4.3.0RC3 New Comment: I have also submitted a bug report to Redhat: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=79561 I hope that's ok. Previous Comments: [2002-12-13 09:47:25] [EMAIL PROTECTED] I have now tested with RPMs from Redhat: apache-1.3.27-2.i386.rpm php-4.1.2-7.3.6.i386.rpm php-mysql-4.1.2-7.3.6.i386.rpm And these from MySQL: MySQL-shared-3.23.54-1.i386.rpm MySQL-4.0.5-0.i386.rpm And i get the same error: [Fri Dec 13 16:45:25 2002] [notice] child pid 1273 exit signal Segmentation fault (11) [2002-12-13 08:52:40] [EMAIL PROTECTED] I use files as my session handler. Have also tried with mm, but I think the same happens here. [2002-12-13 08:42:34] [EMAIL PROTECTED] Are you using PHP sessions, if so what session handler are you using? [2002-12-13 07:42:05] [EMAIL PROTECTED] [root@spinaker root]# gdb /usr/local/apache/bin/httpd GNU gdb Red Hat Linux (5.2-2) 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-redhat-linux"... (no debugging symbols found)... (gdb) run -X Starting program: /usr/local/apache/bin/httpd -X (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... Program received signal SIGSEGV, Segmentation fault. 0x401ac9af in memcpy () from /lib/libc.so.6 (gdb) bt #0 0x401ac9af in memcpy () from /lib/libc.so.6 #1 0x0810c512 in _mem_block_check () #2 0x0810c4d5 in _mem_block_check () #3 0x0810b72f in _efree () #4 0x0811af00 in _zval_dtor () #5 0x08111d0a in free_zend_constant () #6 0x0812167d in zend_hash_del_key_or_index () #7 0x08121f38 in zend_hash_reverse_apply () #8 0x08112113 in clean_non_persistent_constants () #9 0x0811290c in shutdown_executor () #10 0x0811c0c6 in zend_deactivate () #11 0x08079fbc in php_request_shutdown () #12 0x08127e82 in apache_php_module_main () #13 0x080774dc in php_restore_umask () #14 0x08077535 in php_restore_umask () #15 0x08149dc3 in ap_invoke_handler () #16 0x0815ed47 in ap_some_auth_required () #17 0x0815f16b in ap_internal_redirect () #18 0x0806bc3c in ap_get_server_built () #19 0x08149dc3 in ap_invoke_handler () #20 0x0815ed47 in ap_some_auth_required () #21 0x0815eda8 in ap_process_request () #22 0x08155be5 in ap_child_terminate () ---Type to continue, or q to quit--- #23 0x08155d90 in ap_child_terminate () #24 0x08155f04 in ap_child_terminate () #25 0x0815657c in ap_child_terminate () #26 0x08156ddf in main () #27 0x401481c4 in __libc_start_main () from /lib/libc.so.6 (gdb) [2002-12-13 04:06:11] [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. 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/20985 -- Edit this bug report at http://bugs.php.net/?id=20985&edit=1
#20985 [Opn]: heavy load = Segmentation fault
ID: 20985 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Reproducible crash Operating System: Redhat Linux 7.3 & 8 PHP Version: 4.3.0RC3 New Comment: I have now tested with RPMs from Redhat: apache-1.3.27-2.i386.rpm php-4.1.2-7.3.6.i386.rpm php-mysql-4.1.2-7.3.6.i386.rpm And these from MySQL: MySQL-shared-3.23.54-1.i386.rpm MySQL-4.0.5-0.i386.rpm And i get the same error: [Fri Dec 13 16:45:25 2002] [notice] child pid 1273 exit signal Segmentation fault (11) Previous Comments: [2002-12-13 08:52:40] [EMAIL PROTECTED] I use files as my session handler. Have also tried with mm, but I think the same happens here. [2002-12-13 08:42:34] [EMAIL PROTECTED] Are you using PHP sessions, if so what session handler are you using? [2002-12-13 07:42:05] [EMAIL PROTECTED] [root@spinaker root]# gdb /usr/local/apache/bin/httpd GNU gdb Red Hat Linux (5.2-2) 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-redhat-linux"... (no debugging symbols found)... (gdb) run -X Starting program: /usr/local/apache/bin/httpd -X (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... Program received signal SIGSEGV, Segmentation fault. 0x401ac9af in memcpy () from /lib/libc.so.6 (gdb) bt #0 0x401ac9af in memcpy () from /lib/libc.so.6 #1 0x0810c512 in _mem_block_check () #2 0x0810c4d5 in _mem_block_check () #3 0x0810b72f in _efree () #4 0x0811af00 in _zval_dtor () #5 0x08111d0a in free_zend_constant () #6 0x0812167d in zend_hash_del_key_or_index () #7 0x08121f38 in zend_hash_reverse_apply () #8 0x08112113 in clean_non_persistent_constants () #9 0x0811290c in shutdown_executor () #10 0x0811c0c6 in zend_deactivate () #11 0x08079fbc in php_request_shutdown () #12 0x08127e82 in apache_php_module_main () #13 0x080774dc in php_restore_umask () #14 0x08077535 in php_restore_umask () #15 0x08149dc3 in ap_invoke_handler () #16 0x0815ed47 in ap_some_auth_required () #17 0x0815f16b in ap_internal_redirect () #18 0x0806bc3c in ap_get_server_built () #19 0x08149dc3 in ap_invoke_handler () #20 0x0815ed47 in ap_some_auth_required () #21 0x0815eda8 in ap_process_request () #22 0x08155be5 in ap_child_terminate () ---Type to continue, or q to quit--- #23 0x08155d90 in ap_child_terminate () #24 0x08155f04 in ap_child_terminate () #25 0x0815657c in ap_child_terminate () #26 0x08156ddf in main () #27 0x401481c4 in __libc_start_main () from /lib/libc.so.6 (gdb) [2002-12-13 04:06:11] [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. [2002-12-13 03:55:57] [EMAIL PROTECTED] I have tested this on different machines, so I do not think that this is a hardware error. 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/20985 -- Edit this bug report at http://bugs.php.net/?id=20985&edit=1
#20985 [Fbk->Opn]: heavy load = Segmentation fault
ID: 20985 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: Reproducible crash Operating System: Redhat Linux 7.3 & 8 PHP Version: 4.3.0RC3 New Comment: I use files as my session handler. Have also tried with mm, but I think the same happens here. Previous Comments: [2002-12-13 08:42:34] [EMAIL PROTECTED] Are you using PHP sessions, if so what session handler are you using? [2002-12-13 07:42:05] [EMAIL PROTECTED] [root@spinaker root]# gdb /usr/local/apache/bin/httpd GNU gdb Red Hat Linux (5.2-2) 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-redhat-linux"... (no debugging symbols found)... (gdb) run -X Starting program: /usr/local/apache/bin/httpd -X (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... Program received signal SIGSEGV, Segmentation fault. 0x401ac9af in memcpy () from /lib/libc.so.6 (gdb) bt #0 0x401ac9af in memcpy () from /lib/libc.so.6 #1 0x0810c512 in _mem_block_check () #2 0x0810c4d5 in _mem_block_check () #3 0x0810b72f in _efree () #4 0x0811af00 in _zval_dtor () #5 0x08111d0a in free_zend_constant () #6 0x0812167d in zend_hash_del_key_or_index () #7 0x08121f38 in zend_hash_reverse_apply () #8 0x08112113 in clean_non_persistent_constants () #9 0x0811290c in shutdown_executor () #10 0x0811c0c6 in zend_deactivate () #11 0x08079fbc in php_request_shutdown () #12 0x08127e82 in apache_php_module_main () #13 0x080774dc in php_restore_umask () #14 0x08077535 in php_restore_umask () #15 0x08149dc3 in ap_invoke_handler () #16 0x0815ed47 in ap_some_auth_required () #17 0x0815f16b in ap_internal_redirect () #18 0x0806bc3c in ap_get_server_built () #19 0x08149dc3 in ap_invoke_handler () #20 0x0815ed47 in ap_some_auth_required () #21 0x0815eda8 in ap_process_request () #22 0x08155be5 in ap_child_terminate () ---Type to continue, or q to quit--- #23 0x08155d90 in ap_child_terminate () #24 0x08155f04 in ap_child_terminate () #25 0x0815657c in ap_child_terminate () #26 0x08156ddf in main () #27 0x401481c4 in __libc_start_main () from /lib/libc.so.6 (gdb) [2002-12-13 04:06:11] [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. [2002-12-13 03:55:57] [EMAIL PROTECTED] I have tested this on different machines, so I do not think that this is a hardware error. [2002-12-13 03:49:42] [EMAIL PROTECTED] I get these errors on both Redhat Linux 7.3 & 8 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/20985 -- Edit this bug report at http://bugs.php.net/?id=20985&edit=1
#20988 [Fbk->Csd]: Apache segfaults using MM session on garbage collection
ID: 20988 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Closed Bug Type: Session related Operating System: Linux 2.4.19 (Debian) PHP Version: 4.3.0RC3 New Comment: My comments moved to #20358. Previous Comments: [2002-12-13 08:37:40] [EMAIL PROTECTED] Sorry, I meant "print *data" and "print *sd" so that we see the contents of the arguments. Can you also do "print slot", "print data->hash", "print *(data->hash)" and "print *prev" for me? [2002-12-13 08:37:17] [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. Because of this, we hope you add your comments to the existing bug instead. Thank you for your interest in PHP. This is a known issue with the 'mm' session handler that is described in report #20358. In the interest of keeping the discussion about this bug in one place I am closing this report. [2002-12-13 08:33:44] [EMAIL PROTECTED] #0 0x48287655 in ps_sd_destroy (data=0x811b0a0, sd=0x4c6c2354) at mod_mm.c:168 168 for (prev = data->hash[slot]; prev->next != sd; prev = prev->next); print data: $1 = (ps_mm *) 0x811b0a0 print sd: $2 = (ps_sd *) 0x4c6c2354 [2002-12-13 08:23:33] [EMAIL PROTECTED] Before this backtrace, GDB should have spit out an error too with a source line, can you please paste that one in the form, and also the result of: print data and print sd (at the same place as were you typed 'bt'). thanks! Derick [2002-12-13 08:20:18] [EMAIL PROTECTED] Managed to get backtrace on FreeBSD box: #0 0x48287655 in ps_sd_destroy (data=0x811b0a0, sd=0x4c6c2354) at mod_mm.c:168 #1 0x4828784f in ps_mm_destroy (data=0x811b0a0) at mod_mm.c:242 #2 0x48287a25 in zm_shutdown_ps_mm (type=1, module_number=11) at mod_mm.c:293 #3 0x48231e93 in module_destructor (module=0x811c500) at zend_API.c:1127 #4 0x482338d3 in zend_hash_destroy (ht=0x48333b80) at zend_hash.c:541 #5 0x4822ef3f in zend_shutdown () at zend.c:492 #6 0x4823c107 in php_module_shutdown () at main.c:1052 #7 0x4823c0d4 in php_module_shutdown_wrapper (sapi_globals=0x48311880) at main.c:1029 #8 0x48239abc in apache_php_module_shutdown_wrapper () at mod_php4.c:800 #9 0x805003a in run_cleanups () #10 0x804f09f in ap_clear_pool () #11 0x804f100 in ap_destroy_pool () #12 0x804f08b in ap_clear_pool () #13 0x804f100 in ap_destroy_pool () #14 0x8059460 in clean_parent_exit () #15 0x805b925 in standalone_main () #16 0x805bd6b in main () #17 0x804eb0d in _start () 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/20988 -- Edit this bug report at http://bugs.php.net/?id=20988&edit=1
#20358 [Com]: Apache is "Segmentation fault" by session_start() with libmm
ID: 20358
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Verified
Bug Type: Session related
Operating System: RedHat7.3
PHP Version: 4.3.0-dev
New Comment:
FreeBSD, Apache 1.3.27, PHP 4.2.3
#0 0x48287655 in ps_sd_destroy (data=0x811b0a0, sd=0x4c6c2354) at
mod_mm.c:168
168 for (prev = data->hash[slot]; prev->next != sd;
prev = prev->next);
(gdb) bt
#0 0x48287655 in ps_sd_destroy (data=0x811b0a0, sd=0x4c6c2354) at
mod_mm.c:168
#1 0x4828784f in ps_mm_destroy (data=0x811b0a0) at mod_mm.c:242
#2 0x48287a25 in zm_shutdown_ps_mm (type=1, module_number=11) at
mod_mm.c:293
#3 0x48231e93 in module_destructor (module=0x811c500) at
zend_API.c:1127
#4 0x482338d3 in zend_hash_destroy (ht=0x48333b80) at zend_hash.c:541
#5 0x4822ef3f in zend_shutdown () at zend.c:492
#6 0x4823c107 in php_module_shutdown () at main.c:1052
#7 0x4823c0d4 in php_module_shutdown_wrapper
(sapi_globals=0x48311880)
at main.c:1029
#8 0x48239abc in apache_php_module_shutdown_wrapper () at
mod_php4.c:800
#9 0x805003a in run_cleanups ()
#10 0x804f09f in ap_clear_pool ()
#11 0x804f100 in ap_destroy_pool ()
#12 0x804f08b in ap_clear_pool ()
#13 0x804f100 in ap_destroy_pool ()
#14 0x8059460 in clean_parent_exit ()
#15 0x805b925 in standalone_main ()
#16 0x805bd6b in main ()
#17 0x804eb0d in _start ()
(gdb) print *data
$3 = {mm = 0x4c69b414, hash = 0x4c69b434, hash_max = 511, hash_cnt =
0,
owner = 81324}
(gdb) print *sd
$4 = {next = 0x3e0, hv = 979, ctime = 1282159212, data = 0x74656c73,
datalen = 2087871860, alloclen = 976304755, key = "\""}
(gdb) print slot
$5 = 1282155348
(gdb) print data->hash
$6 = (ps_sd **) 0x4c69b434
(gdb) print *(data->hash)
$7 = (ps_sd *) 0x4c6c2354
(gdb) print *prev
Cannot access memory at address 0x10.
Previous Comments:
[2002-11-12 06:01:38] [EMAIL PROTECTED]
more info...
(gdb) list
182
183 hv = ps_sd_hash(key, strlen(key));
184 slot = hv & data->hash_max;
185
186 for (prev = NULL, ret = data->hash[slot]; ret; prev =
ret, ret =
ret->next)
187 if (ret->hv == hv && !strcmp(ret->key, key))
188 break;
189
190 if (ret && rw && ret != data->hash[slot]) {
191 /* Move the entry to the top of the linked list
*/
(gdb) print key
$1 = 0x8136f2c "136"
(gdb) print hv
$2 = 1943406893
(gdb) print slot
$3 = 301
(gdb) print data->hash_max
$4 = 511
(gdb) print prev
$5 = (ps_sd *) 0x4413df00
(gdb) print ret
$6 = (ps_sd *) 0x1f
(gdb) print ret->next
Cannot access memory at address 0x1f
(gdb) print data->hash[slot]->next
$7 = (struct ps_sd *) 0x1f
[2002-11-12 05:51:51] [EMAIL PROTECTED]
Apache was re-compiled with -DBIG_SECURITY_HOLE option.
edit /usr/local/apache/conf/httpd.conf
User root
Group root
CoreDumpDirectory /tmp
# /usr/local/apache/bin/apachectl start
# sh loop.sh
# tail -f /usr/local/apache/logs/error_log
[Tue Nov 12 20:41:49 2002] [notice] child pid 23351 exit signal
Segmentation fault (11), possible coredump in /tmp
child proccess of apache was core dumped.
back trace
(gdb) bt
#0 0x40148a33 in ps_sd_lookup (data=0x80d4418, key=0x8136f2c "136",
rw=0)
at /home/work/httpd/php-4.3.0pre2/ext/session/mod_mm.c:187
#1 0x40148ec8 in ps_read_mm (mod_data=0x4029ea70, key=0x8136f2c
"136",
val=0xbfffd1e0, vallen=0xbfffd1dc)
at /home/work/httpd/php-4.3.0pre2/ext/session/mod_mm.c:326
#2 0x401446b9 in php_session_initialize ()
at /home/work/httpd/php-4.3.0pre2/ext/session/session.c:608
#3 0x40145864 in php_session_start ()
at /home/work/httpd/php-4.3.0pre2/ext/session/session.c:1004
#4 0x40147438 in zif_session_start (ht=0, return_value=0x8136fd4,
this_ptr=0x0, return_value_used=0)
at /home/work/httpd/php-4.3.0pre2/ext/session/session.c:1445
#5 0x4022cfc7 in execute (op_array=0x8136c3c)
at /home/work/httpd/php-4.3.0pre2/Zend/zend_execute.c:1595
#6 0x4021a174 in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at /home/work/httpd/php-4.3.0pre2/Zend/zend.c:839
#7 0x401e1f13 in php_execute_script (primary_file=0xb6b0)
at /home/work/httpd/php-4.3.0pre2/main/main.c:1542
#8 0x40231f36 in apache_php_module_main (r=0x812ff2c,
display_source_mode=0)
at /home/work/httpd/php-4.3.0pre2/sapi/apache/sapi_apache.c:55
#9 0x40232e00 in send_php (r=0x812ff2c, display_source_mode=0,
filename=0x813093c
"/usr/local/apache/htdocs/php/samples/session/bug.phtml")
at /home/work/httpd/php-4.3.0pre2/sapi/apache/mod_php4.c:556
#10 0x40232e6d in send_parsed_php (r=0x812ff2c)
at /home/work/httpd/php-4.3.0pre2/sapi/apache/mod_php4.c:571
#11 0x0806a7bb in ap_invoke_handler ()
#12 0x0807f723 in process_reques
#20977 [Com]: Cannot compile both yaz and imap options
ID: 20977 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Compile Failure Operating System: Solaris 2.9 PHP Version: 4.3.0RC3 New Comment: Yes, the versions of yaz and the imap c-client libraries were the same with php 4.2.3, and I did not encounter any build errors using the same configure options. I'll share the problem with the yaz and c-client developers. Thanks. Previous Comments: [2002-12-13 02:45:44] [EMAIL PROTECTED] Are the yaz and c-client libs the same when you tried with PHP 4.2.3 ?? And this really isn't a PHP problem, both c-client and yaz libs use same names for their functions. You really should report this to either the authors of yaz or c-client.. [2002-12-12 18:43:14] [EMAIL PROTECTED] With php-4.3.0RC3 on Solaris 2.9, the 'imap' and 'yaz' extensions seem to have a conflict. That is, I get compilation errors after the following configure command: configure --with-imap --with-yaz The make fails with: /bin/sh libtool --silent --mode=link gcc -export-dynamic -g -O2 -L/usr/ucblib -L/usr/local/lib/gcc-lib/sparc-sun-solaris2.9/2.95.3 -L/usr/local/lib -R /usr/ucblib -R /usr/local/lib/gcc-lib/sparc-sun-solaris2.9/2.95.3 -R /usr/local/lib ext/ctype/ctype.lo ext/imap/php_imap.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.l /usr/local/lib/libyaz.a(unix.o): In function `unix_close': /usr/local/src/yaz/yaz-1.9.2/comstack/unix.c:565: multiple definition of `unix_close' /usr/local/lib/libc-client.a(unix.o):/usr/local/src/imap/imap-2002.RC2/c-client/unix.c:437: first defined here /usr/local/sparc-sun-solaris2.9/bin/ld: Warning: size of symbol `unix_close' changed from 124 to 100 in unix.o collect2: ld returned 1 exit status gmake: *** [sapi/cgi/php-cgi] Error 1 However, 'configure --with-imap' and 'configure --with-yaz' each build without errors. Similarly, php4.2.3 does not have this problem with configured with both imap and yaz. Thanks. -- Edit this bug report at http://bugs.php.net/?id=20977&edit=1
#20985 [Opn->Fbk]: heavy load = Segmentation fault
ID: 20985 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Reproducible crash Operating System: Redhat Linux 7.3 & 8 PHP Version: 4.3.0RC3 New Comment: Are you using PHP sessions, if so what session handler are you using? Previous Comments: [2002-12-13 07:42:05] [EMAIL PROTECTED] [root@spinaker root]# gdb /usr/local/apache/bin/httpd GNU gdb Red Hat Linux (5.2-2) 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-redhat-linux"... (no debugging symbols found)... (gdb) run -X Starting program: /usr/local/apache/bin/httpd -X (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... Program received signal SIGSEGV, Segmentation fault. 0x401ac9af in memcpy () from /lib/libc.so.6 (gdb) bt #0 0x401ac9af in memcpy () from /lib/libc.so.6 #1 0x0810c512 in _mem_block_check () #2 0x0810c4d5 in _mem_block_check () #3 0x0810b72f in _efree () #4 0x0811af00 in _zval_dtor () #5 0x08111d0a in free_zend_constant () #6 0x0812167d in zend_hash_del_key_or_index () #7 0x08121f38 in zend_hash_reverse_apply () #8 0x08112113 in clean_non_persistent_constants () #9 0x0811290c in shutdown_executor () #10 0x0811c0c6 in zend_deactivate () #11 0x08079fbc in php_request_shutdown () #12 0x08127e82 in apache_php_module_main () #13 0x080774dc in php_restore_umask () #14 0x08077535 in php_restore_umask () #15 0x08149dc3 in ap_invoke_handler () #16 0x0815ed47 in ap_some_auth_required () #17 0x0815f16b in ap_internal_redirect () #18 0x0806bc3c in ap_get_server_built () #19 0x08149dc3 in ap_invoke_handler () #20 0x0815ed47 in ap_some_auth_required () #21 0x0815eda8 in ap_process_request () #22 0x08155be5 in ap_child_terminate () ---Type to continue, or q to quit--- #23 0x08155d90 in ap_child_terminate () #24 0x08155f04 in ap_child_terminate () #25 0x0815657c in ap_child_terminate () #26 0x08156ddf in main () #27 0x401481c4 in __libc_start_main () from /lib/libc.so.6 (gdb) [2002-12-13 04:06:11] [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. [2002-12-13 03:55:57] [EMAIL PROTECTED] I have tested this on different machines, so I do not think that this is a hardware error. [2002-12-13 03:49:42] [EMAIL PROTECTED] I get these errors on both Redhat Linux 7.3 & 8 [2002-12-13 03:47:42] [EMAIL PROTECTED] [Fri Dec 13 10:17:36 2002] [notice] child pid 15954 exit signal Segmentation fault (11) I get several lines like the above when I have heavy load on the server. This also happens whith php 4.2.3 In the test i used: Compaq P4 1.6ghz, 256mb ram Redhat Linux 7.3, kernel 2.4.18-18.8.0 Apache 1.3.27 Php 4.3.0RC3 & 4.2.3 MySQL 4.0.5a Stress tool: http://webtool.rte.microsoft.com/ I configured php like this: ./configure --with-apache=../apache-1.3.27 --with-mysql=/usr --enable-trans-sid --enable-inline-optimization --without-pear 'make test' made no errors. Please let me know what I can do to help you fix this bug. -- Edit this bug report at http://bugs.php.net/?id=20985&edit=1
#20988 [Bgs->Fbk]: Apache segfaults using MM session on garbage collection
ID: 20988 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Bogus +Status: Feedback Bug Type: Session related Operating System: Linux 2.4.19 (Debian) PHP Version: 4.3.0RC3 New Comment: Sorry, I meant "print *data" and "print *sd" so that we see the contents of the arguments. Can you also do "print slot", "print data->hash", "print *(data->hash)" and "print *prev" for me? Previous Comments: [2002-12-13 08:37:17] [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. Because of this, we hope you add your comments to the existing bug instead. Thank you for your interest in PHP. This is a known issue with the 'mm' session handler that is described in report #20358. In the interest of keeping the discussion about this bug in one place I am closing this report. [2002-12-13 08:33:44] [EMAIL PROTECTED] #0 0x48287655 in ps_sd_destroy (data=0x811b0a0, sd=0x4c6c2354) at mod_mm.c:168 168 for (prev = data->hash[slot]; prev->next != sd; prev = prev->next); print data: $1 = (ps_mm *) 0x811b0a0 print sd: $2 = (ps_sd *) 0x4c6c2354 [2002-12-13 08:23:33] [EMAIL PROTECTED] Before this backtrace, GDB should have spit out an error too with a source line, can you please paste that one in the form, and also the result of: print data and print sd (at the same place as were you typed 'bt'). thanks! Derick [2002-12-13 08:20:18] [EMAIL PROTECTED] Managed to get backtrace on FreeBSD box: #0 0x48287655 in ps_sd_destroy (data=0x811b0a0, sd=0x4c6c2354) at mod_mm.c:168 #1 0x4828784f in ps_mm_destroy (data=0x811b0a0) at mod_mm.c:242 #2 0x48287a25 in zm_shutdown_ps_mm (type=1, module_number=11) at mod_mm.c:293 #3 0x48231e93 in module_destructor (module=0x811c500) at zend_API.c:1127 #4 0x482338d3 in zend_hash_destroy (ht=0x48333b80) at zend_hash.c:541 #5 0x4822ef3f in zend_shutdown () at zend.c:492 #6 0x4823c107 in php_module_shutdown () at main.c:1052 #7 0x4823c0d4 in php_module_shutdown_wrapper (sapi_globals=0x48311880) at main.c:1029 #8 0x48239abc in apache_php_module_shutdown_wrapper () at mod_php4.c:800 #9 0x805003a in run_cleanups () #10 0x804f09f in ap_clear_pool () #11 0x804f100 in ap_destroy_pool () #12 0x804f08b in ap_clear_pool () #13 0x804f100 in ap_destroy_pool () #14 0x8059460 in clean_parent_exit () #15 0x805b925 in standalone_main () #16 0x805bd6b in main () #17 0x804eb0d in _start () [2002-12-13 07:57:20] [EMAIL PROTECTED] While trying to backtrace a particular forked child it would not segfault until i detach gdb from it - then it segfaults with: [Sat Dec 14 05:02:19 2002] [notice] child pid 4858 exit signal Segmentation fault (11) 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/20988 -- Edit this bug report at http://bugs.php.net/?id=20988&edit=1
#20988 [Opn->Bgs]: Apache segfaults using MM session on garbage collection
ID: 20988 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Session related Operating System: Linux 2.4.19 (Debian) PHP Version: 4.3.0RC3 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. Because of this, we hope you add your comments to the existing bug instead. Thank you for your interest in PHP. This is a known issue with the 'mm' session handler that is described in report #20358. In the interest of keeping the discussion about this bug in one place I am closing this report. Previous Comments: [2002-12-13 08:33:44] [EMAIL PROTECTED] #0 0x48287655 in ps_sd_destroy (data=0x811b0a0, sd=0x4c6c2354) at mod_mm.c:168 168 for (prev = data->hash[slot]; prev->next != sd; prev = prev->next); print data: $1 = (ps_mm *) 0x811b0a0 print sd: $2 = (ps_sd *) 0x4c6c2354 [2002-12-13 08:23:33] [EMAIL PROTECTED] Before this backtrace, GDB should have spit out an error too with a source line, can you please paste that one in the form, and also the result of: print data and print sd (at the same place as were you typed 'bt'). thanks! Derick [2002-12-13 08:20:18] [EMAIL PROTECTED] Managed to get backtrace on FreeBSD box: #0 0x48287655 in ps_sd_destroy (data=0x811b0a0, sd=0x4c6c2354) at mod_mm.c:168 #1 0x4828784f in ps_mm_destroy (data=0x811b0a0) at mod_mm.c:242 #2 0x48287a25 in zm_shutdown_ps_mm (type=1, module_number=11) at mod_mm.c:293 #3 0x48231e93 in module_destructor (module=0x811c500) at zend_API.c:1127 #4 0x482338d3 in zend_hash_destroy (ht=0x48333b80) at zend_hash.c:541 #5 0x4822ef3f in zend_shutdown () at zend.c:492 #6 0x4823c107 in php_module_shutdown () at main.c:1052 #7 0x4823c0d4 in php_module_shutdown_wrapper (sapi_globals=0x48311880) at main.c:1029 #8 0x48239abc in apache_php_module_shutdown_wrapper () at mod_php4.c:800 #9 0x805003a in run_cleanups () #10 0x804f09f in ap_clear_pool () #11 0x804f100 in ap_destroy_pool () #12 0x804f08b in ap_clear_pool () #13 0x804f100 in ap_destroy_pool () #14 0x8059460 in clean_parent_exit () #15 0x805b925 in standalone_main () #16 0x805bd6b in main () #17 0x804eb0d in _start () [2002-12-13 07:57:20] [EMAIL PROTECTED] While trying to backtrace a particular forked child it would not segfault until i detach gdb from it - then it segfaults with: [Sat Dec 14 05:02:19 2002] [notice] child pid 4858 exit signal Segmentation fault (11) [2002-12-13 07:34:33] [EMAIL PROTECTED] I know it's not a backtrace. I have just forgot to paste apache log segfault line example in my original posting. However. When trying to backtrace I cannot reproduce this behavior. It's happening under constant heavy load that can be simulated using ab -n 1 and the example script I have supplied. Only after about 3000-4000 request this one happens. I cannot execute 3000 request because httpd -X exits after several hundred requests (normal exit - no backtrace) and I don't know why. 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/20988 -- Edit this bug report at http://bugs.php.net/?id=20988&edit=1
#20988 [Fbk->Opn]: Apache segfaults using MM session on garbage collection
ID: 20988 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: Session related Operating System: Linux 2.4.19 (Debian) PHP Version: 4.3.0RC3 New Comment: #0 0x48287655 in ps_sd_destroy (data=0x811b0a0, sd=0x4c6c2354) at mod_mm.c:168 168 for (prev = data->hash[slot]; prev->next != sd; prev = prev->next); print data: $1 = (ps_mm *) 0x811b0a0 print sd: $2 = (ps_sd *) 0x4c6c2354 Previous Comments: [2002-12-13 08:23:33] [EMAIL PROTECTED] Before this backtrace, GDB should have spit out an error too with a source line, can you please paste that one in the form, and also the result of: print data and print sd (at the same place as were you typed 'bt'). thanks! Derick [2002-12-13 08:20:18] [EMAIL PROTECTED] Managed to get backtrace on FreeBSD box: #0 0x48287655 in ps_sd_destroy (data=0x811b0a0, sd=0x4c6c2354) at mod_mm.c:168 #1 0x4828784f in ps_mm_destroy (data=0x811b0a0) at mod_mm.c:242 #2 0x48287a25 in zm_shutdown_ps_mm (type=1, module_number=11) at mod_mm.c:293 #3 0x48231e93 in module_destructor (module=0x811c500) at zend_API.c:1127 #4 0x482338d3 in zend_hash_destroy (ht=0x48333b80) at zend_hash.c:541 #5 0x4822ef3f in zend_shutdown () at zend.c:492 #6 0x4823c107 in php_module_shutdown () at main.c:1052 #7 0x4823c0d4 in php_module_shutdown_wrapper (sapi_globals=0x48311880) at main.c:1029 #8 0x48239abc in apache_php_module_shutdown_wrapper () at mod_php4.c:800 #9 0x805003a in run_cleanups () #10 0x804f09f in ap_clear_pool () #11 0x804f100 in ap_destroy_pool () #12 0x804f08b in ap_clear_pool () #13 0x804f100 in ap_destroy_pool () #14 0x8059460 in clean_parent_exit () #15 0x805b925 in standalone_main () #16 0x805bd6b in main () #17 0x804eb0d in _start () [2002-12-13 07:57:20] [EMAIL PROTECTED] While trying to backtrace a particular forked child it would not segfault until i detach gdb from it - then it segfaults with: [Sat Dec 14 05:02:19 2002] [notice] child pid 4858 exit signal Segmentation fault (11) [2002-12-13 07:34:33] [EMAIL PROTECTED] I know it's not a backtrace. I have just forgot to paste apache log segfault line example in my original posting. However. When trying to backtrace I cannot reproduce this behavior. It's happening under constant heavy load that can be simulated using ab -n 1 and the example script I have supplied. Only after about 3000-4000 request this one happens. I cannot execute 3000 request because httpd -X exits after several hundred requests (normal exit - no backtrace) and I don't know why. [2002-12-13 07:01:55] [EMAIL PROTECTED] That is not a back trace, please follow the instructions as described here: http://bugs.php.net/bugs-generating-backtrace.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/20988 -- Edit this bug report at http://bugs.php.net/?id=20988&edit=1
#20546 [Fbk->Bgs]: compile with gcc 3.2 fails due to parser errors
ID: 20546 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Bogus Bug Type: Compile Failure Operating System: RedHat Linux 8.0 PHP Version: 4.3.0-dev Previous Comments: [2002-12-13 08:13:06] [EMAIL PROTECTED] i finally found out what was wrong -- i was missing 'cpp0', which apparently was not required by the Redhat Rawhide gcc packages as it should have been. without it, the configure script assumed that i wasn't using GNU gcc, and was failing left and right. sorry for the trouble! [2002-12-11 12:21:29] [EMAIL PROTECTED] I added the patch to zend_hash.h as specified in this bug: http://bugs.php.net/bug.php?id=15217, (adding #include to zend_hash.h), and the seemed to rectify my initial problems, however, now I am getting the following warnings: /home/ben/src/php4-STABLE-200212111430/TSRM/tsrm_virtual_cwd.h:159: warning: `struct utimbuf' declared inside parameter list /home/ben/src/php4-STABLE-200212111430/TSRM/tsrm_virtual_cwd.h:159: warning: its scope is only this definition or declaration, which is probably not what you want from a number of different files. [2002-12-11 10:59:38] [EMAIL PROTECTED] php4-STABLE-200212111430 red hat 8.0 gcc version 3.2.1 autoconf version 2.13-5 (downgraded from more-current 2.56-1) automake version 1.6.3-1 libtool version 1.4.3-2 zlib version 1.1.4-4 ./configure --with-pgsql --with-gd --with-apxs2=/usr/local/apache2/bin/apxs --enable-track-vars --enable-force-cgi-redirect --with-gettext --with-gd --with-dom --with-zlib-dir=/usr/lib --enable-cli i tried this configure/make with autoconf 2.56-1 first (on a freshly un-tarred php4-stable snap) and it failed as it had before. then after downgrading to the recommended autoconf 2.13 and doing a 'make distclean; ./buildconf', i was still receiving make errors as previously stated in this bug report. is this a gcc issue? i have tried the recommended build tools, but have not tried (nor wanted) to downgrade my gcc to get PHP to build. here is my make output with autoconf 2.13 [root@thelocust php4-STABLE-200212111430]# make /bin/sh libtool --silent --mode=compile gcc -Iext/zlib/ -I/home/ben/src/php4-STABLE-200212111430/ext/zlib/ -DPHP_ATOM_INC -I/home/ben/src/php4-STABLE-200212111430/include -I/home/ben/src/php4-STABLE-200212111430/main -I/home/ben/src/php4-STABLE-200212111430 -I/usr/local/apache2/include -I/home/ben/src/php4-STABLE-200212111430/Zend -I/usr/include/libxml2 -I/home/ben/src/php4-STABLE-200212111430/ext/xml/expat -I/home/ben/src/php4-STABLE-200212111430/TSRM -g -prefer-pic -c /home/ben/src/php4-STABLE-200212111430/ext/zlib/zlib.c -o ext/zlib/zlib.lo In file included from /home/ben/src/php4-STABLE-200212111430/Zend/zend.h:202, from /home/ben/src/php4-STABLE-200212111430/main/php.h:34, from /home/ben/src/php4-STABLE-200212111430/ext/zlib/zlib.c:28: /home/ben/src/php4-STABLE-200212111430/Zend/zend_hash.h:119: parse error before "va_list" In file included from /home/ben/src/php4-STABLE-200212111430/Zend/zend.h:203, from /home/ben/src/php4-STABLE-200212111430/main/php.h:34, from /home/ben/src/php4-STABLE-200212111430/ext/zlib/zlib.c:28: /home/ben/src/php4-STABLE-200212111430/Zend/zend_llist.h:34: parse error before "va_list" In file included from /home/ben/src/php4-STABLE-200212111430/main/php.h:34, from /home/ben/src/php4-STABLE-200212111430/ext/zlib/zlib.c:28: /home/ben/src/php4-STABLE-200212111430/Zend/zend.h:285: parse error before "va_list" /home/ben/src/php4-STABLE-200212111430/Zend/zend.h:423: parse error before "va_list" In file included from /home/ben/src/php4-STABLE-200212111430/main/php.h:224, from /home/ben/src/php4-STABLE-200212111430/ext/zlib/zlib.c:28: /home/ben/src/php4-STABLE-200212111430/main/spprintf.h:40: parse error before "va_list" In file included from /home/ben/src/php4-STABLE-200212111430/ext/zlib/zlib.c:28: /home/ben/src/php4-STABLE-200212111430/main/php.h:277: parse error before "va_list" In file included from /home/ben/src/php4-STABLE-200212111430/main/php.h:360, from /home/ben/src/php4-STABLE-200212111430/ext/zlib/zlib.c:28: /home/ben/src/php4-STABLE-200212111430/TSRM/tsrm_virtual_cwd.h:159: warning: `struct utimbuf' declared inside parameter list /home/ben/src/php4-STABLE-200212111430/TSRM/tsrm_virtual_cwd.h:159: warning: its scope is only this definition or declaration, which is probably not what you want In file included from /home/ben/src/php4-STABLE-200212111430/ext/standard/php_standard.h:23, from /home/ben/src/php4-STABLE-200212111430/ext/zlib/zlib.c:48: /home/ben/
#20988 [Opn->Fbk]: Apache segfaults using MM session on garbage collection
ID: 20988 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Session related Operating System: Linux 2.4.19 (Debian) PHP Version: 4.3.0RC3 New Comment: Before this backtrace, GDB should have spit out an error too with a source line, can you please paste that one in the form, and also the result of: print data and print sd (at the same place as were you typed 'bt'). thanks! Derick Previous Comments: [2002-12-13 08:20:18] [EMAIL PROTECTED] Managed to get backtrace on FreeBSD box: #0 0x48287655 in ps_sd_destroy (data=0x811b0a0, sd=0x4c6c2354) at mod_mm.c:168 #1 0x4828784f in ps_mm_destroy (data=0x811b0a0) at mod_mm.c:242 #2 0x48287a25 in zm_shutdown_ps_mm (type=1, module_number=11) at mod_mm.c:293 #3 0x48231e93 in module_destructor (module=0x811c500) at zend_API.c:1127 #4 0x482338d3 in zend_hash_destroy (ht=0x48333b80) at zend_hash.c:541 #5 0x4822ef3f in zend_shutdown () at zend.c:492 #6 0x4823c107 in php_module_shutdown () at main.c:1052 #7 0x4823c0d4 in php_module_shutdown_wrapper (sapi_globals=0x48311880) at main.c:1029 #8 0x48239abc in apache_php_module_shutdown_wrapper () at mod_php4.c:800 #9 0x805003a in run_cleanups () #10 0x804f09f in ap_clear_pool () #11 0x804f100 in ap_destroy_pool () #12 0x804f08b in ap_clear_pool () #13 0x804f100 in ap_destroy_pool () #14 0x8059460 in clean_parent_exit () #15 0x805b925 in standalone_main () #16 0x805bd6b in main () #17 0x804eb0d in _start () [2002-12-13 07:57:20] [EMAIL PROTECTED] While trying to backtrace a particular forked child it would not segfault until i detach gdb from it - then it segfaults with: [Sat Dec 14 05:02:19 2002] [notice] child pid 4858 exit signal Segmentation fault (11) [2002-12-13 07:34:33] [EMAIL PROTECTED] I know it's not a backtrace. I have just forgot to paste apache log segfault line example in my original posting. However. When trying to backtrace I cannot reproduce this behavior. It's happening under constant heavy load that can be simulated using ab -n 1 and the example script I have supplied. Only after about 3000-4000 request this one happens. I cannot execute 3000 request because httpd -X exits after several hundred requests (normal exit - no backtrace) and I don't know why. [2002-12-13 07:01:55] [EMAIL PROTECTED] That is not a back trace, please follow the instructions as described here: http://bugs.php.net/bugs-generating-backtrace.php [2002-12-13 07:00:15] [EMAIL PROTECTED] Apache segfault log entry: [Sat Dec 14 03:41:39 2002] [notice] child pid 3613 exit signal Segmentation fault (11) 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/20988 -- Edit this bug report at http://bugs.php.net/?id=20988&edit=1
#20988 [Opn]: Apache segfaults using MM session on garbage collection
ID: 20988 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Session related Operating System: Linux 2.4.19 (Debian) PHP Version: 4.3.0RC3 New Comment: Managed to get backtrace on FreeBSD box: #0 0x48287655 in ps_sd_destroy (data=0x811b0a0, sd=0x4c6c2354) at mod_mm.c:168 #1 0x4828784f in ps_mm_destroy (data=0x811b0a0) at mod_mm.c:242 #2 0x48287a25 in zm_shutdown_ps_mm (type=1, module_number=11) at mod_mm.c:293 #3 0x48231e93 in module_destructor (module=0x811c500) at zend_API.c:1127 #4 0x482338d3 in zend_hash_destroy (ht=0x48333b80) at zend_hash.c:541 #5 0x4822ef3f in zend_shutdown () at zend.c:492 #6 0x4823c107 in php_module_shutdown () at main.c:1052 #7 0x4823c0d4 in php_module_shutdown_wrapper (sapi_globals=0x48311880) at main.c:1029 #8 0x48239abc in apache_php_module_shutdown_wrapper () at mod_php4.c:800 #9 0x805003a in run_cleanups () #10 0x804f09f in ap_clear_pool () #11 0x804f100 in ap_destroy_pool () #12 0x804f08b in ap_clear_pool () #13 0x804f100 in ap_destroy_pool () #14 0x8059460 in clean_parent_exit () #15 0x805b925 in standalone_main () #16 0x805bd6b in main () #17 0x804eb0d in _start () Previous Comments: [2002-12-13 07:57:20] [EMAIL PROTECTED] While trying to backtrace a particular forked child it would not segfault until i detach gdb from it - then it segfaults with: [Sat Dec 14 05:02:19 2002] [notice] child pid 4858 exit signal Segmentation fault (11) [2002-12-13 07:34:33] [EMAIL PROTECTED] I know it's not a backtrace. I have just forgot to paste apache log segfault line example in my original posting. However. When trying to backtrace I cannot reproduce this behavior. It's happening under constant heavy load that can be simulated using ab -n 1 and the example script I have supplied. Only after about 3000-4000 request this one happens. I cannot execute 3000 request because httpd -X exits after several hundred requests (normal exit - no backtrace) and I don't know why. [2002-12-13 07:01:55] [EMAIL PROTECTED] That is not a back trace, please follow the instructions as described here: http://bugs.php.net/bugs-generating-backtrace.php [2002-12-13 07:00:15] [EMAIL PROTECTED] Apache segfault log entry: [Sat Dec 14 03:41:39 2002] [notice] child pid 3613 exit signal Segmentation fault (11) [2002-12-13 06:56:27] [EMAIL PROTECTED] of course there should be: semicolon missing 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/20988 -- Edit this bug report at http://bugs.php.net/?id=20988&edit=1
#20989 [Opn->Fbk]: URL variable without = affects other URL variable
ID: 20989 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: *URL Functions Operating System: Linux PHP Version: 4.2.2 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip Previous Comments: [2002-12-13 08:16:24] [EMAIL PROTECTED] ?a&b&c=3&d=4&e=5 This results in HTTP_GET_VARS: a= b= c=3 The variables d and e are missing. For each variable without = it deletes a variable at the end. -- Edit this bug report at http://bugs.php.net/?id=20989&edit=1
#20989 [NEW]: URL variable without = affects other URL variable
From: [EMAIL PROTECTED] Operating system: Linux PHP version: 4.2.2 PHP Bug Type: *URL Functions Bug description: URL variable without = affects other URL variable ?a&b&c=3&d=4&e=5 This results in HTTP_GET_VARS: a= b= c=3 The variables d and e are missing. For each variable without = it deletes a variable at the end. -- Edit bug report at http://bugs.php.net/?id=20989&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20989&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20989&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20989&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20989&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20989&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20989&r=support Expected behavior: http://bugs.php.net/fix.php?id=20989&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20989&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20989&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20989&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20989&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20989&r=dst IIS Stability: http://bugs.php.net/fix.php?id=20989&r=isapi
#20546 [Com]: compile with gcc 3.2 fails due to parser errors
ID: 20546 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Compile Failure Operating System: RedHat Linux 8.0 PHP Version: 4.3.0-dev New Comment: i finally found out what was wrong -- i was missing 'cpp0', which apparently was not required by the Redhat Rawhide gcc packages as it should have been. without it, the configure script assumed that i wasn't using GNU gcc, and was failing left and right. sorry for the trouble! Previous Comments: [2002-12-11 12:21:29] [EMAIL PROTECTED] I added the patch to zend_hash.h as specified in this bug: http://bugs.php.net/bug.php?id=15217, (adding #include to zend_hash.h), and the seemed to rectify my initial problems, however, now I am getting the following warnings: /home/ben/src/php4-STABLE-200212111430/TSRM/tsrm_virtual_cwd.h:159: warning: `struct utimbuf' declared inside parameter list /home/ben/src/php4-STABLE-200212111430/TSRM/tsrm_virtual_cwd.h:159: warning: its scope is only this definition or declaration, which is probably not what you want from a number of different files. [2002-12-11 10:59:38] [EMAIL PROTECTED] php4-STABLE-200212111430 red hat 8.0 gcc version 3.2.1 autoconf version 2.13-5 (downgraded from more-current 2.56-1) automake version 1.6.3-1 libtool version 1.4.3-2 zlib version 1.1.4-4 ./configure --with-pgsql --with-gd --with-apxs2=/usr/local/apache2/bin/apxs --enable-track-vars --enable-force-cgi-redirect --with-gettext --with-gd --with-dom --with-zlib-dir=/usr/lib --enable-cli i tried this configure/make with autoconf 2.56-1 first (on a freshly un-tarred php4-stable snap) and it failed as it had before. then after downgrading to the recommended autoconf 2.13 and doing a 'make distclean; ./buildconf', i was still receiving make errors as previously stated in this bug report. is this a gcc issue? i have tried the recommended build tools, but have not tried (nor wanted) to downgrade my gcc to get PHP to build. here is my make output with autoconf 2.13 [root@thelocust php4-STABLE-200212111430]# make /bin/sh libtool --silent --mode=compile gcc -Iext/zlib/ -I/home/ben/src/php4-STABLE-200212111430/ext/zlib/ -DPHP_ATOM_INC -I/home/ben/src/php4-STABLE-200212111430/include -I/home/ben/src/php4-STABLE-200212111430/main -I/home/ben/src/php4-STABLE-200212111430 -I/usr/local/apache2/include -I/home/ben/src/php4-STABLE-200212111430/Zend -I/usr/include/libxml2 -I/home/ben/src/php4-STABLE-200212111430/ext/xml/expat -I/home/ben/src/php4-STABLE-200212111430/TSRM -g -prefer-pic -c /home/ben/src/php4-STABLE-200212111430/ext/zlib/zlib.c -o ext/zlib/zlib.lo In file included from /home/ben/src/php4-STABLE-200212111430/Zend/zend.h:202, from /home/ben/src/php4-STABLE-200212111430/main/php.h:34, from /home/ben/src/php4-STABLE-200212111430/ext/zlib/zlib.c:28: /home/ben/src/php4-STABLE-200212111430/Zend/zend_hash.h:119: parse error before "va_list" In file included from /home/ben/src/php4-STABLE-200212111430/Zend/zend.h:203, from /home/ben/src/php4-STABLE-200212111430/main/php.h:34, from /home/ben/src/php4-STABLE-200212111430/ext/zlib/zlib.c:28: /home/ben/src/php4-STABLE-200212111430/Zend/zend_llist.h:34: parse error before "va_list" In file included from /home/ben/src/php4-STABLE-200212111430/main/php.h:34, from /home/ben/src/php4-STABLE-200212111430/ext/zlib/zlib.c:28: /home/ben/src/php4-STABLE-200212111430/Zend/zend.h:285: parse error before "va_list" /home/ben/src/php4-STABLE-200212111430/Zend/zend.h:423: parse error before "va_list" In file included from /home/ben/src/php4-STABLE-200212111430/main/php.h:224, from /home/ben/src/php4-STABLE-200212111430/ext/zlib/zlib.c:28: /home/ben/src/php4-STABLE-200212111430/main/spprintf.h:40: parse error before "va_list" In file included from /home/ben/src/php4-STABLE-200212111430/ext/zlib/zlib.c:28: /home/ben/src/php4-STABLE-200212111430/main/php.h:277: parse error before "va_list" In file included from /home/ben/src/php4-STABLE-200212111430/main/php.h:360, from /home/ben/src/php4-STABLE-200212111430/ext/zlib/zlib.c:28: /home/ben/src/php4-STABLE-200212111430/TSRM/tsrm_virtual_cwd.h:159: warning: `struct utimbuf' declared inside parameter list /home/ben/src/php4-STABLE-200212111430/TSRM/tsrm_virtual_cwd.h:159: warning: its scope is only this definition or declaration, which is probably not what you want In file included from /home/ben/src/php4-STABLE-200212111430/ext/standard/php_standard.h:23, from /home/ben/src/php4-STABLE-200212111430/ext/zlib/zlib.c:48: /home/ben/src/php4-STABLE-200212111430/ext/standard/php_string.h: In function `php_memnstr': /home/ben/src/php4-STABLE-200212111430/ext
#20968 [Opn->Bgs]: Session rewriter misses a case
ID: 20968 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Session related Operating System: Windows 2000 PHP Version: 4.2.3 New Comment: It is intentional Previous Comments: [2002-12-13 08:03:15] [EMAIL PROTECTED] The javascript is generated code from a product by a dll. I have no access to modifying the html. The only workaround I have is to not use trans sid. But then clients without cookies cannot access it. I do not believe this behavior is intentional. Charles [2002-12-13 03:02:01] [EMAIL PROTECTED] Use single quotes in your script. Not a bug. [2002-12-12 12:29:44] [EMAIL PROTECTED] The cvs behaves differently but still the same error str += ""; It doesnt put quotes around the reptoc but it still puts bad quotes around the type="hidden" and others. Charles [2002-12-12 11:49:02] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-12-12 11:42:10] [EMAIL PROTECTED] Whe html is written with javascript and trans sid is used, The javascript may get messed up. ie str += "
#20968 [Bgs->Opn]: Session rewriter misses a case
ID: 20968 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Bogus +Status: Open Bug Type: Session related Operating System: Windows 2000 PHP Version: 4.2.3 New Comment: The javascript is generated code from a product by a dll. I have no access to modifying the html. The only workaround I have is to not use trans sid. But then clients without cookies cannot access it. I do not believe this behavior is intentional. Charles Previous Comments: [2002-12-13 03:02:01] [EMAIL PROTECTED] Use single quotes in your script. Not a bug. [2002-12-12 12:29:44] [EMAIL PROTECTED] The cvs behaves differently but still the same error str += ""; It doesnt put quotes around the reptoc but it still puts bad quotes around the type="hidden" and others. Charles [2002-12-12 11:49:02] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-12-12 11:42:10] [EMAIL PROTECTED] Whe html is written with javascript and trans sid is used, The javascript may get messed up. ie str += "
#20988 [Opn]: Apache segfaults using MM session on garbage collection
ID: 20988 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Session related Operating System: Linux 2.4.19 (Debian) PHP Version: 4.3.0RC3 New Comment: While trying to backtrace a particular forked child it would not segfault until i detach gdb from it - then it segfaults with: [Sat Dec 14 05:02:19 2002] [notice] child pid 4858 exit signal Segmentation fault (11) Previous Comments: [2002-12-13 07:34:33] [EMAIL PROTECTED] I know it's not a backtrace. I have just forgot to paste apache log segfault line example in my original posting. However. When trying to backtrace I cannot reproduce this behavior. It's happening under constant heavy load that can be simulated using ab -n 1 and the example script I have supplied. Only after about 3000-4000 request this one happens. I cannot execute 3000 request because httpd -X exits after several hundred requests (normal exit - no backtrace) and I don't know why. [2002-12-13 07:01:55] [EMAIL PROTECTED] That is not a back trace, please follow the instructions as described here: http://bugs.php.net/bugs-generating-backtrace.php [2002-12-13 07:00:15] [EMAIL PROTECTED] Apache segfault log entry: [Sat Dec 14 03:41:39 2002] [notice] child pid 3613 exit signal Segmentation fault (11) [2002-12-13 06:56:27] [EMAIL PROTECTED] of course there should be: semicolon missing [2002-12-13 06:55:24] [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. 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/20988 -- Edit this bug report at http://bugs.php.net/?id=20988&edit=1
#17826 [Com]: PHP 4.2.1 Apache SAPI is not compatible with Apache 2.0.39
ID: 17826 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: Apache2 related Operating System: Win32 PHP Version: 4.2.1 Assigned To: edink New Comment: OK, corrected thanks to Edin: # There is link on the front page: # # http://snaps.php.net/~edink/php-4.3.0RC3-Win32.zip # # Edin Vince Previous Comments: [2002-12-13 05:18:29] [EMAIL PROTECTED] Hi, Despite having done exactly what is explained in "[23 Oct 8:52pm] [EMAIL PROTECTED]" in this bug list, I still have "cannot load php4apache2.dll into server - The specified procedure cannot be found". Versions of apache and php are the same. The only thing is that I'm using Windows XP Pro SP1 with all windows updates... Download of php4-win32-STABLE-latest.zip was made today (buggy version?) What's wrong??? Do I have to put php4ts.dll into the register datas??? DO I miss any specific XP Pro procedure? I spent 3 hours on this and it still doesn't work. Urgent help needed plz. Thanks in advance. Vince [2002-12-07 11:18:22] [EMAIL PROTECTED] When I use the SAPI DLL for PHP on W2K and Apache 2.0.43, I get nothing. :( No errors anywhere I can see, but also no php processing. I know it's 'supposed' to be buggy, but I get nothing - not even an error. I can load a .php page, but everything between the shows up in the page source. If I use php-cgi.exe instead of php4apache2.dll, my pages work. But I have an urgent need for the virtual() function and this only works in the dll version of php. Using apache -k start there are no errors. There are also no errors in error.log. I've set php.ini to report errors, but there aren't ever any. Anyone got an idea? My httpd.conf contains: # PHP LoadModule php4_module c:/php/sapi/php4apache2.dll #AddModule mod_php4.c AddType application/x-httpd-php .phtml .php .php3 .php4 .html I've commented out the AddModule line for 2 reasons. One is that I have no module called mod_php4.c - the other reason is that the docs say that it's not required in the newer versions of Apache, especially Apache 2. Bob Kramer [2002-11-13 06:51:20] [EMAIL PROTECTED] Thank you The post: [11 Oct 2:17pm] [EMAIL PROTECTED] did the trick for me. I had some problems that are explained at the http://bugs.php.net/bug.php?id=16575 page (read the mcdragon posts in november) The trick with the latest (stable) snaps worked. I used the php4apache2.dll and the php4ts.dll Interesting! I took the PHP download and the SNAP in the same day and the first had the modified date at the begin of sept 2002 and the snap had november 13th 2002 (TODAY). In any case, thanks KRONUZ for the great help :-))) [2002-11-10 17:51:19] [EMAIL PROTECTED] FYI - The files referenced above are back online. Thanks, imajes, for your quick response! [2002-11-10 13:28:47] [EMAIL PROTECTED] snaps has moved server, and win32 snaps haven't been uploaded yet. please bear with us as we fix this. Thanks 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/17826 -- Edit this bug report at http://bugs.php.net/?id=17826&edit=1
#20985 [Fbk->Opn]: heavy load = Segmentation fault
ID: 20985 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: Reproducible crash Operating System: Redhat Linux 7.3 & 8 PHP Version: 4.3.0RC3 New Comment: [root@spinaker root]# gdb /usr/local/apache/bin/httpd GNU gdb Red Hat Linux (5.2-2) 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-redhat-linux"... (no debugging symbols found)... (gdb) run -X Starting program: /usr/local/apache/bin/httpd -X (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... Program received signal SIGSEGV, Segmentation fault. 0x401ac9af in memcpy () from /lib/libc.so.6 (gdb) bt #0 0x401ac9af in memcpy () from /lib/libc.so.6 #1 0x0810c512 in _mem_block_check () #2 0x0810c4d5 in _mem_block_check () #3 0x0810b72f in _efree () #4 0x0811af00 in _zval_dtor () #5 0x08111d0a in free_zend_constant () #6 0x0812167d in zend_hash_del_key_or_index () #7 0x08121f38 in zend_hash_reverse_apply () #8 0x08112113 in clean_non_persistent_constants () #9 0x0811290c in shutdown_executor () #10 0x0811c0c6 in zend_deactivate () #11 0x08079fbc in php_request_shutdown () #12 0x08127e82 in apache_php_module_main () #13 0x080774dc in php_restore_umask () #14 0x08077535 in php_restore_umask () #15 0x08149dc3 in ap_invoke_handler () #16 0x0815ed47 in ap_some_auth_required () #17 0x0815f16b in ap_internal_redirect () #18 0x0806bc3c in ap_get_server_built () #19 0x08149dc3 in ap_invoke_handler () #20 0x0815ed47 in ap_some_auth_required () #21 0x0815eda8 in ap_process_request () #22 0x08155be5 in ap_child_terminate () ---Type to continue, or q to quit--- #23 0x08155d90 in ap_child_terminate () #24 0x08155f04 in ap_child_terminate () #25 0x0815657c in ap_child_terminate () #26 0x08156ddf in main () #27 0x401481c4 in __libc_start_main () from /lib/libc.so.6 (gdb) Previous Comments: [2002-12-13 04:06:11] [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. [2002-12-13 03:55:57] [EMAIL PROTECTED] I have tested this on different machines, so I do not think that this is a hardware error. [2002-12-13 03:49:42] [EMAIL PROTECTED] I get these errors on both Redhat Linux 7.3 & 8 [2002-12-13 03:47:42] [EMAIL PROTECTED] [Fri Dec 13 10:17:36 2002] [notice] child pid 15954 exit signal Segmentation fault (11) I get several lines like the above when I have heavy load on the server. This also happens whith php 4.2.3 In the test i used: Compaq P4 1.6ghz, 256mb ram Redhat Linux 7.3, kernel 2.4.18-18.8.0 Apache 1.3.27 Php 4.3.0RC3 & 4.2.3 MySQL 4.0.5a Stress tool: http://webtool.rte.microsoft.com/ I configured php like this: ./configure --with-apache=../apache-1.3.27 --with-mysql=/usr --enable-trans-sid --enable-inline-optimization --without-pear 'make test' made no errors. Please let me know what I can do to help you fix this bug. -- Edit this bug report at http://bugs.php.net/?id=20985&edit=1
#20988 [Fbk->Opn]: Apache segfaults using MM session on garbage collection
ID: 20988 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: Session related Operating System: Linux 2.4.19 (Debian) PHP Version: 4.3.0RC3 New Comment: I know it's not a backtrace. I have just forgot to paste apache log segfault line example in my original posting. However. When trying to backtrace I cannot reproduce this behavior. It's happening under constant heavy load that can be simulated using ab -n 1 and the example script I have supplied. Only after about 3000-4000 request this one happens. I cannot execute 3000 request because httpd -X exits after several hundred requests (normal exit - no backtrace) and I don't know why. Previous Comments: [2002-12-13 07:01:55] [EMAIL PROTECTED] That is not a back trace, please follow the instructions as described here: http://bugs.php.net/bugs-generating-backtrace.php [2002-12-13 07:00:15] [EMAIL PROTECTED] Apache segfault log entry: [Sat Dec 14 03:41:39 2002] [notice] child pid 3613 exit signal Segmentation fault (11) [2002-12-13 06:56:27] [EMAIL PROTECTED] of course there should be: semicolon missing [2002-12-13 06:55:24] [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. [2002-12-13 06:54:22] [EMAIL PROTECTED] Apache 1.3.27 PHP 4.3.0RC3: Configure Command => './configure' '--with-mysql' '--with-dom' '--with-dom-xslt' '--with-apxs=/usr/bin/apxs' '--with-zlib' '--with-mm' This can be reproduced by a script: in php.ini set garbage collection to be called often and set MM session handler: session.save_handler = mm session.gc_probability = 1 session.gc_dividend= 1 session.gc_maxlifetime = 30 To reproduce run: ab -n 1 http://server/above_script.php Note that this bug is also reproducible on FreeBSD with php 4.3.2 - will not post another bug report. -- Edit this bug report at http://bugs.php.net/?id=20988&edit=1
#20969 [Ver->Bgs]: Bitwise NOT (~): wrong results on Linux
ID: 20969 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Verified +Status: Bogus Bug Type: *Math Functions Operating System: i386 Redhat Linux PHP Version: 4CVS-20021213 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 This behaviour is mentioned in the manual. See http://www.php.net/manual/en/language.types.integer.php#language.types.integer.casting Previous Comments: [2002-12-12 14:45:31] [EMAIL PROTECTED] Although bitwise operators are not expected to use with float values, the reported behaviour is quite inconsistent. Possible documentation problem? [2002-12-12 12:39:39] [EMAIL PROTECTED] The Bitwise NOT operator ~ doesn't fuinction correctly on the Linux system. Examples: ~-22 = 2147483647 ~4180982798 = 2147483647 But on a Windows 2000 Server it functions well: ~-22 = -2072745075 ~4180982798 = 113984497 On both systems PHP 4.2.2 is used. If that's a "feature" then PHP is not usable for any bitwise operation. -- Edit this bug report at http://bugs.php.net/?id=20969&edit=1
#20802 [Com]: memory limit crash
ID: 20802 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Critical Bug Type: Scripting Engine problem Operating System: Redhat 7.0 PHP Version: 4.3.0RC2 New Comment: I'm having the same problem with PHP 4.3RC3 with Apache 2.0.43 running with the perchild MPM. After the crash occours, apache does not accept any more connections, even though there are other processes that could handle them, and I'm required to restart it. Here are some outputs from ps and top, before and after the crash, perhaps it will be usefull with something: /* I've pasted only the part that shows the "root" process, and a single child with its accompanying threads; there are 4 more children (with their threads), but they are similar and their state doesn't change */ (1) "ps ax --forest" before 3541 ?S 0:00 /opt/httpd-2.0.43/bin/httpd -k start 3542 ?S 0:00 \_ /opt/httpd-2.0.43/bin/httpd -k start 3545 ?S 0:00 | \_ /opt/httpd-2.0.43/bin/httpd -k start 3546 ?S 0:38 | \_ /opt/httpd-2.0.43/bin/httpd -k start 3549 ?S 0:00 | \_ /opt/httpd-2.0.43/bin/httpd -k start 3550 ?S 0:00 | \_ /opt/httpd-2.0.43/bin/httpd -k start 3556 ?S 0:00 | \_ /opt/httpd-2.0.43/bin/httpd -k start 3561 ?S 0:00 | \_ /opt/httpd-2.0.43/bin/httpd -k start 3578 ?S 0:00 | \_ /opt/httpd-2.0.43/bin/httpd -k start (2) "ps ax --forest" before 3541 ?S 0:00 /opt/httpd-2.0.43/bin/httpd -k start 3542 ?S 0:00 \_ /opt/httpd-2.0.43/bin/httpd -k start 3545 ?Z 0:00 | \_ [httpd ] (3) "top" output after the crash PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ Command PPID nFLT nDRT WCHAN Flags 3542 httpd 9 0 58028 56m 4972 S 0.0 7.5 0:00.00 /opt/httpd- 35411 13k rt_sigsus .14. 3545 httpd 8 0 000 Z 0.0 0.0 0:00.04 ( httpd , argc=3, argv=0xbfffe944, init=0x80792f8 <_init>, fini=0x826c8f4 <_fini>, rtld_fini=0x4000a914 <_dl_fini>, stack_end=0xbfffe93c) at ../sysdeps/generic/libc-start.c:92 [2002-12-04 00:33:07] [EMAIL PROTECTED] Veryfied with PHP 4.4.0-dev (Nov 29 2002) and PHP 4.3.0-dev (Nov 25 2002). With both versions the script just ended without any error message, but there is no segmentation fault. Derick [2002-12-03 16:12:50] [EMAIL PROTECTED] I have a php installation with a memory limit set to 8MB. If I try to run this script I don't receive an error like "memory limit excedeed" (10MB > 8MB), simply the server kills the connection without any error on the screen or in the logs. Server configuration: Linux Redhat 7.0 Apache 1.3.22 PHP 4.3.0RC2 Zend Optimizer 2.0.3 Mysql 4.0.5 Configure: './configure' '--enable-track-vars' '--prefix=/usr' '--exec-prefix=/usr' '--libexecdir=/usr/lib/apache' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--datadir=/home/httpd' '--sysconfdir=/etc/httpd/conf' '--localstatedir=/var' '--libdir=/usr/lib/apache' '--includedir=/usr/include/apache' '--mandir=/usr/man' '--with-mysql=/usr' '--enable-memory-limit' '--with-config-file-path=/usr/local/Zend/etc' '--with-apxs' '--with-zlib' -- Edit this bug report at http://bugs.php.net/?id=20802&edit=1
#20979 [Fbk->Opn]: sendmail_from,SMTP and other valuse in php.ini not being read...
ID: 20979
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Open
Bug Type: IIS related
Operating System: Windows XP Pro.
PHP Version: 4CVS-2002-12-12 (dev)
New Comment:
unfortunately I am sure, I checked it in the command prompt as well as
looking in the folder in windows explorer, before I posted this report
I turned on "show extensions for known file types" the minute I
installed XP.
I do wish the solutions was something that simple though :)
As of tonight I will just write a new file and include it in all my PHP
scripts with all the php.ini settings as ini_set("X","X"); commands
which should work fine, just that it is rather tedious.
I am curious, is there a way I can use the "enable document footer"
feature in iis to add this file automatically to only .PHP files?
-Andrew
Previous Comments:
[2002-12-13 02:31:32] [EMAIL PROTECTED]
Are you absolutely sure that the php.ini is not in fact 'php.ini.ini'
like happened in #20753 ?
[2002-12-12 20:55:16] [EMAIL PROTECTED]
I know that this problem has been reported before...
in fact many many times before, but I have tried other peoples
solutions to it with no success.
I recently recieved this error from the "Phorm" Script, an excelent
form processor/result-emailing
script with tons of features:
here is a link to it on my server:
http://67.80.121.68:8001/feedback.htm
(this site is just a mock up desgin I made for a me and my friend's
joke company btw :)
ERROR
090 - There has been an error, and your information has not been sent.
Alerts:
105 - Mail function failed on user email for template
./feedbackemail.txt.
105P: "sendmail_from" not set in php.ini or custom "From:" header
missing
111 - Mail function failed on sending alerts.
111P: "sendmail_from" not set in php.ini or custom "From:" header
missing
after reading this is checked my php.ini file for my 'SMTP', and
'sendmail_from' settings:
they were correct plus the fact that the phorm script provides a from
address on its own.
so to amuse myself I simply retyped my SMTP and sendmail_from settings
then resaved the file.
I then restarted IIS' services and tried again and recieved the same
error.
next, restarted the whole machine tried again and got the same error.
at this point, somewhat annoyed, I made a file doh.php with being its only contents
browsed to it in my web browser:
http://67.80.121.68:8001/sharedocs/doh.php
and it shows that my path for php.ini is correct, but shows:
Directive | Local Value | Master Value
sendmail_from | no value | no value
SMTP | localhost | localhost
next as a test I added the following lines to doh.php:
ini_set("SMTP","mail-hub.optonline.net");
ini_set("sendmail_from","[EMAIL PROTECTED]");
mail("[EMAIL PROTECTED]","testing","testing");
this worked and I recieved an email... also phpinfo() showed the
following:
Directive | Local Value | Master Value
sendmail_from | [EMAIL PROTECTED] | no value
SMTP | mail-hub.optonline.net | localhost
At this point I have no idea what to do in order to not have to ad
ini_set() commands
to all of my emailing php scripts
any explanations would be extremely appreciated.
PS: i understand that this is a duplicate report and am sorry
also: i am running ASP, ActivePERL, and PHP under iis. as well as a
mysql server.
could something in that combo be causing this problem?
-best reguards
Andrew
--
Edit this bug report at http://bugs.php.net/?id=20979&edit=1
#20988 [Opn->Fbk]: Apache segfaults using MM session on garbage collection
ID: 20988 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Session related Operating System: Linux 2.4.19 (Debian) PHP Version: 4.3.0RC3 New Comment: That is not a back trace, please follow the instructions as described here: http://bugs.php.net/bugs-generating-backtrace.php Previous Comments: [2002-12-13 07:00:15] [EMAIL PROTECTED] Apache segfault log entry: [Sat Dec 14 03:41:39 2002] [notice] child pid 3613 exit signal Segmentation fault (11) [2002-12-13 06:56:27] [EMAIL PROTECTED] of course there should be: semicolon missing [2002-12-13 06:55:24] [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. [2002-12-13 06:54:22] [EMAIL PROTECTED] Apache 1.3.27 PHP 4.3.0RC3: Configure Command => './configure' '--with-mysql' '--with-dom' '--with-dom-xslt' '--with-apxs=/usr/bin/apxs' '--with-zlib' '--with-mm' This can be reproduced by a script: in php.ini set garbage collection to be called often and set MM session handler: session.save_handler = mm session.gc_probability = 1 session.gc_dividend= 1 session.gc_maxlifetime = 30 To reproduce run: ab -n 1 http://server/above_script.php Note that this bug is also reproducible on FreeBSD with php 4.3.2 - will not post another bug report. -- Edit this bug report at http://bugs.php.net/?id=20988&edit=1
#20988 [Fbk->Opn]: Apache segfaults using MM session on garbage collection
ID: 20988 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: Session related Operating System: Linux 2.4.19 (Debian) PHP Version: 4.3.0RC3 New Comment: Apache segfault log entry: [Sat Dec 14 03:41:39 2002] [notice] child pid 3613 exit signal Segmentation fault (11) Previous Comments: [2002-12-13 06:56:27] [EMAIL PROTECTED] of course there should be: semicolon missing [2002-12-13 06:55:24] [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. [2002-12-13 06:54:22] [EMAIL PROTECTED] Apache 1.3.27 PHP 4.3.0RC3: Configure Command => './configure' '--with-mysql' '--with-dom' '--with-dom-xslt' '--with-apxs=/usr/bin/apxs' '--with-zlib' '--with-mm' This can be reproduced by a script: in php.ini set garbage collection to be called often and set MM session handler: session.save_handler = mm session.gc_probability = 1 session.gc_dividend= 1 session.gc_maxlifetime = 30 To reproduce run: ab -n 1 http://server/above_script.php Note that this bug is also reproducible on FreeBSD with php 4.3.2 - will not post another bug report. -- Edit this bug report at http://bugs.php.net/?id=20988&edit=1
#20988 [Opn->Fbk]: Apache segfaults using MM session on garbage collection
ID: 20988 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Session related Operating System: Linux 2.4.19 (Debian) PHP Version: 4.3.0RC3 Previous Comments: [2002-12-13 06:56:27] [EMAIL PROTECTED] of course there should be: semicolon missing [2002-12-13 06:55:24] [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. [2002-12-13 06:54:22] [EMAIL PROTECTED] Apache 1.3.27 PHP 4.3.0RC3: Configure Command => './configure' '--with-mysql' '--with-dom' '--with-dom-xslt' '--with-apxs=/usr/bin/apxs' '--with-zlib' '--with-mm' This can be reproduced by a script: in php.ini set garbage collection to be called often and set MM session handler: session.save_handler = mm session.gc_probability = 1 session.gc_dividend= 1 session.gc_maxlifetime = 30 To reproduce run: ab -n 1 http://server/above_script.php Note that this bug is also reproducible on FreeBSD with php 4.3.2 - will not post another bug report. -- Edit this bug report at http://bugs.php.net/?id=20988&edit=1
#20988 [Fbk->Opn]: Apache segfaults using MM session on garbage collection
ID: 20988 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: Session related Operating System: Linux 2.4.19 (Debian) PHP Version: 4.3.0RC3 New Comment: of course there should be: semicolon missing Previous Comments: [2002-12-13 06:55:24] [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. [2002-12-13 06:54:22] [EMAIL PROTECTED] Apache 1.3.27 PHP 4.3.0RC3: Configure Command => './configure' '--with-mysql' '--with-dom' '--with-dom-xslt' '--with-apxs=/usr/bin/apxs' '--with-zlib' '--with-mm' This can be reproduced by a script: in php.ini set garbage collection to be called often and set MM session handler: session.save_handler = mm session.gc_probability = 1 session.gc_dividend= 1 session.gc_maxlifetime = 30 To reproduce run: ab -n 1 http://server/above_script.php Note that this bug is also reproducible on FreeBSD with php 4.3.2 - will not post another bug report. -- Edit this bug report at http://bugs.php.net/?id=20988&edit=1
#20988 [Opn->Fbk]: Apache segfaults using MM session on garbage collection
ID: 20988 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Session related Operating System: Linux 2.4.19 (Debian) PHP Version: 4.3.0RC3 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: [2002-12-13 06:54:22] [EMAIL PROTECTED] Apache 1.3.27 PHP 4.3.0RC3: Configure Command => './configure' '--with-mysql' '--with-dom' '--with-dom-xslt' '--with-apxs=/usr/bin/apxs' '--with-zlib' '--with-mm' This can be reproduced by a script: in php.ini set garbage collection to be called often and set MM session handler: session.save_handler = mm session.gc_probability = 1 session.gc_dividend= 1 session.gc_maxlifetime = 30 To reproduce run: ab -n 1 http://server/above_script.php Note that this bug is also reproducible on FreeBSD with php 4.3.2 - will not post another bug report. -- Edit this bug report at http://bugs.php.net/?id=20988&edit=1
#20988 [NEW]: Apache segfaults using MM session on garbage collection
From: [EMAIL PROTECTED] Operating system: Linux 2.4.19 (Debian) PHP version: 4.3.0RC3 PHP Bug Type: Session related Bug description: Apache segfaults using MM session on garbage collection Apache 1.3.27 PHP 4.3.0RC3: Configure Command => './configure' '--with-mysql' '--with-dom' '--with-dom-xslt' '--with-apxs=/usr/bin/apxs' '--with-zlib' '--with-mm' This can be reproduced by a script: in php.ini set garbage collection to be called often and set MM session handler: session.save_handler = mm session.gc_probability = 1 session.gc_dividend= 1 session.gc_maxlifetime = 30 To reproduce run: ab -n 1 http://server/above_script.php Note that this bug is also reproducible on FreeBSD with php 4.3.2 - will not post another bug report. -- Edit bug report at http://bugs.php.net/?id=20988&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20988&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20988&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20988&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20988&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20988&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20988&r=support Expected behavior: http://bugs.php.net/fix.php?id=20988&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20988&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20988&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20988&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20988&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20988&r=dst IIS Stability: http://bugs.php.net/fix.php?id=20988&r=isapi
#20976 [Bgs]: rename openssl.cnf
ID: 20976 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Feature/Change Request Operating System: windows systems PHP Version: 4.3.0RC3 New Comment: Hi, I know the issues from mysql and their *.cnf files. I don't know how the openssl.cnf is bundeld and my suggestion was _not_ to make PHP search for an opennsl.txt or whatever extension to openssl config file. I was just asking, if it would be possible to rename the shipping openssl.cnf for the reason of easier editing for windows user. I personally have no problems with this issue, I know how to rename or edit and set the env variables:-) Regards Friedhelm Betz Previous Comments: [2002-12-13 05:51:00] [EMAIL PROTECTED] mysql also has a similar issue with it's my.cnf file, although it will also search for my.ini in certain, not always useful, locations. [2002-12-13 02:37:35] [EMAIL PROTECTED] And you can btw, name it whatever you like, just set an environment variable called "OPENSSL_CONF" with the name. [2002-12-13 02:33:49] [EMAIL PROTECTED] Wrong place to report this, try openssl.org instead. [2002-12-12 17:08:32] [EMAIL PROTECTED] Hi, thanks for your efforts to make openssl extension more easy to use. The note in the openssl/README-ssl.txt adresses cleanly the problem with speeddial-links on windows system. To give more comfort to end-users - ok, renaming in a dos-box works - I suggest to ship this file with an .conf or txt file extension. It doesnt harm, is easy to edit, and will avoid upcoming bug-reports(IMHO). In the tradition to make PHP as easy to use for the end users it would be very kind to rename this file to openssl.conf or openssl.txt. And users who would like to have it named openssl.cnf could easily achieve this by renaming this file through the explorer interface (after editing). Regards Friedhelm Betz -- Edit this bug report at http://bugs.php.net/?id=20976&edit=1
#20957 [Fbk->Csd]: Random Corrupted Constants.
ID: 20957
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Closed
Bug Type: Scripting Engine problem
Operating System: FreeBSD 4.7
PHP Version: 4.2.3
New Comment:
closing then
Previous Comments:
[2002-12-13 05:50:39] [EMAIL PROTECTED]
Problem seems to be resolved with PHP4.3 and PHP-latest snapshot.
Thank you very much.
[2002-12-12 09:10:53] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-latest.zip
[2002-12-12 08:28:57] [EMAIL PROTECTED]
Under heavy load, mod_php4 seems to corrupt constants, and fail to
require php file specified in a constant. It leaves the following error
message in apache error_log:
[Tue Nov 26 15:02:47 2002] [error] PHP Fatal error: Failed opening
required 'onmassdeletepost' (include_path='.:/usr/local/lib/php'
) in /usr/home/huasing/public_html/common.php on line 35
[Tue Nov 26 15:02:48 2002] [error] PHP Fatal error: Failed opening
required 'DB_ERROR_VALUE_COUNT_ON_ROW' (include_path='.:/usr/loc
al/lib/php') in /usr/home/huasing/public_html/common.php on line 35
[Tue Nov 26 15:02:49 2002] [error] PHP Fatal error: Failed opening
required '_PEAR_default_error_options' (include_path='.:/usr/loc
al/lib/php') in /usr/home/huasing/public_html/common.php on line 35
The relevant lines in common.php are:
33 require_once('/home/home/lib/common/config.php');
34 require_once('PEAR.php');
35 require_once('DB.php');
36 require_once(HUASING_LIB_ERROR);
37 require_once(HUASING_LIB_ENV);
After turning off KeepAlive in apache, and set MaxRequestsPerChild = 1
, this problem doesn't appear any more.
Configure:
'./configure' '--with-apxs=/usr/local/sbin/apxs'
'--with-config-file-path=/usr/local/etc' '--enable-versioning'
'--with-regex=system' '--without-gd' '--without-mysql'
'--with-gd=/usr/local' '--enable-gd-native-ttf'
'--with-freetype-dir=/usr/local' '--with-jpeg-dir=/usr/local'
'--with-png-dir=/usr/local' '--with-zlib' '--with-mysql=/usr/local'
'--enable-xslt' '--with-xslt-sablot' '--with-expat-dir=/usr/local'
'--with-iconv=/usr/local' '--prefix=/usr/local'
'i386-portbld-freebsd4.6.2'
it runs on a Dual CPU server.
--
Edit this bug report at http://bugs.php.net/?id=20957&edit=1
#20976 [Bgs]: rename openssl.cnf
ID: 20976 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Feature/Change Request Operating System: windows systems PHP Version: 4.3.0RC3 New Comment: mysql also has a similar issue with it's my.cnf file, although it will also search for my.ini in certain, not always useful, locations. Previous Comments: [2002-12-13 02:37:35] [EMAIL PROTECTED] And you can btw, name it whatever you like, just set an environment variable called "OPENSSL_CONF" with the name. [2002-12-13 02:33:49] [EMAIL PROTECTED] Wrong place to report this, try openssl.org instead. [2002-12-12 17:08:32] [EMAIL PROTECTED] Hi, thanks for your efforts to make openssl extension more easy to use. The note in the openssl/README-ssl.txt adresses cleanly the problem with speeddial-links on windows system. To give more comfort to end-users - ok, renaming in a dos-box works - I suggest to ship this file with an .conf or txt file extension. It doesnt harm, is easy to edit, and will avoid upcoming bug-reports(IMHO). In the tradition to make PHP as easy to use for the end users it would be very kind to rename this file to openssl.conf or openssl.txt. And users who would like to have it named openssl.cnf could easily achieve this by renaming this file through the explorer interface (after editing). Regards Friedhelm Betz -- Edit this bug report at http://bugs.php.net/?id=20976&edit=1
#20957 [Com]: Random Corrupted Constants.
ID: 20957
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: Scripting Engine problem
Operating System: FreeBSD 4.7
PHP Version: 4.2.3
New Comment:
Problem seems to be resolved with PHP4.3 and PHP-latest snapshot.
Thank you very much.
Previous Comments:
[2002-12-12 09:10:53] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-latest.zip
[2002-12-12 08:28:57] [EMAIL PROTECTED]
Under heavy load, mod_php4 seems to corrupt constants, and fail to
require php file specified in a constant. It leaves the following error
message in apache error_log:
[Tue Nov 26 15:02:47 2002] [error] PHP Fatal error: Failed opening
required 'onmassdeletepost' (include_path='.:/usr/local/lib/php'
) in /usr/home/huasing/public_html/common.php on line 35
[Tue Nov 26 15:02:48 2002] [error] PHP Fatal error: Failed opening
required 'DB_ERROR_VALUE_COUNT_ON_ROW' (include_path='.:/usr/loc
al/lib/php') in /usr/home/huasing/public_html/common.php on line 35
[Tue Nov 26 15:02:49 2002] [error] PHP Fatal error: Failed opening
required '_PEAR_default_error_options' (include_path='.:/usr/loc
al/lib/php') in /usr/home/huasing/public_html/common.php on line 35
The relevant lines in common.php are:
33 require_once('/home/home/lib/common/config.php');
34 require_once('PEAR.php');
35 require_once('DB.php');
36 require_once(HUASING_LIB_ERROR);
37 require_once(HUASING_LIB_ENV);
After turning off KeepAlive in apache, and set MaxRequestsPerChild = 1
, this problem doesn't appear any more.
Configure:
'./configure' '--with-apxs=/usr/local/sbin/apxs'
'--with-config-file-path=/usr/local/etc' '--enable-versioning'
'--with-regex=system' '--without-gd' '--without-mysql'
'--with-gd=/usr/local' '--enable-gd-native-ttf'
'--with-freetype-dir=/usr/local' '--with-jpeg-dir=/usr/local'
'--with-png-dir=/usr/local' '--with-zlib' '--with-mysql=/usr/local'
'--enable-xslt' '--with-xslt-sablot' '--with-expat-dir=/usr/local'
'--with-iconv=/usr/local' '--prefix=/usr/local'
'i386-portbld-freebsd4.6.2'
it runs on a Dual CPU server.
--
Edit this bug report at http://bugs.php.net/?id=20957&edit=1
#20896 [Com]: php -w hangs indefinitely at 100% CPU
ID: 20896 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Verified Bug Type: *General Issues Operating System: SuSE 7.2 PHP Version: 4.3.0RC2 New Comment: Same problem exists in 4.3.0RC3 Previous Comments: [2002-12-11 02:38:44] [EMAIL PROTECTED] This happens also with the -s option. And with CGI binary too. Basically the reason is that the -s / -w options use some hackish way to accomplish the tasks. Which seems to work on some systems though.. [2002-12-11 02:20:06] [EMAIL PROTECTED] Also repeatable on SuSE 8.0 [2002-12-09 00:03:12] [EMAIL PROTECTED] Not quite a crash, but I found no better category (time to add one for the CLI SAPI?) A simple php -w filename.php will on my system output the things it should, but then hang forever at full CPU consumption. [PHP Modules] ctype gd mysql overload pcre pgsql posix session standard tokenizer xml zlib -- Edit this bug report at http://bugs.php.net/?id=20896&edit=1
#17826 [Com]: PHP 4.2.1 Apache SAPI is not compatible with Apache 2.0.39
ID: 17826 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: Apache2 related Operating System: Win32 PHP Version: 4.2.1 Assigned To: edink New Comment: Hi, Despite having done exactly what is explained in "[23 Oct 8:52pm] [EMAIL PROTECTED]" in this bug list, I still have "cannot load php4apache2.dll into server - The specified procedure cannot be found". Versions of apache and php are the same. The only thing is that I'm using Windows XP Pro SP1 with all windows updates... Download of php4-win32-STABLE-latest.zip was made today (buggy version?) What's wrong??? Do I have to put php4ts.dll into the register datas??? DO I miss any specific XP Pro procedure? I spent 3 hours on this and it still doesn't work. Urgent help needed plz. Thanks in advance. Vince Previous Comments: [2002-12-07 11:18:22] [EMAIL PROTECTED] When I use the SAPI DLL for PHP on W2K and Apache 2.0.43, I get nothing. :( No errors anywhere I can see, but also no php processing. I know it's 'supposed' to be buggy, but I get nothing - not even an error. I can load a .php page, but everything between the shows up in the page source. If I use php-cgi.exe instead of php4apache2.dll, my pages work. But I have an urgent need for the virtual() function and this only works in the dll version of php. Using apache -k start there are no errors. There are also no errors in error.log. I've set php.ini to report errors, but there aren't ever any. Anyone got an idea? My httpd.conf contains: # PHP LoadModule php4_module c:/php/sapi/php4apache2.dll #AddModule mod_php4.c AddType application/x-httpd-php .phtml .php .php3 .php4 .html I've commented out the AddModule line for 2 reasons. One is that I have no module called mod_php4.c - the other reason is that the docs say that it's not required in the newer versions of Apache, especially Apache 2. Bob Kramer [2002-11-13 06:51:20] [EMAIL PROTECTED] Thank you The post: [11 Oct 2:17pm] [EMAIL PROTECTED] did the trick for me. I had some problems that are explained at the http://bugs.php.net/bug.php?id=16575 page (read the mcdragon posts in november) The trick with the latest (stable) snaps worked. I used the php4apache2.dll and the php4ts.dll Interesting! I took the PHP download and the SNAP in the same day and the first had the modified date at the begin of sept 2002 and the snap had november 13th 2002 (TODAY). In any case, thanks KRONUZ for the great help :-))) [2002-11-10 17:51:19] [EMAIL PROTECTED] FYI - The files referenced above are back online. Thanks, imajes, for your quick response! [2002-11-10 13:28:47] [EMAIL PROTECTED] snaps has moved server, and win32 snaps haven't been uploaded yet. please bear with us as we fix this. Thanks [2002-11-10 13:16:51] [EMAIL PROTECTED] I appreciate all the information posted on this bug, but does anyone know what's wrong with snaps.php.net? I can't download the file that's referenced above, http://snaps.php.net/win32/php4-win32-STABLE-latest.zip Does anyone have any information on what's going on with snaps.php.net? 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/17826 -- Edit this bug report at http://bugs.php.net/?id=17826&edit=1
#20987 [NEW]: Problem with curl_setopt and client certificates
From: [EMAIL PROTECTED] Operating system: Redhat Linux 7.2 PHP version: 4.3.0RC3 PHP Bug Type: cURL related Bug description: Problem with curl_setopt and client certificates It appears that if you try to specify a client certficate for an HTTPS connection using the CURLOPT_SSLCERT option, nothing gets set. An example would be: curl_setopt($ch, CURLOPT_SSLCERT, "client.pem"); A quick look at the PHP source seems to indicate that this option is omitted from the curl_setopt function. If I add it it works fine. -- Edit bug report at http://bugs.php.net/?id=20987&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20987&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20987&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20987&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20987&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20987&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20987&r=support Expected behavior: http://bugs.php.net/fix.php?id=20987&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20987&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20987&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20987&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20987&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20987&r=dst IIS Stability: http://bugs.php.net/fix.php?id=20987&r=isapi
#20986 [NEW]: PHP causes Apache to leak semaphores
From: [EMAIL PROTECTED] Operating system: RedHat Linux 7.1 & 8.0 PHP version: 4.2.2 PHP Bug Type: Apache related Bug description: PHP causes Apache to leak semaphores This bug has been discussed over at RedHat's Bugzilla. See http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=70846 A quick synopsis of how I get it to misbehave: Create the following simple PHP script and access it through a web browser: 2, 'test' => 2, 1 => 'hello', 'say' => 'hello', 2 => 42, 'life' => 42, 3 => 'this should help \'crash\' the machine', 'hoho' => 'this should help \'crash\' the machine'); print_r($crash); for( $i=0; $i It should die with an error similar to this: Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to allocate 35 bytes) in /home//crash.php on line 14 Reload this page a good 5-10 times. If you run 'ipcs -s' and then restart apache and run 'ipcs -s' again you will find that the number of semaphore arrays has increased and the first few semid's are unchanged (not having been freed when apache shutdown?). If you rinse and repeat the above with a crude shell script like: while [ true ]; do wget -O - http://localhost/crash.php wget -O - http://localhost/crash.php wget -O - http://localhost/crash.php wget -O - http://localhost/crash.php wget -O - http://localhost/crash.php wget -O - http://localhost/crash.php wget -O - http://localhost/crash.php wget -O - http://localhost/crash.php wget -O - http://localhost/crash.php wget -O - http://localhost/crash.php ipcs -s|grep apache|wc /etc/rc.d/init.d/httpd restart sleep 1 ipcs -s|grep apache|wc done then you'll find the semaphore array numbers increasing slowly and apache taking longer and longer to do each restart until eventually (once all 128 semaphore arrays are used) it refuses to start at all with the message reported earlier in this bug (70846): Starting httpd: Ouch! ap_mm_create(1048576, "/var/run/httpd.mm.5619") failed Error: MM: mm:core: failed to acquire semaphore (No space left on device): OS: Invalid argument [FAILED] Just restarting apache in a loop without loading crash.php on a freshly booted system does not cause the number of semaphores to spiral - it stays constant at 5. This is verifyable on multiple RH7.1 and a RH8.0 machine, all fully updated through RHN (except for kernels). RedHat have literally just released an updated mm package which stops the use of kernel semaphores so that the leaks should not cause Apache problems so quickly (ie more than 128 are now allowed), but none-the-less there RedHat agree there is still a PHP problem. Louis -- Edit bug report at http://bugs.php.net/?id=20986&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20986&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20986&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20986&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20986&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20986&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20986&r=support Expected behavior: http://bugs.php.net/fix.php?id=20986&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20986&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20986&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20986&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20986&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20986&r=dst IIS Stability: http://bugs.php.net/fix.php?id=20986&r=isapi
#20985 [Opn->Fbk]: heavy load = Segmentation fault
ID: 20985 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Reproducible crash Operating System: Redhat Linux 7.3 & 8 PHP Version: 4.3.0RC3 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: [2002-12-13 03:55:57] [EMAIL PROTECTED] I have tested this on different machines, so I do not think that this is a hardware error. [2002-12-13 03:49:42] [EMAIL PROTECTED] I get these errors on both Redhat Linux 7.3 & 8 [2002-12-13 03:47:42] [EMAIL PROTECTED] [Fri Dec 13 10:17:36 2002] [notice] child pid 15954 exit signal Segmentation fault (11) I get several lines like the above when I have heavy load on the server. This also happens whith php 4.2.3 In the test i used: Compaq P4 1.6ghz, 256mb ram Redhat Linux 7.3, kernel 2.4.18-18.8.0 Apache 1.3.27 Php 4.3.0RC3 & 4.2.3 MySQL 4.0.5a Stress tool: http://webtool.rte.microsoft.com/ I configured php like this: ./configure --with-apache=../apache-1.3.27 --with-mysql=/usr --enable-trans-sid --enable-inline-optimization --without-pear 'make test' made no errors. Please let me know what I can do to help you fix this bug. -- Edit this bug report at http://bugs.php.net/?id=20985&edit=1
#20984 [Opn->Bgs]: copy( "file.txt" , "file.txt" ) empties the file
ID: 20984 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Unknown/Other Function Operating System: w2k PHP Version: 4.2.3 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 Previous Comments: [2002-12-13 03:39:33] [EMAIL PROTECTED] copy( "toto.txt" , "toto.txt"); // then toto.txt is empty -- Edit this bug report at http://bugs.php.net/?id=20984&edit=1
#17774 [Opn->Bgs]: connection_status() not returning correct result
ID: 17774 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Scripting Engine problem Operating System: FREEBSD 4.7-STABLE PHP Version: PHP/4.3.0RC3 New Comment: ignore that, its working now, but it wasnt a minute ago. Previous Comments: [2002-12-13 04:04:08] [EMAIL PROTECTED] Okay, so we got the problem down to apache 2.x. ANyway, I got time to install apache 1.3.27. Now my system is running this :- SERVER_SOFTWARE Apache/1.3.27 (Unix) PHP/4.3.0RC3 And the problem still exists. I run the exact same script as shown above, which yourselfs have verified should return a '1'. The script is returning a 0, even if I press the STOP button. I have not bothered to compile gzip into this apache installation, to ensure it is not that which causes a problem. http://admin.mghost.net/~neil/test/ - script http://admin.mghost.net/~neil/test/output.txt - output file http://admin.mghost.net/~neil/test/test.cgi - standard perl diver script, to show details of my server. [2002-12-08 17:01:42] [EMAIL PROTECTED] This may interest you :- http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8996 Obviously if apaches log files are doing htat, then its completely the fault of apache 2 :-/ [2002-12-08 10:46:28] [EMAIL PROTECTED] This report describes another problem: http://bugs.php.net/bug.php?id=14542 So there is clearly some bug in there. But for aborts it definately works (on apache1) so you should report this to apache folks too, would be nice to hear what they think of it.. :) [2002-12-08 08:23:31] [EMAIL PROTECTED] Okay, I should report this to Apache then ? This is a fault in there software ? [2002-12-08 03:17:06] [EMAIL PROTECTED] For me your test script makes output.txt contain 1 when I press 'stop' button in my browser. But I'm using Apache 1.3.27. And so should you as Apache2 is still beta quality. 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/17774 -- Edit this bug report at http://bugs.php.net/?id=17774&edit=1
#17774 [Bgs->Opn]: connection_status() not returning correct result
ID: 17774
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Bogus
+Status: Open
Bug Type: Scripting Engine problem
-Operating System: FREEBSD 4.5-STABLE
+Operating System: FREEBSD 4.7-STABLE
-PHP Version: 4.0CVS-2002-06-15
+PHP Version: PHP/4.3.0RC3
New Comment:
Okay, so we got the problem down to apache 2.x. ANyway, I got time to
install apache 1.3.27.
Now my system is running this :-
SERVER_SOFTWARE Apache/1.3.27 (Unix) PHP/4.3.0RC3
And the problem still exists.
I run the exact same script as shown above, which yourselfs have
verified should return a '1'. The script is returning a 0, even if I
press the STOP button.
I have not bothered to compile gzip into this apache installation, to
ensure it is not that which causes a problem.
http://admin.mghost.net/~neil/test/ - script
http://admin.mghost.net/~neil/test/output.txt - output file
http://admin.mghost.net/~neil/test/test.cgi - standard perl diver
script, to show details of my server.
Previous Comments:
[2002-12-08 17:01:42] [EMAIL PROTECTED]
This may interest you :-
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8996
Obviously if apaches log files are doing htat, then its completely the
fault of apache 2 :-/
[2002-12-08 10:46:28] [EMAIL PROTECTED]
This report describes another problem:
http://bugs.php.net/bug.php?id=14542
So there is clearly some bug in there. But for aborts it definately
works (on apache1) so you should report this
to apache folks too, would be nice to hear what they think of it.. :)
[2002-12-08 08:23:31] [EMAIL PROTECTED]
Okay, I should report this to Apache then ? This is a fault in there
software ?
[2002-12-08 03:17:06] [EMAIL PROTECTED]
For me your test script makes output.txt contain 1 when I press 'stop'
button in my browser.
But I'm using Apache 1.3.27. And so should you as Apache2 is still beta
quality.
[2002-12-07 08:47:29] [EMAIL PROTECTED]
Okay, time has moved on, plenty of new versions have come out, ive kept
up to the very latest all along, alas, as expected, it still doesnt
work.
Can I just get a clarification of what should happen when a user
presses the stop button on the following script ? My guess is that it
should put a 1 or a 2 into the file, not a 0!
-
";
}
flush();
}
$a = $a + 1;
sleep('5');
}
exitfp();
?>
---
You keep telling me this function is fixed, but surely the above code
shuld have an output different to 0 if the user presses the stop button
?
Heres some version info from my server
FreeBSD admin.mghost.net 4.7-STABLE FreeBSD 4.7-STABLE #5: Sun Dec 1
00:39:59 GMT 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/ADMIN
i386
Apache/2.0.43 (Unix) PHP/4.3.0RC2
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/17774
--
Edit this bug report at http://bugs.php.net/?id=17774&edit=1
#20985 [Com]: heavy load = Segmentation fault
ID: 20985 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Reproducible crash Operating System: Redhat Linux 7.3 & 8 PHP Version: 4.3.0RC3 New Comment: I have tested this on different machines, so I do not think that this is a hardware error. Previous Comments: [2002-12-13 03:49:42] [EMAIL PROTECTED] I get these errors on both Redhat Linux 7.3 & 8 [2002-12-13 03:47:42] [EMAIL PROTECTED] [Fri Dec 13 10:17:36 2002] [notice] child pid 15954 exit signal Segmentation fault (11) I get several lines like the above when I have heavy load on the server. This also happens whith php 4.2.3 In the test i used: Compaq P4 1.6ghz, 256mb ram Redhat Linux 7.3, kernel 2.4.18-18.8.0 Apache 1.3.27 Php 4.3.0RC3 & 4.2.3 MySQL 4.0.5a Stress tool: http://webtool.rte.microsoft.com/ I configured php like this: ./configure --with-apache=../apache-1.3.27 --with-mysql=/usr --enable-trans-sid --enable-inline-optimization --without-pear 'make test' made no errors. Please let me know what I can do to help you fix this bug. -- Edit this bug report at http://bugs.php.net/?id=20985&edit=1
#20985 [Opn]: heavy load = Segmentation fault
ID: 20985 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Reproducible crash -Operating System: Redhat Linux 8 +Operating System: Redhat Linux 7.3 & 8 PHP Version: 4.3.0RC3 New Comment: I get these errors on both Redhat Linux 7.3 & 8 Previous Comments: [2002-12-13 03:47:42] [EMAIL PROTECTED] [Fri Dec 13 10:17:36 2002] [notice] child pid 15954 exit signal Segmentation fault (11) I get several lines like the above when I have heavy load on the server. This also happens whith php 4.2.3 In the test i used: Compaq P4 1.6ghz, 256mb ram Redhat Linux 7.3, kernel 2.4.18-18.8.0 Apache 1.3.27 Php 4.3.0RC3 & 4.2.3 MySQL 4.0.5a Stress tool: http://webtool.rte.microsoft.com/ I configured php like this: ./configure --with-apache=../apache-1.3.27 --with-mysql=/usr --enable-trans-sid --enable-inline-optimization --without-pear 'make test' made no errors. Please let me know what I can do to help you fix this bug. -- Edit this bug report at http://bugs.php.net/?id=20985&edit=1
#20985 [NEW]: heavy load = Segmentation fault
From: [EMAIL PROTECTED] Operating system: Redhat Linux 8 PHP version: 4.3.0RC3 PHP Bug Type: Reproducible crash Bug description: heavy load = Segmentation fault [Fri Dec 13 10:17:36 2002] [notice] child pid 15954 exit signal Segmentation fault (11) I get several lines like the above when I have heavy load on the server. This also happens whith php 4.2.3 In the test i used: Compaq P4 1.6ghz, 256mb ram Redhat Linux 7.3, kernel 2.4.18-18.8.0 Apache 1.3.27 Php 4.3.0RC3 & 4.2.3 MySQL 4.0.5a Stress tool: http://webtool.rte.microsoft.com/ I configured php like this: ./configure --with-apache=../apache-1.3.27 --with-mysql=/usr --enable-trans-sid --enable-inline-optimization --without-pear 'make test' made no errors. Please let me know what I can do to help you fix this bug. -- Edit bug report at http://bugs.php.net/?id=20985&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20985&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20985&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20985&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20985&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20985&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20985&r=support Expected behavior: http://bugs.php.net/fix.php?id=20985&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20985&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20985&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20985&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20985&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20985&r=dst IIS Stability: http://bugs.php.net/fix.php?id=20985&r=isapi
#20984 [NEW]: copy( "file.txt" , "file.txt" ) empties the file
From: [EMAIL PROTECTED] Operating system: w2k PHP version: 4.2.3 PHP Bug Type: Unknown/Other Function Bug description: copy( "file.txt" , "file.txt" ) empties the file copy( "toto.txt" , "toto.txt"); // then toto.txt is empty -- Edit bug report at http://bugs.php.net/?id=20984&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20984&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20984&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20984&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20984&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20984&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20984&r=support Expected behavior: http://bugs.php.net/fix.php?id=20984&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20984&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20984&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20984&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20984&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20984&r=dst IIS Stability: http://bugs.php.net/fix.php?id=20984&r=isapi
