#20735 [Fbk->Csd]: Crashing, when trying to create DB_DataObject Class definitions
ID: 20735 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Closed Bug Type: MSSQL related Operating System: Windows 2000 PHP Version: 4.3.0RC2 New Comment: Feedback via email: "I have no more MSSQL problems with RC3. Thank to whoever fixed it." Previous Comments: [2002-12-04 22:47:36] [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-04 22:23:19] [EMAIL PROTECTED] can you try a snapshot release - latest cvs from (snaps.php.net) - I believe there where some fixes to the ms-sql driver in the last few days. [2002-11-30 09:10:11] [EMAIL PROTECTED] can you try setting the debug = 5 in the ini file This should give you an idea of how far it is getting before crashing. Then just add exit;'s until you locate the line of code that is causing it to die. - my guess is that is a bug with the ms-sql bindings. Unfortunatly I dont have access to ms-sql (or windows 2000) to test this on. Regards Alan [2002-11-30 07:34:41] [EMAIL PROTECTED] can you send me ([EMAIL PROTECTED]) the database create script and your ini file - I'll see if I can reproduce this on linux. [2002-11-30 06:52:06] [EMAIL PROTECTED] When I try to create to DB_DataObject class definition (DB_DataObject 0.6) I get a crash. I give the instruction: d:\php430\php.exe createTables.php D:\work\livo2\etc\dbo_livo.ini The message box (unfortunatly in german) says: Die Anweisung in "0x778cb9b1" verweist auf Speicher in "0x". Der Vorgang "written" konnte nicht auf dem Speicher durchgeführt werden. Klicken Sie auf "OK", um das Programm zu beenden. Klicken Sie auf "Abbrechen", um das Programm zu debuggen. (The instruction in "0x778cb9b1" refers to memory at "0x". The task "written" could not be processed. (...)). Contact me for screenshots and more, if you want. Regards, Peter Hopfgartner -- Edit this bug report at http://bugs.php.net/?id=20735&edit=1
#20982 [Opn->Csd]: sort doesn't sort
ID: 20982
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Closed
Bug Type: Arrays related
Operating System: NetBSD/Alpha (64bit) - 1.6
PHP Version: 4.2.2
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 00:37:26] [EMAIL PROTECTED]
I also tried other various sort functions and they all failed to sort:
# cat sort.php
"lemon", "a"=>"orange", "b"=>"banana",
"c"=>"apple");
asort ($fruits);
reset ($fruits);
while (list ($key, $val) = each ($fruits)) {
echo "$key = $val\n";
}
// ksort() demo
echo "\n";
$fruits = array ("d"=>"lemon", "a"=>"orange", "b"=>"banana",
"c"=>"apple");
ksort ($fruits);
reset ($fruits);
while (list ($key, $val) = each ($fruits)) {
echo "$key = $val\n";
}
// usort() demo
echo "\n";
$fruits = array();
function cmp ($a, $b) {
return strcmp($a["fruit"], $b["fruit"]);
}
$fruits[0]["fruit"] = "lemons";
$fruits[1]["fruit"] = "apples";
$fruits[2]["fruit"] = "grapes";
usort($fruits, "cmp");
while (list ($key, $value) = each ($fruits)) {
echo "\$fruits[$key]: " . $value["fruit"] . "\n";
}
?>
# php -q sort.php
fruits[0] = lemon
fruits[1] = orange
fruits[2] = banana
fruits[3] = apple
d = lemon
a = orange
b = banana
c = apple
d = lemon
a = orange
b = banana
c = apple
$fruits[0]: lemons
$fruits[1]: apples
$fruits[2]: grapes
#
[2002-12-13 00:09:11] [EMAIL PROTECTED]
# cat sort.php
# php -v
4.2.2
# php -q sort.php
fruits[0] = lemon
fruits[1] = orange
fruits[2] = banana
fruits[3] = apple
#
--
Edit this bug report at http://bugs.php.net/?id=20982&edit=1
#20542 [NoF->Csd]: 0+0=4G on aix4.3 (64bits)
ID: 20542
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: No Feedback
+Status: Closed
Bug Type: Math related
Operating System: aix 4.3.3.0
PHP Version: 4.2.3
New Comment:
Seems a gcc bug.
Now PHP compiled with the native AIX C compiler
(and apache still compiled with gcc)
and it works.
Previous Comments:
[2002-12-13 01:00:01] [EMAIL PROTECTED]
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".
[2002-11-27 18:54:59] [EMAIL PROTECTED]
Could this be an issue with the C library used on AIX? On a 64 bit
platform (64sparc) I cannot replicate the problem using PHP 4.2.3.
[2002-11-22 02:47:23] [EMAIL PROTECTED]
I am sorry but on this specific platform
does result in 4294967294, really!
And as well.
[2002-11-21 17:25:14] [EMAIL PROTECTED]
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.
Thank you for your interest in PHP.
string cancatination is done using . not , in PHP.
Results in 0 on any platform.
[2002-11-21 05:45:55] [EMAIL PROTECTED]
Script:
Output of script on php 4.2.3:
0+0=4294967294
which is equal to 2^32-2
(Output of script on php 4.1.2 and 4.0.6:
0+0=4294967296
which is equal to 2^32).
In general, all simple additions and multiplications produce huge
numbers:
0+0=4294967294
0+1=4294967295
1+0=4294967295
1+1=4294967296
0-0=0
0-1=-1
1-0=1
1-1=0
0*0=3.5178585246345E+18
0*1=3.5178585265101E+18
1*0=3.5178585265101E+18
1*1=3.5178585283857E+18
0/1=0
1/1=1
2/1=2
2/2=1
Installation issues
# gcc -v
Reading specs from
/usr/local/lib/gcc-lib/rs6000-ibm-aix4.3.3.0/2.95.3/specs
gcc version 2.95.3 20010315 (release)
# make -v
GNU Make version 3.79.1, by Richard Stallman and Roland McGrath.
Built for rs6000-ibm-aix4.3.3.0
# tar -xf apache_1.3.20.tar
# cd apache_1.3.20
# ./configure --enable-module=most
# cd ..
# tar -xf php-4.2.3.tar
# cd php-4.2.3
# ./configure --without-mysql --with-apache=../apache_1.3.20
--enable-static --with-iodbc=/usr/local --enable-track-vars
# make
# make install
# cd ..
# cd apache_1.3.20
# configure --enable-module=most
--activate-module=src/modules/php4/libphp4.a
# make
# make install
I don't know if it is very relevant but the rs6000 on which aix4.3 is
running
is a 64bits machine. The c program
int main()
{
printf("long=%dbits\n",8*sizeof(long));
return 0;
}
outputs 'long=64bits' when compiled with 'cc -q64', while when
compiled
with 'gcc' it outputs 'long=32bits'.
Thanks very much in advance,
Rein van Vliet
--
Edit this bug report at http://bugs.php.net/?id=20542&edit=1
#20981 [Opn->Csd]: --with-db3=shared,dir not working
ID: 20981 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: *Configuration Issues Operating System: solaris 9 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-13 00:05:42] [EMAIL PROTECTED] The configure script is not taking --with-db3=shared,dir. It works fine if I take out the "shared" or if I modify the configure script and add the DB3 directory to line 16771: for i in /usr/local /usr /usr/local/BerkeleyDB.3.0 $withval; do In my specifc case, DB3 is installed at /usr/local/BerkeleyDB, so I the line above is: for i in /usr/local /usr /usr/local/BerkeleyDB.3.0 /usr/local/BerkeleyDB $withval; do But for sure you guys just have to fix the variable $with_db3 Thanks -- Edit this bug report at http://bugs.php.net/?id=20981&edit=1
#20979 [Opn->Fbk]: sendmail_from,SMTP and other valuse in php.ini not being read...
ID: 20979
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Feedback
Bug Type: IIS related
Operating System: Windows XP Pro.
PHP Version: 4CVS-2002-12-12 (dev)
New Comment:
Are you absolutely sure that the php.ini is not in fact 'php.ini.ini'
like happened in #20753 ?
Previous Comments:
[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
#20643 [Opn->Fbk]: long POST fields get truncated
ID: 20643
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Feedback
Bug Type: Apache related
Operating System: Windows NT
PHP Version: 4CVS-2002-11-26 (dev)
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-12 19:50:49] [EMAIL PROTECTED]
Indeed,
we changed our server into RedHat 8.0 (Apache 2.0, PHP 4.2.2).
PHP Code that worked fine on the old server doesn't work on the new
server. Post-method forms let some variables (small) pass without any
problem, but bigger vars got truncated and concatenated with the
original value.
[2002-11-27 03:38:19] [EMAIL PROTECTED]
I double checked it, found the file you mentioned twice, but both are
the same, new updated files.
So problem persists.
[2002-11-26 20:10:45] [EMAIL PROTECTED]
Are you sure you have replaced ALL the old files with the new ones
found in the package? Most important one being php4ts.dll (and also
make sure you don't have many copies of it!)
[2002-11-26 04:54:09] [EMAIL PROTECTED]
Long (>~3k) POSTED fields get truncated
Following test produces correct results (twice the same length) on
Linux + Apache + PHP, Windows NT + IIS + PHP,
but NOT on Windows NT + Apache + PHP.
In last case, back in PHP the length appears to be 4374
bytes. Making the fieldname longer or shorter affects
this length, adding more fields doesn't.
This behaviour looks very much like reported bug #18961,
which is closed. Today, I downloaded, the what I think is, the latest
version (4.4.0-dev). But problem still exists.
The apache server I use is Apache: 1.3.19.0.0a delivered with Oracle
Application Server 1.0.2.2.2a .
My test file:
Data length: " . strlen($_POST['data1']) .
"";
return;
}
?>
"; ?>
var data = document.getElementById("data1");
data.value = "";
alert("Datalength: " + data.value.length);
form.submit();
Thanks,
- Douwe Koops
--
Edit this bug report at http://bugs.php.net/?id=20643&edit=1
#20540 [Bgs]: PHP do not read PHP.INI
ID: 20540 User 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: 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 Previous Comments: [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. [2002-11-21 12:20:46] [EMAIL PROTECTED] Thanks a lot for your fast reply... But, I knew of course that phpinfo() shows the path... and the displayed path by phpinfo() is "c:\winxp\php.ini" This is where I put the php.ini, but whatever I'm modifying in it and even restarting Apache, it does not take the changes into account I do not understand why... Anyway I'm using a workaround until finding the reason based on ini_set() function... I have to harcode it in the source code, but it works... Please, if you have any idea tell me... I hate to not understand when I'm doing all what is requested :-) Regards, Jean-Frederic 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 [Opn->Bgs]: rename openssl.cnf
ID: 20976 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Feature/Change Request Operating System: windows systems PHP Version: 4.3.0RC3 New Comment: Wrong place to report this, try openssl.org instead. Previous Comments: [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
#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: And you can btw, name it whatever you like, just set an environment variable called "OPENSSL_CONF" with the name. Previous Comments: [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
#20983 [NEW]: cmd line option -dextension_dir not correctly honored
From: [EMAIL PROTECTED]
Operating system: Win98
PHP version: 4CVS-2002-12-13 (dev)
PHP Bug Type: Reproducible crash
Bug description: cmd line option -dextension_dir not correctly honored
OS: Win98 SE
Setup: php 4.4-dev Dec 10 8:29, no PHP related stuff in any Windows or
System folder, php folder and sub out of zip unchanged except php.ini
Sorting out inst issues I stumbled over following behaviour:
Scenario a:
Dos Box, Current dir = dir containing php.exe, php.ini states a wrong
extension dir, holding outdated exts
I say :"php.exe c:\abc\def.php"
No complains about missing or wrong ext mods
this is a script doing socket stuff. It begins to run, opens, binds,
listens to a socket, and recognizes a
connection request from a telnet client. Then it dies with a page fault on
socket_read when the client wants to submit the first character. Oddly
enough it gets as far but ok as the ext dir is wrong anyway.
Scenario b:
I fix extension_dir using "-dextension_dir=path" on the commandline. echo
ini_get('extension_dir') shows
the correct location BUT: The script dies when it comes to reading the
first character from the client
Scenario c:
I fix php.ini, just changing extension_dir to point to the correct
location. Everything works fine.
Both extension_dir specs can be given rel and abs. Same symptoms.
--
Edit bug report at http://bugs.php.net/?id=20983&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=20983&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=20983&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=20983&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=20983&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=20983&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=20983&r=support
Expected behavior: http://bugs.php.net/fix.php?id=20983&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=20983&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=20983&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=20983&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20983&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=20983&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=20983&r=isapi
#20977 [Opn->Fbk]: Cannot compile both yaz and imap options
ID: 20977 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Compile Failure Operating System: Solaris 2.9 PHP Version: 4.3.0RC3 New Comment: 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.. Previous Comments: [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
#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: Use single quotes in your script. Not a bug. Previous Comments: [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 += "
#20973 [Opn->Bgs]: configure fails with IMAP
ID: 20973
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Bogus
Bug Type: IMAP related
Operating System: Sun Linux 7.0
PHP Version: 4.3.0RC3
New Comment:
So the added sanity check caught an error in your system.
Not PHP bug. (the build would have failed later otherwise)
(try searching web with "reference to __canary_death_handler'" and
you'll find out what the real problem is.)
Previous Comments:
[2002-12-12 13:56:17] [EMAIL PROTECTED]
PHP4 up through versions 4.2.3 installed without incident on the same
hardware/software configuration. Imap version is 2000c-stackgaurdC3.
This is running on a Sun Cobalt RaQ550 server appliance, so upgrading
the installed version of imap is not a desirable option.
./configure --with-imap --with-imap-ssl
results in the following:
checking for IMAP support... yes
checking for pam_start in -lpam... yes
checking for crypt in -lcrypt... (cached) yes
checking whether SSL libraries are needed for c-client... /usr/lib
checking whether IMAP works... no
configure: error: build test failed. Please check the config.log for
details.
config.log shows the following:
configure:34447: checking for IMAP support
configure:34805: checking for pam_start in -lpam
configure:34824: gcc -o conftest -g -O2 conftest.c -lpam -lcrypt
-lresolv -lm -ldl -lnsl -lcrypt 1>&5
configure:34852: checking for crypt in -lcrypt
configure:35246: checking whether SSL libraries are needed for
c-client
configure:35407: checking whether IMAP works
configure:35440: gcc -o conftest -g -O2 conftest.c -lcrypto -lssl
-lc-client -lcrypt -lpam -lcrypt -lresolv -lm -ldl -lnsl -lcrypt
1>&5
/usr/lib/libc-client.a(osdep.o): In function `ssl_onceonlyinit':
/usr/src/redhat/BUILD/imap-2000c/c-client/auth_ssl.c:153: the use of
`tmpnam' is dangerous, better use `mkstemp'
/usr/lib/libc-client.a(mail.o): In function `mm_cache':
/usr/src/redhat/BUILD/imap-2000c/c-client/mail.c:185: undefined
reference to `__canary_death_handler'
/usr/lib/libc-client.a(mail.o): In function `mail_parameters':
/usr/src/redhat/BUILD/imap-2000c/c-client/mail.c:459: undefined
reference to `__canary_death_handler'
/usr/lib/libc-client.a(mail.o): In function `mail_valid':
/usr/src/redhat/BUILD/imap-2000c/c-client/mail.c:490: undefined
reference to `__canary_death_handler'
/usr/lib/libc-client.a(mail.o): In function `mail_valid_net':
/usr/src/redhat/BUILD/imap-2000c/c-client/mail.c:508: undefined
reference to `__canary_death_handler'
/usr/lib/libc-client.a(mail.o): In function `mail_valid_net_parse':
/usr/src/redhat/BUILD/imap-2000c/c-client/mail.c:619: undefined
reference to `__canary_death_handler'
/usr/lib/libc-client.a(mail.o):/usr/src/redhat/BUILD/imap-2000c/c-client/mail.c:677:
more undefined references to `__canary_death_handler' follow
collect2: ld returned 1 exit status
configure: failed program was:
#line 35415 "configure"
#include "confdefs.h"
void mm_log(void){}
void mm_dlog(void){}
void mm_flags(void){}
void mm_fatal(void){}
void mm_critical(void){}
void mm_nocritical(void){}
void mm_notify(void){}
void mm_login(void){}
void mm_diskerror(void){}
void mm_status(void){}
void mm_lsub(void){}
void mm_list(void){}
void mm_exists(void){}
void mm_searched(void){}
void mm_expunged(void){}
char mail_open();
int main() {
mail_open(0,"",0);
return 0;
}
--
Edit this bug report at http://bugs.php.net/?id=20973&edit=1
#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
#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
#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 [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
#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
#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
#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
#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
#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
#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
#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
#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
#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
#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 [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 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
#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
#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 [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 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: 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 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
#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
#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
#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
#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
#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
#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
#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
#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 += "
#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 += "
#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
#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
#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
#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
#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
#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 [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
#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 [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
#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
#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
#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
#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
#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
#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 [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->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
#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
#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
#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
#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
#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
#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
#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
#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
#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
#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
#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
#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
#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
#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
#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->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
#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
#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
#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
#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
#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
#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 [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 [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
#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 [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 [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
#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
#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
#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
#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
#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:
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
#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
#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
#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
#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
#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
#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
