[PHP-DEV] PHP 4.0 Bug #9641 Updated: get_required_files()/get_included_files() does not work as docuemented
ID: 9641
User Update by: [EMAIL PROTECTED]
Old-Status: Closed
Status: Open
Bug Type: Documentation problem
Description: get_required_files()/get_included_files() does not work as docuemented
Document is updated to reflect current PHP behavior. (Some what) Problems are still
there, so I reopen this.
Since include()/require()/include_once()/required_once() behavior has been changed
recently, descriptions are still incorrect for at least 4.0.4pl1.
I think those functions(lang. constructs) behave almost the same in recent PHP.
(Except require()/require_once() dies when it fails)
include()/require()/include_once()/require_once() now shares the same hash, so result
of get_included_files()/get_required_files() are the same. These function also lists
files included by include()/require() due to recent changes in these.
This makes function descriptions still incorrect.
Function descriptions for
include()/require()/include_once()/require_once()/get_included_files()/get_required_files()
are needed to be changed to reflect recent changes.
It would be helpful for users, if there are descriptions about changes in
include()/require()/include_once()/required_once(). (At least which versions supposed
to work as described)
Hope this helps.
Previous Comments:
---
[2001-03-17 02:18:33] [EMAIL PROTECTED]
documentation updated to reflect new behavior
---
[2001-03-15 09:22:56] [EMAIL PROTECTED]
Now, get_required_files and get_included_files are the same.
Documentation should be changed.
---
[2001-03-08 18:26:48] [EMAIL PROTECTED]
get_required_files()/get_included_files() does not work as docuemented
http://www.php.net/manual/en/function.get-required-files.php
Tested under Apache 1.3.17 w/ mod-ssl, mod-gzip, and other modules comes with apache.
RedHat 7.0.1/j. PHP 4.0.4pl1 running as apache module.
I found strange require_once() behaviour (to be reported as bug) and I also found this
problem.
If this is not a script engine problem, then it should be documentation problem. Hope
this info helps developer/documentation team.
Following code is identical to the example in manual.
?php
require_once ('local.php');
require_once ('../inc/global.php');
for ($i=1; $i5; $i++) {
include_once 'util'.$i.'php';
}
echo 'pre';
echo "Required_once filesn";
print_r (get_required_files());
echo "Included_once filesn";
print_r (get_included_files());
echo date('H:i:s',time());
echo '/pre';
?
I get
===
Required_once files
Array
(
[0] = /home/httpd/httpd/html/untitled/local.php
[1] = /home/httpd/httpd/html/inc/global.php
[2] = /home/httpd/httpd/html/untitled/util1php
[3] = /home/httpd/httpd/html/untitled/util2php
[4] = /home/httpd/httpd/html/untitled/util3php
[5] = /home/httpd/httpd/html/untitled/util4php
)
Included_once files
Array
(
[0] = /home/httpd/httpd/html/untitled/local.php
[1] = /home/httpd/httpd/html/inc/global.php
[2] = /home/httpd/httpd/html/untitled/util1php
[3] = /home/httpd/httpd/html/untitled/util2php
[4] = /home/httpd/httpd/html/untitled/util3php
[5] = /home/httpd/httpd/html/untitled/util4php
)
08:17:35
===
---
Full Bug description available at: http://bugs.php.net/?id=9641
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP-DEV] Re: [PHP-CVS] cvs: php4 / TODO-4.1.txt
Stig Bakken wrote: Log: here's a preliminary list of stuff for 4.1 Is there any timeframe for when PHP 4.1.0 will be released? PS: When will PHP 4.0.5 be released? :) Well im not happy with the current state of some bugs in HTTP_AUTH section and waiting for a reply from Rasmus on this issue then we can have yet another final RC and release it hopefully. - James -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10322 Updated: Logical error in fopen-wrappers.c
ID: 10322
Updated by: jmoore
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: PHP options/info functions
PHP Version: 4.0.4pl1
Assigned To:
Comments:
This will not make it into 4.0.5 as this was branched a while back but it might well
make it into 4.0.6. Ill get a developer to look at this patch.
- James
Previous Comments:
---
[2001-04-13 20:57:35] [EMAIL PROTECTED]
I thought, while I'm here, I'd submit a patch to fix this.
The patch also includes support for an additional special case in php.ini's
open_basedir.
The current "." allows scripts to access files in the same directory as the script.
"DOCUMENT_ROOT" allows a script to access any other file in the virtualhost's
directory tree. DOCUMENT_ROOT is calculated by PATH_TRANSLATED and removing
SCRIPT_URI from the end - This conveniently works for both full Apache Virtalhosts and
mod_aliased Mass virtual hosting (I don't know if this is true for the newer mod_vhost
- just check what PATH_TRANSLATED and SCRIPT_URI is set to in phpinfo() - if removing
the latter from the former is the sites docroot then you are away).
Anyway, the patch: code shamelessly copied from the "." segment :)
*** main/fopen-wrappers.c.orig Fri Apr 13 17:50:02 2001
--- main/fopen-wrappers.c Sat Apr 14 01:46:28 2001
***
*** 141,151
char resolved_name[MAXPATHLEN];
char resolved_basedir[MAXPATHLEN];
char local_open_basedir[MAXPATHLEN];
int local_open_basedir_pos;
SLS_FETCH();
/* Special case basedir==".": Use script-directory */
! if ((strcmp(PG(open_basedir), ".") == 0)
SG(request_info).path_translated
*SG(request_info).path_translated
) {
--- 141,167
char resolved_name[MAXPATHLEN];
char resolved_basedir[MAXPATHLEN];
char local_open_basedir[MAXPATHLEN];
+ char *local_open_request_uri;
int local_open_basedir_pos;
SLS_FETCH();
+ /* Special case basedir="DOCUMENT_ROOT": Restrict to directory of the
+* virtualhost itself as calculated by PATH_TRANSLATED - SCRIPT_URI
+* [EMAIL PROTECTED]
+*/
+ if ((strcmp(basedir, "DOCUMENT_ROOT") == 0)
+ SG(request_info).path_translated
+ *SG(request_info).path_translated ) {
+ /* Copy path_translated to local_open_basedir, the look in
+ this string for where request_uri starts and zero that byte
+ thus leaving local_open_basedir set to the virtualhost's
+ DOCUMENT_ROOT */
+ strlcpy(local_open_basedir, SG(request_info).path_translated, si
zeof(local_open_basedir));
+ local_open_request_uri=strstr(local_open_basedir,SG(request_info
).request_uri);
+ if (local_open_request_uri) *local_open_request_uri = '
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10325: Opening database connection breaks ldap
From: [EMAIL PROTECTED]
Operating system: Linux 2.4.3
PHP version: 4.0.4pl1
PHP Bug Type: LDAP related
Bug description: Opening database connection breaks ldap
Opening a database connection breaks LDAP's link index.
Example code:
?php
$dbcon = pg_connect("host=localhost port=5432 dbname=testdb user=testuser
password=testpass");
$ds = ldap_connect("localhost");
$ldapcon = ldap_bind($ds);
// This always returns 1
echo $ldapcon;
// This errors out
ldap_search($ldapcon, "dc=test,dc=com", "cn=*");
?
This generates the error:
PHP Warning: 1 is not a LDAP link index
If you comment out the pg_connect() line, LDAP works fine.
If you pg_close($dbcon) right after the pg_connect(), you still get the PHP error.
This is a definite show stopper considering some people use a database for sessions,
which means you can't use LDAP
after you start your session.
I'm using the latest openldap 2.0.7 postgres 7.0.3,
php compiled into apache:
./configure --enable-memory-limit --enable-track-vars --enable-sysvsem
--enable-sysvshm --with-gd --with-pgsql --with-freetype
--with-ldap=/usr/local/openldap --with-xml --with-mhash --enable-trans-sid
--with-kerberos --with-mcrypt --with-apache=../apache_1.3.19 --enable-bcmath
--with-zlib --with-sockets --enable-inline-optimizations
Please fix soon :)
--
Edit Bug report at: http://bugs.php.net/?id=10325edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10324 Updated: reproducable seg fault during generic script exec with pgsql and mcrypt
ID: 10324 Updated by: derick Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Feedback Bug Type: Reproduceable crash PHP Version: 4.0.4pl1 Assigned To: Comments: Can you try configuring php with --enable-debug, so that better backtraces can be made? Previous Comments: --- [2001-04-14 00:19:26] [EMAIL PROTECTED] Hi, I've managed to uncover a reproducable segmentation fault that occurs during execution of a script containing a loop of pgsql mcrypt calls. As best as I can tell mcrypt doesn't appear to by the cuplrit as removing the mcrypt calls doesn't prent the segfault (although it does seem to change the time/position) when the crash happens. Commententing out the Db queries (implemented using PEAR DB) does prevent the crash, however, on several occausions I managed to get the script to crash after my code had completed and the send buffer had been flushed (only record of a fault was in the error log), so I'm doubtful that the error is in the db code per se. Running gdb seems to show that memory is courupt before the script is run the first time (after researting apache) as can be seen in the trace below (this first memory error is exposed when executing any other script after an apache restart). Once the script runs for a while (it contains a rather expensive loop of db calls) it fails with the seg fault. I've already rebuilt postgres, libmcrypt and php, to no avail... Any ideas would be most appricated! Thanks Kevin --- build flags: './configure' '--prefix=/etc/php' '--with-apxs=/etc/apache/bin/apxs' '--with-mysql' '--with-pgsql' '--with-mcrypt' gdb session: This GDB was configured as "ppc-yellowdog-linux"... (gdb) run -X Starting program: /etc/apache/bin/httpd -X Cannot access memory at address 0x34623731. (gdb) bt #0 _dl_debug_state () at dl-debug.c:56 #1 0xfea2044 in dl_open_worker (a=0x30026c70) at dl-open.c:195 #2 0xfea21f8 in _dl_open (file=0xfea1d44 "224!ÿÀ|b -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #10299 Updated: CPU and Memory Spike
ID: 10299 User Update by: [EMAIL PROTECTED] Status: Open Bug Type: Performance problem Description: CPU and Memory Spike This is vmstat show if I keep reloading the script procs memory pagedisks faults cpu r b w avm fre flt re pi po fr sr da0 da1 in sy cs us sy id 1 4 0 73860 134324 0 0 0 0 0 2 0 382 3804 258 16 1 83 0 4 0 73860 134244 0 0 0 0 0 0 0 357 3789 245 15 4 81 1 4 0 73860 134244 0 0 0 0 0 0 0 373 3763 263 14 3 83 2 4 0 73860 13416 142 0 0 0 139 0 0 0 402 6155 285 26 4 70 0 4 0 73860 134084 0 0 0 4 0 11 0 366 3179 220 11 2 87 1 4 0 73860 134004 0 0 0 0 0 0 0 358 3943 257 15 3 82 2 4 0 73860 134004 0 0 0 0 0 0 0 340 4201 240 12 42 45 2 4 0 73860 134004 0 0 0 0 0 0 0 240 1842 90 0 100 0 2 4 0 73116 134004 0 0 0 0 0 19 0 265 1802 98 0 100 0 2 4 0 73116 134004 0 0 0 0 0 0 0 241 1753 93 0 100 0 2 4 0 73116 134004 0 0 0 0 0 0 0 239 1729 96 0 100 0 2 4 0 73116 134004 0 0 0 0 0 0 0 241 1612 94 0 100 0 2 4 0 73116 134004 0 0 0 0 0 0 0 243 1576 97 0 100 0 2 4 0 73116 134004 0 0 0 0 0 0 0 243 1541 98 0 100 0 2 4 0 73116 134004 0 0 0 0 0 0 0 239 1487 102 0 100 0 2 4 0 73116 134004 0 0 0 0 0 0 0 241 1401 93 0 100 0 2 4 0 73116 134004 0 0 0 0 0 0 0 251 1405 100 0 100 0 2 4 0 73116 134004 0 0 0 0 0 0 0 246 1338 101 0 100 0 2 4 0 73116 134004 0 0 0 0 0 0 0 238 1297 94 0 100 0 2 4 0 73860 134004 0 0 0 0 0 0 2 243 1282 100 0 100 0 2 4 0 73860 134004 0 0 0 0 0 0 0 239 1223 89 0 100 0 2 4 0 73860 134004 0 0 0 2 0 9 16 300 1180 92 0 100 0 procs memory pagedisks faults cpu r b w avm fre flt re pi po fr sr da0 da1 in sy cs us sy id 3 4 0 73860 134004 0 0 0 0 0 0 0 251 1156 90 0 100 0 3 4 0 50296 134004 0 0 0 0 0 6 0 258 1116 93 0 100 0 2 4 0 50296 134004 0 0 0 0 0 0 0 240 1108 83 0 100 0 3 4 0 50296 134004 0 0 0 0 0 0 0 245 1064 92 0 100 0 3 4 0 46988 134004 0 0 0 0 0 0 0 242 1031 83 0 100 0 3 4 0 46988 134004 0 0 0 0 0 0 0 242 989 82 0 100 0 2 4 0 46988 134004 0 0 0 0 0 0 0 243 1010 85 0 100 0 2 4 0 46988 134004 0 0 0 0 0 1 0 241 985 81 0 100 0 2 4 0 46988 134004 0 0 0 0 0 0 0 241 971 89 1 99 0 2 4 0 46988 134004 0 0 0 0 0 0 0 243 940 74 0 100 0 3 4 0 46988 134004 0 0 0 2 0 8 0 250 926 80 0 100 0 2 4 0 46988 134004 0 0 0 0 0 1 0 245 930 88 0 100 0 3 4 0 46988 134004 0 0 0 0 0 0 0 240 905 80 0 100 0 2 4 0 46988 134004 0 0 0 0 0 7 0 253 920 100 0 98 2 3 4 0 47332 13056 90 0 0 0 0 0 0 0 239 2113 116 3 97 0 2 4 0 46588 130484 0 0 0 0 0 1 0 243 2334 103 1 99 0 1 4 0 46244 133924 0 0 0 86 0 8 0 276 4383 140 7 19 74 1 4 0 47896 13184 59 0 0 0 0 0 2 0 275 621 56 7 1 92 0 4 0 47896 13152 20 0 0 0 0 0 1 0 253 471 46 6 1 93 1 4 0 47492 13372 18 0 0 0 64 0 0 0 251 478 43 0 1 99 0 4 0 47492 133724 0 0 0 0 0 0 0 235 440 40 0 0 100 0 4 0 47492 133724 0 0 0 0 0 0 0 238 442 40 0 2 98 The CPU time drop from 80 all the way to zero and make the Apache hang for like 30 seconds and the resume back again. It happens VERY often if I only have like 30 users surf the website at the same time. It pretty much bring the web server down if I have around 50 users surft the site Previous Comments: --- [2001-04-11 18:03:59] [EMAIL PROTECTED] I am running on FreeBSD 4.2 Stable, Apache 1.3.19 + PHP 4.0.4pl1 + Modssl on a Dual P2 400mhz with 256mb ram. From time to time, one of the httpd process will eat up all the CPU time and memory, and after around 5 to 10 seconds, it goes back to normal Even a Very simple script like ? echo "test"; ? can make it happen. 1 out of 25 reload of the above script can make the spike happen. But the web server do not crash though. If I run on a script with heavy database access, it happen 1 out of 10 if I press reload button continously. BTW, is that normal for Apache to take up 30% of the CPU time to excute
[PHP-DEV] PHP 4.0 Bug #10322 Updated: Logical error in fopen-wrappers.c
ID: 10322
User Update by: [EMAIL PROTECTED]
Status: Open
Bug Type: PHP options/info functions
Description: Logical error in fopen-wrappers.c
Thanks for the response, however, can you confirm that there is a logical coding error
here?
The DOCUMENT_ROOT patch is secondary and would be nice - but is the bug going to be
fixed in 4.0.5 ?
Regards,
Paul.
Previous Comments:
---
[2001-04-14 05:34:04] [EMAIL PROTECTED]
This will not make it into 4.0.5 as this was branched a while back but it might well
make it into 4.0.6. Ill get a developer to look at this patch.
- James
---
[2001-04-13 20:57:35] [EMAIL PROTECTED]
I thought, while I'm here, I'd submit a patch to fix this.
The patch also includes support for an additional special case in php.ini's
open_basedir.
The current "." allows scripts to access files in the same directory as the script.
"DOCUMENT_ROOT" allows a script to access any other file in the virtualhost's
directory tree. DOCUMENT_ROOT is calculated by PATH_TRANSLATED and removing
SCRIPT_URI from the end - This conveniently works for both full Apache Virtalhosts and
mod_aliased Mass virtual hosting (I don't know if this is true for the newer mod_vhost
- just check what PATH_TRANSLATED and SCRIPT_URI is set to in phpinfo() - if removing
the latter from the former is the sites docroot then you are away).
Anyway, the patch: code shamelessly copied from the "." segment :)
*** main/fopen-wrappers.c.orig Fri Apr 13 17:50:02 2001
--- main/fopen-wrappers.c Sat Apr 14 01:46:28 2001
***
*** 141,151
char resolved_name[MAXPATHLEN];
char resolved_basedir[MAXPATHLEN];
char local_open_basedir[MAXPATHLEN];
int local_open_basedir_pos;
SLS_FETCH();
/* Special case basedir==".": Use script-directory */
! if ((strcmp(PG(open_basedir), ".") == 0)
SG(request_info).path_translated
*SG(request_info).path_translated
) {
--- 141,167
char resolved_name[MAXPATHLEN];
char resolved_basedir[MAXPATHLEN];
char local_open_basedir[MAXPATHLEN];
+ char *local_open_request_uri;
int local_open_basedir_pos;
SLS_FETCH();
+ /* Special case basedir="DOCUMENT_ROOT": Restrict to directory of the
+* virtualhost itself as calculated by PATH_TRANSLATED - SCRIPT_URI
+* [EMAIL PROTECTED]
+*/
+ if ((strcmp(basedir, "DOCUMENT_ROOT") == 0)
+ SG(request_info).path_translated
+ *SG(request_info).path_translated ) {
+ /* Copy path_translated to local_open_basedir, the look in
+ this string for where request_uri starts and zero that byte
+ thus leaving local_open_basedir set to the virtualhost's
+ DOCUMENT_ROOT */
+ strlcpy(local_open_basedir, SG(request_info).path_translated, si
zeof(local_open_basedir));
+ local_open_request_uri=strstr(local_open_basedir,SG(request_info
).request_uri);
+ if (local_open_request_uri) *local_open_request_uri = '
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #10299 Updated: CPU and Memory Spike
ID: 10299
User Update by: [EMAIL PROTECTED]
Status: Open
Bug Type: Performance problem
Description: CPU and Memory Spike
I found the problem. since the script I use have a lot of include and require
statement. just a script include a bunch of files and keep reloading the page will
kill the server in no time. I attach a sample config file I usually include, just
make a test.php and include this file like 10 times to simulate a lot of include
files. And then, just keep reloading test.php. You should see the script take a lot
of CPU time and eventually the httpd eat all the CPU time and the process hang. From
command "top", one of the httpd process keep eating up CPU time.
The following is the sample config file
?
/*Root directory */
$config[root_path] = "/usr2/home/business/test/www";
$config[w3b_path] = "/usr2/home/business/test/www/wwwthreads";
$config[data_path] = "/usr2/home/business/test/data";
$config[rdf_path] = "/usr2/home/business/test/www/rdf";
/* database */
include $config[root_path]."/db.php";
/* global */
$config[sitename] = "www.test.net";
$config[root_url] = "http://www.test.net/";
// Cookie Setting
$config[cookie_path] = "/"; # web root directory
$config[CookieURL] = ".test.net";
$config[cookieTTL] = 7200; // in seconds
$config[minpass]= 3; # Minimum user password length in characters
/* language and locale */
$config[language] = "english";# [english] english, [big5] BIG5 code
$config[locale] = "english";# Used for translation of date-related stuff
/* story control */
$config[commentmax] = 4096;
$config[abstractlen]= 4996; #length of abstract show on first page
$config[icon_width] = 100; # Topic icons width
$config[timezone] = "HKT"; #Time zone
$config[limitnews] = 10; # default number of stories per page
$config[older_story_num]= 10; # number of older stories to display
$config[anon_users] = 0; # 1 to allow anonymous postings
# 0 to disable
/* theme control */
$config[def_theme] = "Main"; # name of default theme (see themes/ directory for
list)
/* mail settings */
$config[use_fake_email] = 1; # Displays fake email addresses for users instead of the
real ones
$config[notifyEmail]= "[EMAIL PROTECTED]"; #address where you want to
receive notice
//$config[CensorList] =
array('fuck','cunt','fucker','fucking','pussy','cock','c0ck','cum','bitch','shit');
$config[CensorList] = array("/fuck/s","/fuck/s","/fuck/s",
"/[a-z]*fuck[a-z]*/is",
"/[a-z]*cunt[a-z]*/is",
"/[a-z]*pussy[a-z]*/is",
"/[a-z]*cock[a-z]*/is",
"/[a-z]*c0ck[a-z]*/is",
"/[a-z]*shit[a-z]*/is",
"/[a-z]*bitch[a-z]*/is",
"/[a-z]*diu[a-z]*/is"
);
# See also specific LOCALE definitions
$config[CensorMode] = 3; # 0: no filtering
# 1: exact match
# 2: match word beginnings
# 3: match string anywhere in words
$config[CensorReplace] = "[CENSORED]" ;
/* allowable HTML tags. Used by check_html()
Happily lifted (with mods) from phpslash */
$config[AllowableHTML] = array("p"=1, # 2 means accept all qualifiers: foo bar
"b"=1,# 1 means accept the tag only: foo
"i"=1,
"a"=2,
"em"=1,
"br"=1,
"strong"=1,
"blockquote"=1,
"img"=2,
"tt"=1,
"hr"=1,
"li"=1,
"ol"=1,
"div"=1,
"ul"=1);
$config[AllowableHTMLtag] =
"b,i,a,em,br,strong,blockquote,tt,hr,li,ol,div,ul";
/* poll settings */
$config[maxOptions] = 12; # maximal number of options allowed
$config[BarScale] = 1;# scale of result bar (in multiples of 100 pixels)
$config[warnCheaters] = 1;# 1 - a notice issued on vote second try
# 0 - silently ignores the vote
$config[maxOptions] = 10;
/* story stuff */
$reasons = array('As is', # "Normal"
'Offtopic', # Bad Responses
'Flamebait',
'Troll',
'Redundant',
'Insightful', # Good Responses
'Interesting',
'Informative',
'Funny',
'Overrated',# Last two are "special"
'Underrated');
if ($config[dateString] ==
[PHP-DEV] PHP 4.0 Bug #10324 Updated: reproducable seg fault during generic script exec with pgsql and mcrypt
ID: 10324 User Update by: [EMAIL PROTECTED] Old-Status: Feedback Status: Open Bug Type: Reproduceable crash Description: reproducable seg fault during generic script exec with pgsql and mcrypt I've rebuilt php with --enable-debug on (rm config.cache cleaned the build dirs), but the db symbols still don't appear in the back trace. I am using the standard build environment that ships with yellodog/rh 6.2 (gnu), so I am not sure why this isn't working as expected. Previous Comments: --- [2001-04-14 07:38:40] [EMAIL PROTECTED] Can you try configuring php with --enable-debug, so that better backtraces can be made? --- [2001-04-14 00:19:26] [EMAIL PROTECTED] Hi, I've managed to uncover a reproducable segmentation fault that occurs during execution of a script containing a loop of pgsql mcrypt calls. As best as I can tell mcrypt doesn't appear to by the cuplrit as removing the mcrypt calls doesn't prent the segfault (although it does seem to change the time/position) when the crash happens. Commententing out the Db queries (implemented using PEAR DB) does prevent the crash, however, on several occausions I managed to get the script to crash after my code had completed and the send buffer had been flushed (only record of a fault was in the error log), so I'm doubtful that the error is in the db code per se. Running gdb seems to show that memory is courupt before the script is run the first time (after researting apache) as can be seen in the trace below (this first memory error is exposed when executing any other script after an apache restart). Once the script runs for a while (it contains a rather expensive loop of db calls) it fails with the seg fault. I've already rebuilt postgres, libmcrypt and php, to no avail... Any ideas would be most appricated! Thanks Kevin --- build flags: './configure' '--prefix=/etc/php' '--with-apxs=/etc/apache/bin/apxs' '--with-mysql' '--with-pgsql' '--with-mcrypt' gdb session: This GDB was configured as "ppc-yellowdog-linux"... (gdb) run -X Starting program: /etc/apache/bin/httpd -X Cannot access memory at address 0x34623731. (gdb) bt #0 _dl_debug_state () at dl-debug.c:56 #1 0xfea2044 in dl_open_worker (a=0x30026c70) at dl-open.c:195 #2 0xfea21f8 in _dl_open (file=0xfea1d44 "224!ÿÀ|b -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #10324 Updated: reproducable seg fault during generic script exec with pgsql and mcrypt
ID: 10324 User Update by: [EMAIL PROTECTED] Status: Open Bug Type: Reproduceable crash Description: reproducable seg fault during generic script exec with pgsql and mcrypt here's the back trace (again without db symbols) of the crash when it happens after my script has completed execution: Program received signal SIGSEGV, Segmentation fault. 0xfe21138 in chunk_free (ar_ptr=0xfebb380, p=0x101f03d8) at malloc.c:3111 3111malloc.c: No such file or directory. (gdb) bt #0 0xfe21138 in chunk_free (ar_ptr=0xfebb380, p=0x101f03d8) at malloc.c:3111 #1 0xfe20fb0 in __libc_free (mem=0xfebb380) at malloc.c:3023 #2 0xf01121c in ?? () from /etc/apache/libexec/libphp4.so #3 0x0 in ?? () (gdb) Previous Comments: --- [2001-04-14 09:46:01] [EMAIL PROTECTED] I've rebuilt php with --enable-debug on (rm config.cache cleaned the build dirs), but the db symbols still don't appear in the back trace. I am using the standard build environment that ships with yellodog/rh 6.2 (gnu), so I am not sure why this isn't working as expected. --- [2001-04-14 07:38:40] [EMAIL PROTECTED] Can you try configuring php with --enable-debug, so that better backtraces can be made? --- [2001-04-14 00:19:26] [EMAIL PROTECTED] Hi, I've managed to uncover a reproducable segmentation fault that occurs during execution of a script containing a loop of pgsql mcrypt calls. As best as I can tell mcrypt doesn't appear to by the cuplrit as removing the mcrypt calls doesn't prent the segfault (although it does seem to change the time/position) when the crash happens. Commententing out the Db queries (implemented using PEAR DB) does prevent the crash, however, on several occausions I managed to get the script to crash after my code had completed and the send buffer had been flushed (only record of a fault was in the error log), so I'm doubtful that the error is in the db code per se. Running gdb seems to show that memory is courupt before the script is run the first time (after researting apache) as can be seen in the trace below (this first memory error is exposed when executing any other script after an apache restart). Once the script runs for a while (it contains a rather expensive loop of db calls) it fails with the seg fault. I've already rebuilt postgres, libmcrypt and php, to no avail... Any ideas would be most appricated! Thanks Kevin --- build flags: './configure' '--prefix=/etc/php' '--with-apxs=/etc/apache/bin/apxs' '--with-mysql' '--with-pgsql' '--with-mcrypt' gdb session: This GDB was configured as "ppc-yellowdog-linux"... (gdb) run -X Starting program: /etc/apache/bin/httpd -X Cannot access memory at address 0x34623731. (gdb) bt #0 _dl_debug_state () at dl-debug.c:56 #1 0xfea2044 in dl_open_worker (a=0x30026c70) at dl-open.c:195 #2 0xfea21f8 in _dl_open (file=0xfea1d44 "224!ÿÀ|b -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 / TODO-4.1.txt
On Sat, 14 Apr 2001, Sebastian Bergmann wrote: Stig Bakken wrote: Log: here's a preliminary list of stuff for 4.1 Is there any timeframe for when PHP 4.1.0 will be released? I don't know, but I'd like to start a branch for the 4.1.0 code in a week or so (or sooner, that's just when I'll have a use for it). I've got a bunch of stuff to put in, a new XSLT extension (syntax *will* change, but speed, stability and memory usage are greatly improved, as well as allowing multiple XSLT backends, initial support for Sablotron and libxslt). I'd also like to put the ADT stuff in 4.1 (nearing completion, still have to work up a good proposal). There are also some changes in cURL which don't really change the API but would be good to announce along with 4.1 (persistent connections)... That's just my stuff (I think I have a bit more for 4.1 too :)... I have a feeling from the todo that other people have a bunch of patches or things "todo" for 4.1 as well. Therefore I think setting up a branch at this time or pretty soon would be a good idea. That way we can start preparing for and stabilizing 4.1. -Sterling -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] TODO: UNC?
The "Zend" section of php4/TODO has an entry "* make UNC filenames work with V_CD layer" in it. Hasn't Daniel fixed this issue for PHP 4.0.6? -- sebastian bergmann[EMAIL PROTECTED] http://www.sebastian-bergmann.de bonn.phpug.de | www.php.net | www.phpOpenTracker.de | www.titanchat.de -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 / TODO-4.1.txt
Sterling Hughes wrote: got a bunch of stuff to put in, a new XSLT extension (syntax *will* change, but speed, stability and memory usage are greatly improved, as well as allowing multiple XSLT backends, initial support for Sablotron and libxslt). Sounds good. I'd also like to put the ADT stuff in 4.1 (nearing completion, still have to work up a good proposal). This is good news! I can't wait to get my hands on your ADT stuff, Sterling. a branch at this time or pretty soon would be a good idea. That way we can start preparing for and stabilizing 4.1. +1 PS: What changes to the ZendEngine could be done for a 4.1 release? No, I'm not starting another ApplicationServer debate, but during the last one there were a couple of good ideas that should be considerd, IMHO. Happy Easter, Sebastian -- sebastian bergmann[EMAIL PROTECTED] http://www.sebastian-bergmann.de bonn.phpug.de | www.php.net | www.phpOpenTracker.de | www.titanchat.de -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10326: Error while inserting cyrillic symbols into database
From: [EMAIL PROTECTED]
Operating system: Windows NT4 SP6
PHP version: 4.0.4
PHP Bug Type: InterBase related
Bug description: Error while inserting cyrillic symbols into database
Environment:
Windows NT 4.0 SP6
PHP v4.0.4 (binaries from www.php.net)
InterBase v6.0.0.627
Apache v1.3.17
The following is metadata for simple InterBase database and short script that tries
to insert a range of symbols into this database.
All works ok while inserting symbols with codes lower than 128, but for all symbols
with codes greater than 128 (included cyrillic symbols in windows-1251 code page with
codes in range 192..255) the following error is received:
Warning: InterBase: arithmetic exception, numeric overflow, or string truncation
Cannot transliterate character between character sets in d:\web\dom\test\qqq.php on
line 7
Note, that nothing is actually inserted into database. Executing the same query
directly into InterBase causes data to be inserted properly
Database metadata:
==
SET SQL DIALECT 3;
SET NAMES WIN1251;
CREATE DATABASE 'D:\db\base.gdb' USER 'user' PASSWORD 'password'
PAGE_SIZE 4096
DEFAULT CHARACTER SET WIN1251;
CREATE GENERATOR GEN_TEST_ID;
SET GENERATOR GEN_TEST_ID TO 0;
CREATE TABLE TEST (
ID INTEGER NOT NULL,
TEXT VARCHAR(100));
SET TERM ^ ;
CREATE TRIGGER TEST_BI FOR TEST
ACTIVE BEFORE INSERT POSITION 0
AS
BEGIN
IF (NEW.ID IS NULL) THEN
NEW.ID = GEN_ID(GEN_TEST_ID,1);
END
^
SET TERM ; ^
Test PHP script to reproduce bug:
=
?php
$ib = ibase_connect("d:\\db\\base.gdb" , "user", "password");
for ($i=60;$i256;$i++)
{
$sql = "INSERT INTO TEST (TEXT) VALUES ('".chr($i)."');";
echo $sql."br";
$query = ibase_query($ib,$sql);
};
ibase_close($ib);
?
--
Edit Bug report at: http://bugs.php.net/?id=10326edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10327: urldecode decodes url-encoded cyrillic strings incorrectly.
From: [EMAIL PROTECTED]
Operating system: FreeBSD 4.1-RELEASE
PHP version: 4.0.3pl1
PHP Bug Type: *URL Functions
Bug description: "urldecode" decodes url-encoded cyrillic strings incorrectly.
?php
//Write encoding
echo "Src: ".urlencode("Çàïèñü óñïåøíî èçìåíåíà")."br\n";
//Wrong decoding
echo "Src-Dst: ".urldecode(urlencode("Çàïèñü óñïåøíî èçìåíåíà"))."br\n";
//Write encoding of wrong decoding. See the difference!!!
echo "Src-Dst-Src: ".urlencode(urldecode(urlencode("Çàïèñü óñïåøíî
èçìåíåíà")))."br\n";
?
'./configure' '--without-x' '--enable-track-vars'
'--with-apache=../apache_1.3.14rusPL30.0' '--with-mod_charset' '--with-gd'
'--enable-ftp' '--with-mysql=/usr/local' '--with-pcre-regex'
Here you can see dump of phpinfo() function in our
system.
http://www.77rus.ru/manager/questions/a.php
--
Edit Bug report at: http://bugs.php.net/?id=10327edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] CVS Account Request
Full name: Jeffery Charles Cann Email: [EMAIL PROTECTED] ID: jccann Purpose: PEAR commits -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10330: imap-2001.BETA and imap-ssl support in PHP4
From: [EMAIL PROTECTED] Operating system: i386-slackware-linux-gnu PHP version: 4.0 Latest CVS (14/04/2001) PHP Bug Type: IMAP related Bug description: imap-2001.BETA and imap-ssl support in PHP4 I've built the imap-2001.BETA toolkit with SSL (OpenSSL 0.9.6a) support and copied the c-client header files in a 'standard' location and c-client library files, but when compiling PHP4-cvs --with-imap-ssl support I get the following error: config.nice: "./configure" \ "--with-apxs" \ "--with-config-file-path=/var/www/conf" \ "--with-gdbm" \ "--with-gettext" \ "--with-imap" \ "--with-imap-ssl" \ "--with-mysql" \ "--with-openssl" \ "--with-regex=system" \ "--with-zlib" \ "--enable-memory-limit" \ "--enable-safe-mode" \ "--enable-track-vars" \ "--enable-bcmath" \ "--enable-wddx" \ "--enable-xml" \ $ make ... -DTARGET="httpsd" -DUSE_HSREGEX -DUSE_EXPAT -DAPACHE_SSL -DSUPPORT_UTF8 -DXML_BYTE_ORDER=12 -g -O2 -c php_imap.c php_imap.c: In function `php_minit_imap': php_imap.c:450: `auth_ssl' undeclared (first use in this function) php_imap.c:450: (Each undeclared identifier is reported only once php_imap.c:450: for each function it appears in.) make[3]: *** [php_imap.lo] Error 1 make[3]: Leaving directory `/home/raul/src/cvs/php4/ext/imap' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/raul/src/cvs/php4/ext/imap' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/raul/src/cvs/php4/ext' make: *** [all-recursive] Error 1 ~/src/imap-2001.BETA.SNAP-0104140025$ cat c-client/linkage.c mail_link (mboxdriver); /* link in the mbox driver */ mail_link (imapdriver); /* link in the imap driver */ mail_link (nntpdriver); /* link in the nntp driver */ mail_link (pop3driver); /* link in the pop3 driver */ mail_link (mhdriver);/* link in the mh driver */ mail_link (mxdriver);/* link in the mx driver */ mail_link (mbxdriver); /* link in the mbx driver */ mail_link (tenexdriver); /* link in the tenex driver */ mail_link (mtxdriver); /* link in the mtx driver */ mail_link (mmdfdriver); /* link in the mmdf driver */ mail_link (unixdriver); /* link in the unix driver */ mail_link (newsdriver); /* link in the news driver */ mail_link (philedriver); /* link in the phile driver */ mail_link (dummydriver); /* link in the dummy driver */ auth_link (auth_md5);/* link in the md5 authenticator */ auth_link (auth_pla);/* link in the pla authenticator */ auth_link (auth_log);/* link in the log authenticator */ ssl_onceonlyinit (); Thank you. Raul -- Edit Bug report at: http://bugs.php.net/?id=10330edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
