#17959 [Com]: array reference problems
ID: 17959
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Scripting Engine problem
Operating System: linux
PHP Version: 4.2.1
New Comment:
I have experienced similar problems with PHP on Linux 2.4.x. It only
seems to occur in very weird circumstances where you have a reference
pointing (yes I know references are not pointers) to an array element.
My only test cases are much larger that those presented by
"[EMAIL PROTECTED]" as they involve production code. The one piece of
information I can offer which may be of some use is that in my case,
the problem can be eliminated by removing an uneeded "global" statement
(the reference was already in scope). I realize that sounds absurd,
but I have a case where "global" actually breaks the reference. When I
comment out the global statement, the reference doesn't get wiped out.
I know the reference is global because it was created in $GLOBALS. I
know this seems strange, but I can var_dump it before and after and the
only thing that changes is me commenting out the global statement.
Previous Comments:
[2002-07-29 06:50:20] [EMAIL PROTECTED]
'top',
'A' => array
(
'name' => 'A',
'A_a' => array
(
'name' => 'A_a',
'fn_1' => 'Aa_fn_1',
'fn_2' => 'Aa_fn_2',
'fn_3' => 'Aa_fn_3',
'A_a_1' => array
(
'name' => 'A_a_1',
'fn_1' => 'Aa1_fn_1',
'fn_2' => 'Aa1_fn_2',
),
'A_a_2' => array
(
'name' => 'A_a_2',
'fn_1' => 'Aa2_fn_1',
'fn_2' => 'Aa2_fn_2',
),
),
),
);
// setup "parent references" for each of the nodes.
$top['parent'] = null;
$top['A']['parent'] = &$top;
$top['A']['A_a']['parent'] = &$top['A'];
$top['A']['A_a']['A_a_1']['parent'] = &$top['A']['A_a'];
$top['A']['A_a']['A_a_2']['parent'] = &$top['A']['A_a'];
//$top['A']['A_a']['A_a_1']['parent'] = &$top['A']['A_a'];
//
// Note!
// Here if we uncomment the above line the sample code will
// magically WORK!
//
// Why does the order of initialization matter!? And will the
// code now break elsewhere?
// setup our reference to $top. $ptr is what should change
// on every call to change_ptr(name).
$ptr = &$top;
// change_ptr( name ) does the following w/some verbose
// messages to display the state of variables in question.
//
//if ( ptr[name] )
// ptr = ptr[name];
//
function change_ptr( $name )
{
printf( " change_ptr($name) " );
if ( $GLOBALS['ptr'][$name] ) {
// Setting up string for later printing.
$before_change =
sprintf( "before: \$GLOBALS['ptr']['name'] = %s",
$GLOBALS['ptr']['name'] );
$GLOBALS['ptr'] = &$GLOBALS['ptr'][$name];
$after_change =
sprintf( "after: \$GLOBALS['ptr']['name'] = %s",
$GLOBALS['ptr']['name'] );
printf( "CHANGED:\n" );
printf( "%s\n %s", $before_change, $after_change );
}
else
printf( "NO CHANGE!" );
printf( "\n" );
}
?>
[2002-07-23 16:24:54] [EMAIL PROTECTED]
think of the "global $p;" construct as a shortcut for
"$p = &$GLOBALS['p'];"
so by assigning a new reference you are breaking the one to the global
variable
so you have to explicitly assign to $GLOBALS["p"] here
(marked as documentation problem)
[2002-07-16 08:40:10] [EMAIL PROTECTED]
'top',
'A' => array ( 'name' => 'A', ),
'B' => array
(
'name' => 'B',
'B_b' => array ( 'name' => 'B_b', ),
),
);
// setup "parent references" for each of the nodes.
$top['parent'] = null;
$top['A']['parent'] = &$top;
$top['B']['parent'] = &$top;
$top['B']['B_b']['parent'] = &$top['B'];
// setup our reference to $top. $ptr is what should change
// on every call to change_ptr(name).
$ptr = &$top;
// $i and $iref are meant to demonstrate the inconsistency
// of manipulating references w/in functions.
$i= 0;
$iref = &$i;
// change_ptr( name ) does the following w/some verbose
// messages to display the state of variables in question.
//
//if ( ptr[name] )
// ptr = ptr[name];
//
function change_ptr( $name )
{
// This case demonstrates how change_pt
#20728 [NEW]: $_SESSION can be broken with "global"
From: [EMAIL PROTECTED]
Operating system: Linux 2.4.x
PHP version: 4.2.3
PHP Bug Type: Session related
Bug description: $_SESSION can be broken with "global"
First, please ignore my comment on bug #17959, I have further investigated
this
issue to narrow down exactly what is causing it and have written a test
script
so that you can verify this on your end as well. This bug (should you
accept to
proclaim it a vaild bug) relates to the autoglobal $_SESSION. More
specifically, $_SESSION can be broken so that the values set in it are not
actually saved. First, lets see how it can be broken:
';
var_dump($_SESSION);
$_SESSION['foobar'] = 1;
global $_SESSION;
$_SESSION['foobar'] = 2;
echo 'After session modifications:';
var_dump($_SESSION);
?>
When you run this, and then hit reload (since you must run it at least
twice to
see what actually got saved by session), the browser will output this:
Before session modifications (what got saved to disk):
array(1) {
["foobar"]=>
int(1)
}
After session modifications:
array(1) {
["foobar"]=>
int(2)
}
So, you can see that the line "global $_SESSION;" essentially breaks
session -
the "2" never gets saved to disk. If we comment out "global $_SESSION;",
it
works and the browser outputs this (after you hit reload twice):
Before session modifications:
array(1) {
["foobar"]=>
int(2)
}
After session modifications:
array(1) {
["foobar"]=>
int(2)
}
So now you are asking that is interesting, but why would you ever want to
"global" an autoglobal. Good question! There would be no purpose in
doing this
since $_SESSION is always in scope. Well, this bug presented itself to me
in
an application where there was a reference to a portion of $_SESSION.
Since
the application is over 5000 lines of code, we will view a highly
condensed
test version of this:
';
var_dump($_SESSION);
$_SESSION['foobar'] = 1;
$foobar = $_SESSION['foobar'];
global $foobar;
$foobar = 3;
echo 'After session modifications:';
var_dump($_SESSION);
?>
Outputs:
Before session modifications:
array(1) {
["foobar"]=>
int(1)
}
After session modifications:
array(1) {
["foobar"]=>
&int(1)
}
And if we comment out "global $foobar;" we get:
Before session modifications:
array(1) {
["foobar"]=>
int(1)
}
After session modifications:
array(1) {
["foobar"]=>
&int(3)
}
This is the behavior we would expect with a reference given the output we
saw in
the earlier example. But why would we run "global $foobar;" if it is
already
in scope? In my application, other developers use the code for purposes
of
building other applications. Since I don't know what scope they are
including
my code in, I have to assume it is NOT in global scope and therefore run
"global" on some variables that I will need. In this sort of situation it
makes
sense to call "global" just to make sure that you have what you need.
The
problem is that if they did include it in global scope that it busts
session!!!
Anyways, I look forward to your response. I have already implemented a
workaround to this problem but think it is important that the PHP QA/BUG
teams
are aware of this issue.
Thank You for you time - everyone appreciates the work that you do for
PHP
P.S. My configure line is:
'./configure' '--enable-memory-limit' '--with-mysql=/usr/local/mysql'
'--with-zlib' '--with-apache=../apache_1.3.27'
'--enable-inline-optimization' '--with-curl=/usr/local'
'--with-mcrypt=/usr/local'
--
Edit bug report at http://bugs.php.net/?id=20728&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=20728&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=20728&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=20728&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=20728&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=20728&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=20728&r=support
Expected behavior: http://bugs.php.net/fix.php?id=20728&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=20728&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=20728&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=20728&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20728&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=20728&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=20728&r=isapi
#20728 [Fbk->Opn]: $_SESSION can be broken with "global"
ID: 20728
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Open
Bug Type: Session related
Operating System: Linux 2.4.x
PHP Version: 4.2.3
New Comment:
Hello,
I have compiled the latest snap shot at
http://snaps.php.net/php4-latest.tar.gz. The only change I had to make
for the PHP compiling process was to update my version of curl since
the snapshot requires curl-7.10.2 (the latest stable release). It
compiled fine, I restarted the web server, and the same problem still
occurs with the same code from my original bug post.
Please let me know if you need any additional information.
Mike
Previous Comments:
[2002-11-29 15:23:07] [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-11-29 13:53:57] [EMAIL PROTECTED]
First, please ignore my comment on bug #17959, I have further
investigated this
issue to narrow down exactly what is causing it and have written a test
script
so that you can verify this on your end as well. This bug (should you
accept to
proclaim it a vaild bug) relates to the autoglobal $_SESSION. More
specifically, $_SESSION can be broken so that the values set in it are
not
actually saved. First, lets see how it can be broken:
';
var_dump($_SESSION);
$_SESSION['foobar'] = 1;
global $_SESSION;
$_SESSION['foobar'] = 2;
echo 'After session modifications:';
var_dump($_SESSION);
?>
When you run this, and then hit reload (since you must run it at least
twice to
see what actually got saved by session), the browser will output this:
Before session modifications (what got saved to disk):
array(1) {
["foobar"]=>
int(1)
}
After session modifications:
array(1) {
["foobar"]=>
int(2)
}
So, you can see that the line "global $_SESSION;" essentially breaks
session -
the "2" never gets saved to disk. If we comment out "global
$_SESSION;", it
works and the browser outputs this (after you hit reload twice):
Before session modifications:
array(1) {
["foobar"]=>
int(2)
}
After session modifications:
array(1) {
["foobar"]=>
int(2)
}
So now you are asking that is interesting, but why would you ever want
to
"global" an autoglobal. Good question! There would be no purpose in
doing this
since $_SESSION is always in scope. Well, this bug presented itself to
me in
an application where there was a reference to a portion of $_SESSION.
Since
the application is over 5000 lines of code, we will view a highly
condensed
test version of this:
';
var_dump($_SESSION);
$_SESSION['foobar'] = 1;
$foobar = $_SESSION['foobar'];
global $foobar;
$foobar = 3;
echo 'After session modifications:';
var_dump($_SESSION);
?>
Outputs:
Before session modifications:
array(1) {
["foobar"]=>
int(1)
}
After session modifications:
array(1) {
["foobar"]=>
&int(1)
}
And if we comment out "global $foobar;" we get:
Before session modifications:
array(1) {
["foobar"]=>
int(1)
}
After session modifications:
array(1) {
["foobar"]=>
&int(3)
}
This is the behavior we would expect with a reference given the output
we saw in
the earlier example. But why would we run "global $foobar;" if it is
already
in scope? In my application, other developers use the code for
purposes of
building other applications. Since I don't know what scope they are
including
my code in, I have to assume it is NOT in global scope and therefore
run
"global" on some variables that I will need. In this sort of situation
it makes
sense to call "global" just to make sure that you have what you need.
The
problem is that if they did include it in global scope that it busts
session!!!
Anyways, I look forward to your response. I have already implemented
a
workaround to this problem but think it is important that the PHP
QA/BUG teams
are aware of this issue.
Thank You for you time - everyone appreciates the work that you do for
PHP
P.S. My configure line is:
'./configure' '--enable-memory-limit' '--with-mysql=/usr/local/mysql'
'--with-zlib' '--with-apache=../apache_1.3.27'
'--enable-inline-optimization' '--with-curl=/usr/local'
'--with-mcrypt=/usr/local'
--
Edit this bug report at http://bugs.php.net/?id=20728&edit=1
#20728 [Bgs->Opn]: $_SESSION can be broken with "global"
ID: 20728
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Bogus
+Status: Open
Bug Type: Session related
Operating System: Linux 2.4.x
PHP Version: 4.2.3
New Comment:
Hello,
I don;t think it is quote as easy as saying "Don't use global with the
autoglobal arrays.". Please read my original bug post. I went out of
my way to be very detailed so that I don't waste your time - this does
nobody any good though if you don't take the time to read it. More
specifically, this is the part I am referring to:
So now you are asking that is interesting, but why would you ever want
to "global" an autoglobal. Good question! There would be no purpose
in doing this since $_SESSION is always in scope. Well, this bug
presented itself to me in an application where there was a reference to
a portion of $_SESSION. Since the application is over 5000 lines of
code, we will view a highly condensed test version of this:
';
var_dump($_SESSION);
$_SESSION['foobar'] = 1;
$foobar = $_SESSION['foobar'];
global $foobar;
$foobar = 3;
echo 'After session modifications:';
var_dump($_SESSION);
?>
So the bug presents itself when you "global" a reference to an array
element of an autoglobal as well. Perhaps, I should have used this as
the original code example. Please take the time to read the full bug
post.
Thank You,
Mike
Previous Comments:
[2002-11-29 20:58:08] [EMAIL PROTECTED]
Don't use global with the autoglobal arrays.
[2002-11-29 17:59:17] [EMAIL PROTECTED]
Hello,
I have compiled the latest snap shot at
http://snaps.php.net/php4-latest.tar.gz. The only change I had to make
for the PHP compiling process was to update my version of curl since
the snapshot requires curl-7.10.2 (the latest stable release). It
compiled fine, I restarted the web server, and the same problem still
occurs with the same code from my original bug post.
Please let me know if you need any additional information.
Mike
[2002-11-29 15:23:07] [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-11-29 13:53:57] [EMAIL PROTECTED]
First, please ignore my comment on bug #17959, I have further
investigated this
issue to narrow down exactly what is causing it and have written a test
script
so that you can verify this on your end as well. This bug (should you
accept to
proclaim it a vaild bug) relates to the autoglobal $_SESSION. More
specifically, $_SESSION can be broken so that the values set in it are
not
actually saved. First, lets see how it can be broken:
';
var_dump($_SESSION);
$_SESSION['foobar'] = 1;
global $_SESSION;
$_SESSION['foobar'] = 2;
echo 'After session modifications:';
var_dump($_SESSION);
?>
When you run this, and then hit reload (since you must run it at least
twice to
see what actually got saved by session), the browser will output this:
Before session modifications (what got saved to disk):
array(1) {
["foobar"]=>
int(1)
}
After session modifications:
array(1) {
["foobar"]=>
int(2)
}
So, you can see that the line "global $_SESSION;" essentially breaks
session -
the "2" never gets saved to disk. If we comment out "global
$_SESSION;", it
works and the browser outputs this (after you hit reload twice):
Before session modifications:
array(1) {
["foobar"]=>
int(2)
}
After session modifications:
array(1) {
["foobar"]=>
int(2)
}
So now you are asking that is interesting, but why would you ever want
to
"global" an autoglobal. Good question! There would be no purpose in
doing this
since $_SESSION is always in scope. Well, this bug presented itself to
me in
an application where there was a reference to a portion of $_SESSION.
Since
the application is over 5000 lines of code, we will view a highly
condensed
test version of this:
';
var_dump($_SESSION);
$_SESSION['foobar'] = 1;
$foobar = $_SESSION['foobar'];
global $foobar;
$foobar = 3;
echo 'After session modifications:';
var_dump($_SESSION);
?>
Outputs:
Before session modifications:
array(1) {
["foobar"]=>
int(1)
}
After session modifications:
array(1) {
["foobar"]=>
&int(1)
}
And if we comment out "global $foobar;" we get:
Before session modifications:
array(1) {
["foobar"]=>
int(1)
}
After session modifications:
array(1) {
["foobar"]=>
&int(3)
}
This is the behavior we would expect with a reference given the output
we saw in
the earlier example. But why would we run
#20728 [Csd->Opn]: $_SESSION can be broken with "global"
ID: 20728
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Closed
+Status: Open
Bug Type: Session related
Operating System: Linux 2.4.x
PHP Version: 4.2.3
New Comment:
Hello,
This code is incorrect - I must have pasted over the code after I
modified it during testing as $foobar is not a reference, but a copy.
Here is what it should be (please note that you will have to hit reload
after the first hit as session gets created on the first hit - so load
it and hit reload - and then view the output):
';
var_dump($_SESSION);
$_SESSION['foobar'] = 1;
$foobar =& $_SESSION['foobar'];
global $foobar;
$foobar = 3;
echo 'After session modifications:';
var_dump($_SESSION);
?>
Previous Comments:
[2002-12-01 16:13:01] [EMAIL PROTECTED]
I get this normal output:
Before session modifications:
array(1) {
["foobar"]=>
int(1)
}
After session modifications:
array(1) {
["foobar"]=>
int(1)
}
No bug here. (using PHP 4.3.0-dev)
[2002-12-01 16:07:16] [EMAIL PROTECTED]
Hello,
I don;t think it is quote as easy as saying "Don't use global with the
autoglobal arrays.". Please read my original bug post. I went out of
my way to be very detailed so that I don't waste your time - this does
nobody any good though if you don't take the time to read it. More
specifically, this is the part I am referring to:
So now you are asking that is interesting, but why would you ever want
to "global" an autoglobal. Good question! There would be no purpose
in doing this since $_SESSION is always in scope. Well, this bug
presented itself to me in an application where there was a reference to
a portion of $_SESSION. Since the application is over 5000 lines of
code, we will view a highly condensed test version of this:
';
var_dump($_SESSION);
$_SESSION['foobar'] = 1;
$foobar = $_SESSION['foobar'];
global $foobar;
$foobar = 3;
echo 'After session modifications:';
var_dump($_SESSION);
?>
So the bug presents itself when you "global" a reference to an array
element of an autoglobal as well. Perhaps, I should have used this as
the original code example. Please take the time to read the full bug
post.
Thank You,
Mike
[2002-11-29 20:58:08] [EMAIL PROTECTED]
Don't use global with the autoglobal arrays.
[2002-11-29 17:59:17] [EMAIL PROTECTED]
Hello,
I have compiled the latest snap shot at
http://snaps.php.net/php4-latest.tar.gz. The only change I had to make
for the PHP compiling process was to update my version of curl since
the snapshot requires curl-7.10.2 (the latest stable release). It
compiled fine, I restarted the web server, and the same problem still
occurs with the same code from my original bug post.
Please let me know if you need any additional information.
Mike
[2002-11-29 15:23:07] [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
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/20728
--
Edit this bug report at http://bugs.php.net/?id=20728&edit=1
#24006 [NEW]: Segmentation fault - related possibly to error handling functions
From: mikemc-phpbug at contactdesigns dot com
Operating system: Linux 2.4.x
PHP version: 4.3.2
PHP Bug Type: Reproducible crash
Bug description: Segmentation fault - related possibly to error handling functions
I have code that ran fine under 4.3.1 compiled with Apache like so:
'./configure' '--with-openssl' '--enable-memory-limit'
'--with-mysql=/usr/local/mysql' '--with-zlib'
'--with-apache=../apache_1.3.27' '--enable-inline-optimization'
'--with-curl=/usr/local' '--with-mcrypt=/usr/local'
It was compiled the same exact way with 4.3.2 except with a newer version
of curl.
This same code now causes a segmentation fault under 4.3.2:
[Tue Jun 3 21:25:51 2003] [notice] child pid 12107 exit signal
Segmentation fault (11)
The offending code is related to a user defined error handler. My current
workaround: remove the error handling code. I have isolated the problem
to a single file and a function within that file. When I comment out the
code that loads this file and calls that function, the segfaults stop and
the code runs as normal:
//include_once('lib/Error/Handler.php');
//CDS_Error_Handler_Init();
Furthermore, I have to call the function - loading the file alone does not
cause the problem. This error handler is a very old version of our
current one which has changed significantly and has no problems in 4.3.2.
You can find the code here:
http://caffeine.contactdesigns.com/~jolt/Handler.phps
I hope this helps - I am in no way put in a bind because of this bug - it
is old code and does nothing for us now. Just hoping to help PHP out in
any way possible. I tried out RC1 on the developemntal servers, but as
it is sometimes, you don't catch the bug until you go to production.
--
Edit bug report at http://bugs.php.net/?id=24006&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=24006&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=24006&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=24006&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=24006&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=24006&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=24006&r=support
Expected behavior: http://bugs.php.net/fix.php?id=24006&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=24006&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=24006&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=24006&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24006&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=24006&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=24006&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=24006&r=gnused
#24006 [Fbk->Opn]: Segmentation fault - related possibly to error handling functions
ID: 24006
User updated by: mikemc-phpbug at contactdesigns dot com
Reported By: mikemc-phpbug at contactdesigns dot com
-Status: Feedback
+Status: Open
Bug Type: Reproducible crash
Operating System: Linux 2.4.x
PHP Version: 4.3.2
New Comment:
Here are the config parameters you will need to set prior to running
the code (I only changed 4 from the original config where the crash was
happening):
// Set environment - either production or development
$CDS_CONFIG['ENV_MODE'] = 'production';
// Semicolon delimited list of developers responsible
$CDS_CONFIG['ADMINS'] = '[EMAIL PROTECTED]';
// Error log - be sure to specify full path
$CDS_CONFIG['ERROR_LOG'] = '/tmp/error.log';
// Template to be displayed to end users in production environment when
an error
// occurs. For example, "The web server has fallen and can't get up"
;-)
$CDS_CONFIG['ERROR_TEMPLATE'] = '/tmp/error_template.html';
// Error callback function that can alter the way the error handler
behaves.
// Read lib/Error/Handler.php for more information.
$CDS_CONFIG['ERROR_CALLBACK'] = NULL;
// Set the error reporting level based on the environment
$CDS_CONFIG['ERROR_REPORTING'] = ($CDS_CONFIG['ENV_MODE'] ==
'development')
? (E_ERROR | E_WARNING | E_PARSE |
E_NOTICE)
: (E_ALL & ~E_NOTICE);
// Log that debug messages are sent to (tail -f this file during
debugging)
$CDS_CONFIG['DEBUG_LOG'] = '/tmp/debug.log';
// Specify where debug output goes ("browser" or "log")
$CDS_CONFIG['DEBUG_MODE'] = 'browser';
// Regular expression specifying which variables are not sent to debug
output
$CDS_CONFIG['DEBUG_EXCLUSION'] = '/.*(?:HTTP|CDS)/s';
Previous Comments:
[2003-06-04 01:10:44] [EMAIL PROTECTED]
I can not reproduce this, I only get this:
Fatal error: CDS_Error_Handler_Init() - Missing parameters in
/home/jani/t.php on line 62
(I just took that handler.phps and pasted it to a file and added the
CDS_Error_Handler_Init(); line)
Could you please try creating a SHORT example script
which can be just copied and run..?
And/Or generate a GDB backtrace of this crash..
[2003-06-03 23:55:42] mikemc-phpbug at contactdesigns dot com
I have code that ran fine under 4.3.1 compiled with Apache like so:
'./configure' '--with-openssl' '--enable-memory-limit'
'--with-mysql=/usr/local/mysql' '--with-zlib'
'--with-apache=../apache_1.3.27' '--enable-inline-optimization'
'--with-curl=/usr/local' '--with-mcrypt=/usr/local'
It was compiled the same exact way with 4.3.2 except with a newer
version of curl.
This same code now causes a segmentation fault under 4.3.2:
[Tue Jun 3 21:25:51 2003] [notice] child pid 12107 exit signal
Segmentation fault (11)
The offending code is related to a user defined error handler. My
current workaround: remove the error handling code. I have isolated
the problem to a single file and a function within that file. When I
comment out the code that loads this file and calls that function, the
segfaults stop and the code runs as normal:
//include_once('lib/Error/Handler.php');
//CDS_Error_Handler_Init();
Furthermore, I have to call the function - loading the file alone does
not cause the problem. This error handler is a very old version of our
current one which has changed significantly and has no problems in
4.3.2. You can find the code here:
http://caffeine.contactdesigns.com/~jolt/Handler.phps
I hope this helps - I am in no way put in a bind because of this bug -
it is old code and does nothing for us now. Just hoping to help PHP
out in any way possible. I tried out RC1 on the developemntal
servers, but as it is sometimes, you don't catch the bug until you go
to production.
--
Edit this bug report at http://bugs.php.net/?id=24006&edit=1
[PHP-BUG] Bug #60419 [NEW]: PCRE segfault
From: Operating system: linux PHP version: 5.3.8 Package: PCRE related Bug Type: Bug Bug description:PCRE segfault Description: Tested this on my custom built 5.3.8 and the standard 5.3.8 that ships with FC 15 - same result in both so I assume it is not specific to my build. Run the test code - it will segfault. Not sure if this is PHP related (PHP hooks into PCRE) or solely lives inside PCRE. Test script: --- https://bugs.php.net/bug.php?id=60419&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60419&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60419&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60419&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60419&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60419&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60419&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60419&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60419&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60419&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60419&r=support Expected behavior: https://bugs.php.net/fix.php?id=60419&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60419&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60419&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60419&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60419&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60419&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60419&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60419&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60419&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60419&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60419&r=mysqlcfg
Bug #60419 [Com]: PCRE segfault
Edit report at https://bugs.php.net/bug.php?id=60419&edit=1 ID: 60419 Comment by: mikemc-phpbug at terabytemedia dot com Reported by:mikemc-phpbug at terabytemedia dot com Summary:PCRE segfault Status: Open Type: Bug Package:PCRE related Operating System: linux PHP Version:5.3.8 Block user comment: N Private report: N New Comment: Removing the "\s?" from the pattern alleviates the issue (no crashing), but of course, then the pattern does not serve a purpose for me. Previous Comments: [2011-11-30 16:23:21] mikemc-phpbug at terabytemedia dot com Description: Tested this on my custom built 5.3.8 and the standard 5.3.8 that ships with FC 15 - same result in both so I assume it is not specific to my build. Run the test code - it will segfault. Not sure if this is PHP related (PHP hooks into PCRE) or solely lives inside PCRE. Test script: --- https://bugs.php.net/bug.php?id=60419&edit=1
