#32514 [Fbk->Opn]: session_start() crashes when session exists
ID: 32514
User updated by: red at raven dot ch
Reported By: red at raven dot ch
-Status: Feedback
+Status: Open
Bug Type: Session related
Operating System: Fedora Core 3
PHP Version: 5.0.3
New Comment:
tried the latest snapshot (200503312030) . still the same.
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1208932672 (LWP 3881)]
0x012dbcee in zend_do_fcall_common_helper_SPEC
(execute_data=0xbfe190b0)
at zend_vm_execute.h:120
120 if (EX(function_state).function->common.fn_flags &
ZEND_ACC_ABST
RACT) {
(gdb) bt
#0 0x012dbcee in zend_do_fcall_common_helper_SPEC
(execute_data=0xbfe190b0)
at zend_vm_execute.h:120
#1 0x012dc705 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(execute_data=0xbfe190b0)
at zend_vm_execute.h:288
#2 0x012dbc3b in execute (op_array=0x8a24f6c) at zend_vm_execute.h:78
#3 0x012dc073 in zend_do_fcall_common_helper_SPEC
(execute_data=0xbfe19220)
at zend_vm_execute.h:204
#4 0x012dc705 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(execute_data=0xbfe19220)
at zend_vm_execute.h:288
#5 0x012dbc3b in execute (op_array=0x875be54) at zend_vm_execute.h:78
#6 0x012dc073 in zend_do_fcall_common_helper_SPEC
(execute_data=0xbfe19360)
at zend_vm_execute.h:204
#7 0x012dc705 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(execute_data=0xbfe19360)
at zend_vm_execute.h:288
#8 0x012dbc3b in execute (op_array=0x875ae9c) at zend_vm_execute.h:78
#9 0x0130d185 in ZEND_INCLUDE_OR_EVAL_SPEC_CV_HANDLER (
execute_data=0xbfe194d0) at zend_vm_execute.h:18130
#10 0x012dbc3b in execute (op_array=0x88f01c4) at zend_vm_execute.h:78
#11 0x012dc073 in zend_do_fcall_common_helper_SPEC
(execute_data=0xbfe19670)
at zend_vm_execute.h:204
#12 0x012dc705 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(execute_data=0xbfe19670)
at zend_vm_execute.h:288
#13 0x012dbc3b in execute (op_array=0x870ad08) at zend_vm_execute.h:78
#14 0x012ac2f3 in zend_call_function (fci=0xbfe19810,
fci_cache=0xbfe19800)
at /usr/local/src/php5-200503312030/Zend/zend_execute_API.c:851
#15 0x012ac842 in zend_lookup_class (name=0x876b32c "User",
name_length=4,
ce=0xbfe198e4)
at /usr/local/src/php5-200503312030/Zend/zend_execute_API.c:956
#16 0x0125c5fa in php_var_unserialize (rval=0xbfe19950, p=0xbfe19a90,
max=0x87e05e8 "\204�217*A", var_hash=0xbfe19a70)
at
/usr/local/src/php5-200503312030/ext/standard/var_unserializer.c:565
#17 0x0125d704 in process_nested_data (rval=0xbfe19a84, p=0xbfe19a90,
max=0x87e05e8 "\204�217*A", var_hash=0xbfe19a70,
ht=0x87e192c,
elements=0)
at
/usr/local/src/php5-200503312030/ext/standard/var_unserializer.c:232
#18 0x0125da92 in object_common2 (rval=0xbfe19a84, p=0xbfe19a90,
max=0x87e05e8 "\204�217*A", var_hash=0xbfe19a70,
elements=4)
at
/usr/local/src/php5-200503312030/ext/standard/var_unserializer.c:322
#19 0x0125c8fd in php_var_unserialize (rval=0xbfe19a84, p=0xbfe19a90,
max=0x87e05e8 "\204�217*A", var_hash=0xbfe19a70)
at
/usr/local/src/php5-200503312030/ext/standard/var_unserializer.c:623
#20 0x01150b56 in ps_srlzr_decode_php (
val=0x87dfd34 "VidaAuth|O:8:\"VidaAuth\":4:{s:14:\"", vallen=2228)
at /usr/local/src/php5-200503312030/ext/session/session.c:509
#21 0x01151015 in php_session_decode (
val=0x87dfd34 "VidaAuth|O:8:\"VidaAuth\":4:{s:14:\"", vallen=2228)
at /usr/local/src/php5-200503312030/ext/session/session.c:571
#22 0x011515a8 in php_session_initialize ()
at /usr/local/src/php5-200503312030/ext/session/session.c:752
#23 0x01153265 in php_session_start ()
at /usr/local/src/php5-200503312030/ext/session/session.c:1203
#24 0x01154c98 in zif_session_start (ht=0, return_value=0x8762bc4,
this_ptr=0x0, return_value_used=0)
at /usr/local/src/php5-200503312030/ext/session/session.c:1665
#25 0x012dbf22 in zend_do_fcall_common_helper_SPEC
(execute_data=0xbfe19e70)
at zend_vm_execute.h:175
#26 0x012e0074 in ZEND_DO_FCALL_SPEC_CONST_HANDLER
(execute_data=0xbfe19e70)
at zend_vm_execute.h:1535
#27 0x012dbc3b in execute (op_array=0x870e19c) at zend_vm_execute.h:78
#28 0x0130d185 in ZEND_INCLUDE_OR_EVAL_SPEC_CV_HANDLER (
execute_data=0xbfe1a150) at zend_vm_execute.h:18130
#29 0x012dbc3b in execute (op_array=0x8a01be4) at zend_vm_execute.h:78
#30 0x012e0b88 in ZEND_INCLUDE_OR_EVAL_SPEC_CONST_HANDLER (
execute_data=0xbfe1a350) at zend_vm_execute.h:1835
#31 0x012dbc3b in execute (op_array=0x876e204) at zend_vm_execute.h:78
#32 0x012b7752 in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at /usr/local/src/php5-200503312030/Zend/zend.c:1059
#33 0x0127711a in php_execute_script (primary_file=0xbfe1c6c0)
at /usr/local/src/php5-200503312030/main/main.c:1639
#34 0x01328681 in php_handler (r=0x86fb2a8)
at /usr/local/src/php5-200503312030/sapi/apache2handler/sa
#35 0x0087a9f7
#32514 [Bgs]: session_start() crashes when session exists
ID: 32514
User updated by: red at raven dot ch
Reported By: red at raven dot ch
Status: Bogus
Bug Type: Session related
Operating System: Fedora Core 3
PHP Version: 5CVS-2005-03-30
New Comment:
but why is it possible if it's no a good idea?
Previous Comments:
[2005-04-05 01:43:18] [EMAIL PROTECTED]
Have you ever thought that it might not be good idea to put everything
into a session?
[2005-04-04 10:32:08] red at raven dot ch
Sorry, I can't reduce this to a few lines of code. It seems this
segmentation fault does only occure in rather complex situations (and I
can't put the finger on it). I'm working with the Vida-Framework (
http://www.vidaframework.ch/ - latest cvs-version) and it seems the
problem can be found in these lines:
[2005-04-03 01:09:52] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc.
If possible, make the script source available online and provide
an URL to it here. Try to avoid embedding huge scripts into the report.
[2005-04-01 00:02:40] red at raven dot ch
tried the latest snapshot (200503312030) . still the same.
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1208932672 (LWP 3881)]
0x012dbcee in zend_do_fcall_common_helper_SPEC
(execute_data=0xbfe190b0)
at zend_vm_execute.h:120
120 if (EX(function_state).function->common.fn_flags &
ZEND_ACC_ABST
RACT) {
(gdb) bt
#0 0x012dbcee in zend_do_fcall_common_helper_SPEC
(execute_data=0xbfe190b0)
at zend_vm_execute.h:120
#1 0x012dc705 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(execute_data=0xbfe190b0)
at zend_vm_execute.h:288
#2 0x012dbc3b in execute (op_array=0x8a24f6c) at zend_vm_execute.h:78
#3 0x012dc073 in zend_do_fcall_common_helper_SPEC
(execute_data=0xbfe19220)
at zend_vm_execute.h:204
#4 0x012dc705 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(execute_data=0xbfe19220)
at zend_vm_execute.h:288
#5 0x012dbc3b in execute (op_array=0x875be54) at zend_vm_execute.h:78
#6 0x012dc073 in zend_do_fcall_common_helper_SPEC
(execute_data=0xbfe19360)
at zend_vm_execute.h:204
#7 0x012dc705 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(execute_data=0xbfe19360)
at zend_vm_execute.h:288
#8 0x012dbc3b in execute (op_array=0x875ae9c) at zend_vm_execute.h:78
#9 0x0130d185 in ZEND_INCLUDE_OR_EVAL_SPEC_CV_HANDLER (
execute_data=0xbfe194d0) at zend_vm_execute.h:18130
#10 0x012dbc3b in execute (op_array=0x88f01c4) at zend_vm_execute.h:78
#11 0x012dc073 in zend_do_fcall_common_helper_SPEC
(execute_data=0xbfe19670)
at zend_vm_execute.h:204
#12 0x012dc705 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(execute_data=0xbfe19670)
at zend_vm_execute.h:288
#13 0x012dbc3b in execute (op_array=0x870ad08) at zend_vm_execute.h:78
#14 0x012ac2f3 in zend_call_function (fci=0xbfe19810,
fci_cache=0xbfe19800)
at /usr/local/src/php5-200503312030/Zend/zend_execute_API.c:851
#15 0x012ac842 in zend_lookup_class (name=0x876b32c "User",
name_length=4,
ce=0xbfe198e4)
at /usr/local/src/php5-200503312030/Zend/zend_execute_API.c:956
#16 0x0125c5fa in php_var_unserialize (rval=0xbfe19950, p=0xbfe19a90,
max=0x87e05e8 "\204�217*A", var_hash=0xbfe19a70)
at
/usr/local/src/php5-200503312030/ext/standard/var_unserializer.c:565
#17 0x0125d704 in process_nested_data (rval=0xbfe19a84, p=0xbfe19a90,
max=0x87e05e8 "\204�217*A", var_hash=0xbfe19a70,
ht=0x87e192c,
elements=0)
at
/usr/local/src/php5-200503312030/ext/standard/var_unserializer.c:232
#18 0x0125da92 in object_common2 (rval=0xbfe19a84, p=0xbfe19a90,
max=0x87e05e8 "\204�217*A", var_hash=0xbfe19a70,
elements=4)
at
/usr/local/src/php5-200503312030/ext/standard/var_unserializer.c:322
#19 0x0125c8fd in php_var_unserialize (rval=0xbfe19a84, p=0xbfe19a90,
max=0x87e05e8 "\204�217*A", var_hash=0xbfe19a70)
at
/usr/local/src/php5-200503312030/ext/standard/var_unserializer.c:623
#20 0x01150b56 in ps_srlzr_decode_php (
val=0x87dfd34 "VidaAuth|O:8:\"VidaAuth\":4:{s:14:\"", vallen=2228)
at /usr/local/src/php5-200503312030/ext/session/session.c:509
#21 0x01151015 in php_session_decode (
val=0x87dfd34 "VidaAuth|O:8:\"VidaAuth\":4:{s:14:\"", vallen=2228)
at /usr/local/src/php5-200503312030/ext/session/session.c:571
#22 0x011515a8 in php_session_initialize ()
#32514 [Fbk->Opn]: session_start() crashes when session exists
ID: 32514
User updated by: red at raven dot ch
Reported By: red at raven dot ch
-Status: Feedback
+Status: Open
Bug Type: Session related
Operating System: Fedora Core 3
PHP Version: 5CVS-2005-03-30
New Comment:
Sorry, I can't reduce this to a few lines of code. It seems this
segmentation fault does only occure in rather complex situations (and I
can't put the finger on it). I'm working with the Vida-Framework (
http://www.vidaframework.ch/ - latest cvs-version) and it seems the
problem can be found in these lines:
Previous Comments:
[2005-04-03 01:09:52] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc.
If possible, make the script source available online and provide
an URL to it here. Try to avoid embedding huge scripts into the report.
[2005-04-01 00:02:40] red at raven dot ch
tried the latest snapshot (200503312030) . still the same.
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1208932672 (LWP 3881)]
0x012dbcee in zend_do_fcall_common_helper_SPEC
(execute_data=0xbfe190b0)
at zend_vm_execute.h:120
120 if (EX(function_state).function->common.fn_flags &
ZEND_ACC_ABST
RACT) {
(gdb) bt
#0 0x012dbcee in zend_do_fcall_common_helper_SPEC
(execute_data=0xbfe190b0)
at zend_vm_execute.h:120
#1 0x012dc705 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(execute_data=0xbfe190b0)
at zend_vm_execute.h:288
#2 0x012dbc3b in execute (op_array=0x8a24f6c) at zend_vm_execute.h:78
#3 0x012dc073 in zend_do_fcall_common_helper_SPEC
(execute_data=0xbfe19220)
at zend_vm_execute.h:204
#4 0x012dc705 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(execute_data=0xbfe19220)
at zend_vm_execute.h:288
#5 0x012dbc3b in execute (op_array=0x875be54) at zend_vm_execute.h:78
#6 0x012dc073 in zend_do_fcall_common_helper_SPEC
(execute_data=0xbfe19360)
at zend_vm_execute.h:204
#7 0x012dc705 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(execute_data=0xbfe19360)
at zend_vm_execute.h:288
#8 0x012dbc3b in execute (op_array=0x875ae9c) at zend_vm_execute.h:78
#9 0x0130d185 in ZEND_INCLUDE_OR_EVAL_SPEC_CV_HANDLER (
execute_data=0xbfe194d0) at zend_vm_execute.h:18130
#10 0x012dbc3b in execute (op_array=0x88f01c4) at zend_vm_execute.h:78
#11 0x012dc073 in zend_do_fcall_common_helper_SPEC
(execute_data=0xbfe19670)
at zend_vm_execute.h:204
#12 0x012dc705 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(execute_data=0xbfe19670)
at zend_vm_execute.h:288
#13 0x012dbc3b in execute (op_array=0x870ad08) at zend_vm_execute.h:78
#14 0x012ac2f3 in zend_call_function (fci=0xbfe19810,
fci_cache=0xbfe19800)
at /usr/local/src/php5-200503312030/Zend/zend_execute_API.c:851
#15 0x012ac842 in zend_lookup_class (name=0x876b32c "User",
name_length=4,
ce=0xbfe198e4)
at /usr/local/src/php5-200503312030/Zend/zend_execute_API.c:956
#16 0x0125c5fa in php_var_unserialize (rval=0xbfe19950, p=0xbfe19a90,
max=0x87e05e8 "\204�217*A", var_hash=0xbfe19a70)
at
/usr/local/src/php5-200503312030/ext/standard/var_unserializer.c:565
#17 0x0125d704 in process_nested_data (rval=0xbfe19a84, p=0xbfe19a90,
max=0x87e05e8 "\204�217*A", var_hash=0xbfe19a70,
ht=0x87e192c,
elements=0)
at
/usr/local/src/php5-200503312030/ext/standard/var_unserializer.c:232
#18 0x0125da92 in object_common2 (rval=0xbfe19a84, p=0xbfe19a90,
max=0x87e05e8 "\204�217*A", var_hash=0xbfe19a70,
elements=4)
at
/usr/local/src/php5-200503312030/ext/standard/var_unserializer.c:322
#19 0x0125c8fd in php_var_unserialize (rval=0xbfe19a84, p=0xbfe19a90,
max=0x87e05e8 "\204�217*A", var_hash=0xbfe19a70)
at
/usr/local/src/php5-200503312030/ext/standard/var_unserializer.c:623
#20 0x01150b56 in ps_srlzr_decode_php (
val=0x87dfd34 "VidaAuth|O:8:\"VidaAuth\":4:{s:14:\"", vallen=2228)
at /usr/local/src/php5-200503312030/ext/session/session.c:509
#21 0x01151015 in php_session_decode (
val=0x87dfd34 "VidaAuth|O:8:\"VidaAuth\":4:{s:14:\"", vallen=2228)
at /usr/local/src/php5-200503312030/ext/session/session.c:571
#22 0x011515a8 in php_session_initialize ()
at /usr/local/src/php5-200503312030/ext/session/session.c:752
#23 0x01153265 in php_session_start ()
at /usr/local/src/php5-200503312030/ext/session/session.c:1203
#24 0x01154c98 in zif_session_start (ht=0, return_value=0x8762bc4,
this_ptr=0x0, return_value_used=0)
at /usr/local/src/php5-200503312030/ext/session/session.c:1665
#
#32514 [Fbk->Opn]: session_start() crashes when session exists
ID: 32514
User updated by: red at raven dot ch
Reported By: red at raven dot ch
-Status: Feedback
+Status: Open
Bug Type: Session related
Operating System: Fedora Core 3
PHP Version: 5.0.3
New Comment:
Unfortunatly I am not able to write a short script which reproduces
this segfault.
(gdb) bt
#0 0x012b4aaf in zend_do_fcall_common_helper (execute_data=0xbfeed720,
opline=0x891d6dc, op_array=0x891837c)
at /usr/local/src/php-5.0.3/Zend/zend_execute.c:2656
#1 0x012b5583 in zend_do_fcall_by_name_handler
(execute_data=0xbfeed720,
opline=0x891d6dc, op_array=0x891837c)
at /usr/local/src/php-5.0.3/Zend/zend_execute.c:2825
#2 0x012af3ed in execute (op_array=0x891837c)
at /usr/local/src/php-5.0.3/Zend/zend_execute.c:1400
#3 0x012b4ece in zend_do_fcall_common_helper (execute_data=0xbfeed8c0,
opline=0x890cd7c, op_array=0x8949dc4)
at /usr/local/src/php-5.0.3/Zend/zend_execute.c:2740
#4 0x012b5583 in zend_do_fcall_by_name_handler
(execute_data=0xbfeed8c0,
opline=0x890cd7c, op_array=0x8949dc4)
at /usr/local/src/php-5.0.3/Zend/zend_execute.c:2825
#5 0x012af3ed in execute (op_array=0x8949dc4)
at /usr/local/src/php-5.0.3/Zend/zend_execute.c:1400
#6 0x012b4ece in zend_do_fcall_common_helper (execute_data=0xbfeeda00,
opline=0x85ce3f4, op_array=0x89498fc)
at /usr/local/src/php-5.0.3/Zend/zend_execute.c:2740
#7 0x012b5583 in zend_do_fcall_by_name_handler
(execute_data=0xbfeeda00,
opline=0x85ce3f4, op_array=0x89498fc)
at /usr/local/src/php-5.0.3/Zend/zend_execute.c:2825
#8 0x012af3ed in execute (op_array=0x89498fc)
at /usr/local/src/php-5.0.3/Zend/zend_execute.c:1400
#9 0x012b7c40 in zend_include_or_eval_handler
(execute_data=0xbfeedba0,
opline=0x8630e30, op_array=0x85d3dac)
at /usr/local/src/php-5.0.3/Zend/zend_execute.c:3565
#10 0x012af3ed in execute (op_array=0x85d3dac)
at /usr/local/src/php-5.0.3/Zend/zend_execute.c:1400
#11 0x012b4ece in zend_do_fcall_common_helper (execute_data=0xbfeedda0,
opline=0x871aec8, op_array=0x871b1d0)
at /usr/local/src/php-5.0.3/Zend/zend_execute.c:2740
#12 0x012b5583 in zend_do_fcall_by_name_handler
(execute_data=0xbfeedda0,
opline=0x871aec8, op_array=0x871b1d0)
at /usr/local/src/php-5.0.3/Zend/zend_execute.c:2825
#13 0x012af3ed in execute (op_array=0x871b1d0)
at /usr/local/src/php-5.0.3/Zend/zend_execute.c:1400
#14 0x0127b952 in zend_call_function (fci=0xbfeedf00, fci_cache=0x0)
at /usr/local/src/php-5.0.3/Zend/zend_execute_API.c:836
#15 0x0127a9a4 in call_user_function_ex (function_table=0x850de20,
object_pp=0x0, function_name=0xbfeedfc0, retval_ptr_ptr=0xbfeedfa8,
param_count=1, params=0xbfeedfdc, no_separation=0,
symbol_table=0x0)
at /usr/local/src/php-5.0.3/Zend/zend_execute_API.c:551
#16 0x0127be99 in zend_lookup_class (name=0x85e0224 "User",
name_length=4,
ce=0xbfeee028) at
/usr/local/src/php-5.0.3/Zend/zend_execute_API.c:928
#17 0x01225613 in php_var_unserialize (rval=0xbfeee08c, p=0xbfeee1bc,
max=0x863d0e0 "\204�217*I", var_hash=0xbfeee1a4)
at /usr/local/src/php-5.0.3/ext/standard/var_unserializer.c:488
#18 0x0122669f in process_nested_data (rval=0xbfeee1b0, p=0xbfeee1bc,
max=0x863d0e0 "\204�217*I", var_hash=0xbfeee1a4,
ht=0x863d6c4,
elements=0) at
/usr/local/src/php-5.0.3/ext/standard/var_unserializer.c:196
#19 0x01226964 in object_common2 (rval=0xbfeee1b0, p=0xbfeee1bc,
max=0x863d0e0 "\204�217*I", var_hash=0xbfeee1a4,
elements=4)
at /usr/local/src/php-5.0.3/ext/standard/var_unserializer.c:259
#20 0x01225910 in php_var_unserialize (rval=0xbfeee1b0, p=0xbfeee1bc,
max=0x863d0e0 "\204�217*I", var_hash=0xbfeee1a4)
at /usr/local/src/php-5.0.3/ext/standard/var_unserializer.c:540
#21 0x01116ad1 in ps_srlzr_decode_php (
val=0x863c82c "VidaAuth|O:8:\"VidaAuth\":4:{s:14:\"", vallen=2228)
at /usr/local/src/php-5.0.3/ext/session/session.c:509
#22 0x01116f76 in php_session_decode (
val=0x863c82c "VidaAuth|O:8:\"VidaAuth\":4:{s:14:\"", vallen=2228)
at /usr/local/src/php-5.0.3/ext/session/session.c:567
#23 0x011175b2 in php_session_initialize ()
at /usr/local/src/php-5.0.3/ext/session/session.c:748
#24 0x011195b4 in php_session_start ()
at /usr/local/src/php-5.0.3/ext/session/session.c:1195
#25 0x0111b14f in zif_session_start (ht=0, return_value=0x87122dc,
this_ptr=0x0, return_value_used=0)
#26 0x012b4d35 in zend_do_fcall_common_helper (execute_data=0xbfeee680,
opline=0x8714b88, op_array=0x85dccfc)
at /usr/local/src/php-5.0.3/Zend/zend_execute.c:2711
#27 0x012b5691 in zend_do_fcall_handler (execute_data=0xbfeee680,
opline=0x8714b88, op_array=0x85dccfc)
at /usr/local/src/php-5.0.3/Zend/zend_execute.c:2843
#28 0x012af3ed in execute (op_array=0x85dccfc)
at /usr/local/src/php-5.0.3/Zend/zend_execute.c
#32514 [NEW]: session_start() crashes when session exists
From: red at raven dot ch
Operating system: Fedora Core 3
PHP version: 5.0.3
PHP Bug Type: Session related
Bug description: session_start() crashes when session exists
Description:
When I create a session and write some objects to it the server crashes
with a segmentation fault on the next request.
When searching in the bug database I found
http://bugs.php.net/bug.php?id=31734 which seems to have similar behaviour
on my machine.
Reproduce code:
---
This is the content of the session file: The code is a bit too complex to
post here.
VidaAuth|O:8:"VidaAuth":4:{s:14:"VidaAuthuser";N;s:18:"VidaAuthloggedIn";N;s:25:
"VidaAuthuserEntityClass";s:4:"User";s:25:"VidaAuthuserObjectCache";O:4:"User":5
:{s:13:"*entityCore";N;s:14:"*tableScheme";O:13:"DBTableScheme":9:{s:20:"DBTable
Schemetable";s:5:"users";s:21:"DBTableSchemefields";a:3:{i:0;s:8:"username";i:1;
s:8:"password";i:2;s:5:"email";}s:20:"DBTableSchemetypes";a:3:{s:8:"username";s:
6:"string";s:8:"password";s:6:"string";s:5:"email";s:6:"string";}s:18:"DBTableSc
hemekey";s:8:"username";s:19:"DBTableSchemenull";a:3:{s:8:"username";b:0;s:8:"pa
ssword";b:0;s:5:"email";b:0;}s:29:"DBTableSchemeeffectiveTypes";a:3:{s:8:"userna
me";s:7:"varchar";s:8:"password";s:7:"varchar";s:5:"email";s:7:"varchar";}s:21:"
DBTableSchemelength";a:3:{s:8:"username";s:3:"255";s:8:"password";s:3:"255";s:5:
"email";s:3:"255";}s:26:"DBTableSchemeforeignKeys";a:0:{}s:22:"DBTableSchemesetI
nfo";a:0:{}}s:12:"*newValues";a:0:{}s:13:"*nullValues";a:0:{}s:8:"*state";i:0;}}
FormManager|O:11:"FormManager":2:{s:7:"counter";i:2;s:5:"stock";a:2:{s:13:"VidaL
oginForm";a:1:{i:1;O:15:"FormDataStorage":7:{s:6:"values";a:0:{}s:25:"FormDataSt
orageinvalids";a:0:{}s:8:"messages";a:0:{}s:29:"FormDataStoragesystemValues";a:2
:{s:15:"controllerClass";s:11:"LoginAction";s:3:"url";O:7:"ThisURL":5:{s:11:"URL
scheme";s:0:"";s:9:"URLhost";s:0:"";s:9:"URLpath";s:6:"/vita/";s:9:"URLfile";s:1
0:"index.php5";s:16:"URLqueryValues";a:0:{}}}s:23:"FormDataStorageparent";N;s:27
:"FormDataStorageidentifier";i:1;s:24:"FormDataStoragereferer";O:7:"Referer":5:{
s:11:"URLscheme";s:0:"";s:9:"URLhost";s:0:"";s:9:"URLpath";s:6:"/vita/";s:9:"URL
file";s:10:"index.php5";s:16:"URLqueryValues";a:0:{s:13:"XmlModuleForm";a:1:
{i:2;O:15:"FormDataStorage":7:{s:6:"values";a:0:{}s:25:"FormDataStorageinvalids"
;a:0:{}s:8:"messages";a:0:{}s:29:"FormDataStoragesystemValues";a:2:{s:15:"contro
llerClass";s:15:"XmlModuleAction";s:3:"url";r:45;}s:23:"FormDataStorageparent";N
;s:27:"FormDataStorageidentifier";i:2;s:24:"FormDataStoragereferer";O:7:"Referer
":5:{s:11:"URLscheme";s:0:"";s:9:"URLhost";s:0:"";s:9:"URLpath";s:6:"/vita/";s:9
Expected result:
To load the session and create the Objects.
Actual result:
--
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1208899904 (LWP 28088)]
0x012d7aaf in zend_do_fcall_common_helper (execute_data=0xbfe83c20,
opline=0x99f46dc, op_array=0x99ef37c)
at /usr/local/src/php-5.0.3/Zend/zend_execute.c:2656
2656if (EX(function_state).function->common.fn_flags &
ZEND_ACC_ABSTRACT) {
--
Edit bug report at http://bugs.php.net/?id=32514&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32514&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=32514&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=32514&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=32514&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=32514&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=32514&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=32514&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=32514&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=32514&r=support
Expected behavior: http://bugs.php.net/fix.php?id=32514&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=32514&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=32514&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=32514&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32514&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=32514&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=32514&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=32514&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=32514&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=32514&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=32514&r=mysqlcfg
#24282 [Com]: Strange Open Base Dir Restriction Errors
ID: 24282 Comment by: red at raven dot ch Reported By: matzrek at shw-networks dot de Status: Open Bug Type: Apache related Operating System: Suse Linux 8.2 / Apache 1.3.27 PHP Version: 4.3.2 New Comment: seems to be the same or similar thing: bug #25198 I realised the same issue as dprado at floripa dot com dot br mentioned... Previous Comments: [2003-08-25 23:57:05] celticlegend at dublin dot com Am working with my hosting co. on what appears to be this same problem. php v.4.3.1, on Apache. The problem is very intermittent, and is triggered by the main site's index.php, the phpBB forum's .php files (various), and a blogger app (php). The hosting techs have not been able to trigger it yet, and say that we are their only customer reporting this problem. Strangely enough, all the errors indicate the offending page is trying to reach another users' directory (/home/bone and others). Sample errors follow: # Example #1 of 3: Warning: Unknown(): open_basedir restriction in effect. File(/home/clegend/public_html/index.php) is not within the allowed path(s): (/home/bone) in Unknown on line 0 Warning: Unknown(/home/clegend/public_html/index.php): failed to create stream: Operation not permitted in Unknown on line 0 Warning: Unknown(): Failed opening '/home/clegend/public_html/index.php' for inclusion (include_path='.:/usr/lib/php:/usr/local/lib/php:/tmp') in Unknown on line 0 (note: I have scoured the code and there is no reference to /home/bone anywhere.) # Example #2 of 3: Warning: Unknown(): open_basedir restriction in effect. File(/home/clegend/public_html/forum/viewtopic.php) is not within the allowed path(s): (/home/bone) in Unknown on line 0 Warning: Unknown(/home/clegend/public_html/forum/viewtopic.php): failed to create stream: Operation not permitted in Unknown on line 0 Warning: Unknown(): Failed opening '/home/clegend/public_html/forum/viewtopic.php' for inclusion (include_path='') in Unknown on line 0 # Example #3 of 3: Warning: Unknown(): open_basedir restriction in effect. File(/home/clegend/public_html/forum/posting.php) is not within the allowed path(s): (/home/bone) in Unknown on line 0 Warning: Unknown(/home/clegend/public_html/forum/posting.php): failed to create stream: Operation not permitted in Unknown on line 0 Warning: Unknown(): Failed opening '/home/clegend/public_html/forum/posting.php' for inclusion (include_path='.:/usr/lib/php:/usr/local/lib/php') in Unknown on line 0 # Apparently my host tech just replied to my ticket on this, just as I was about to hit "Submit": they found this ticket and are trying to apply what dprado suggested. Thanks in advance. [2003-08-21 12:38:31] matzrek at shw-networks dot de Will send my config this evening. Daniel [2003-08-21 11:40:14] fs at nessus dot at ok, i just sent you my configuration files. the php file is nonsense because it happens everywhere, phpinfo() for example. i hope we can fix it as soon as possible. greetings, Florian Schicker [2003-08-15 11:07:33] [EMAIL PROTECTED] I say again: We need to get the httpd.conf, etc. with which you HAVE been experiencing this problem. Read my previous comment. [2003-08-15 10:48:00] matzrek at shw-networks dot de Hi sniper, This error cannot be reproduces exactly at the moment. It happens sometimes. The only thin i realized : it does not appear directly after restarting apache. I have to wait several hours until it happens the first time. Daniel 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/24282 -- Edit this bug report at http://bugs.php.net/?id=24282&edit=1
#25198 [Opn]: error_reporting() seems to affect whole server
ID: 25198 User updated by: red at raven dot ch Reported By: red at raven dot ch Status: Open Bug Type: PHP options/info functions Operating System: linux (redhat 9) apache 2.0.47 PHP Version: 4.3.2 New Comment: just installed php-4.3.3; still the same problem... Previous Comments: [2003-08-22 00:21:22] red at raven dot ch hm, this is a server with about 40 domains running on it. so I don't really like the idea of running a cvs-snapshot (or release-candidate). well, I will try to recreate this one on my development-server. apache2 configuration: ./configure --enable-so --enable-rewrite --enable-proxy [2003-08-21 18:52:43] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip Also, what was the configure line you used for Apache2? [2003-08-21 12:40:48] red at raven dot ch Description: The global configuration shows the following: error_reporting 20392039 when 2 scripts in 2 differents virtualhosts run at the same time and the first one sets error_reporting(E_ALL) and the second one starts before the first ended (and doesn't set error_reporting) it shows the notices as well. ./configure --with-apxs2=/usr/local/apache2/bin/apxs --enable-xml --with-gd --with-png-dir=/usr --with-jpeg-dir=/usr --enable-track-vars --enable-force-cgi-redirect --with-gettext --with-mysql=/usr --with-zlib-dir=/usr --enable-sysvshm --enable-sysvsem --with-xslt --with-ttf --with-freetype-dir=/usr/local --enable-gd-native-ttf --disable-cgi --with-dom --with-dom-xslt --with-iconv -- Edit this bug report at http://bugs.php.net/?id=25198&edit=1
#25198 [Fbk->Opn]: error_reporting() seems to affect whole server
ID: 25198 User updated by: red at raven dot ch Reported By: red at raven dot ch -Status: Feedback +Status: Open Bug Type: PHP options/info functions Operating System: linux (redhat 9) apache 2.0.47 PHP Version: 4.3.2 New Comment: hm, this is a server with about 40 domains running on it. so I don't really like the idea of running a cvs-snapshot (or release-candidate). well, I will try to recreate this one on my development-server. apache2 configuration: ./configure --enable-so --enable-rewrite --enable-proxy Previous Comments: [2003-08-21 18:52:43] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip Also, what was the configure line you used for Apache2? [2003-08-21 12:40:48] red at raven dot ch Description: The global configuration shows the following: error_reporting 20392039 when 2 scripts in 2 differents virtualhosts run at the same time and the first one sets error_reporting(E_ALL) and the second one starts before the first ended (and doesn't set error_reporting) it shows the notices as well. ./configure --with-apxs2=/usr/local/apache2/bin/apxs --enable-xml --with-gd --with-png-dir=/usr --with-jpeg-dir=/usr --enable-track-vars --enable-force-cgi-redirect --with-gettext --with-mysql=/usr --with-zlib-dir=/usr --enable-sysvshm --enable-sysvsem --with-xslt --with-ttf --with-freetype-dir=/usr/local --enable-gd-native-ttf --disable-cgi --with-dom --with-dom-xslt --with-iconv -- Edit this bug report at http://bugs.php.net/?id=25198&edit=1
#25198 [NEW]: error_reporting() seems to affect whole server
From: red at raven dot ch Operating system: linux (redhat 9) apache 2.0.47 PHP version: 4.3.2 PHP Bug Type: PHP options/info functions Bug description: error_reporting() seems to affect whole server Description: The global configuration shows the following: error_reporting 20392039 when 2 scripts in 2 differents virtualhosts run at the same time and the first one sets error_reporting(E_ALL) and the second one starts before the first ended (and doesn't set error_reporting) it shows the notices as well. ./configure --with-apxs2=/usr/local/apache2/bin/apxs --enable-xml --with-gd --with-png-dir=/usr --with-jpeg-dir=/usr --enable-track-vars --enable-force-cgi-redirect --with-gettext --with-mysql=/usr --with-zlib-dir=/usr --enable-sysvshm --enable-sysvsem --with-xslt --with-ttf --with-freetype-dir=/usr/local --enable-gd-native-ttf --disable-cgi --with-dom --with-dom-xslt --with-iconv -- Edit bug report at http://bugs.php.net/?id=25198&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=25198&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=25198&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=25198&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=25198&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=25198&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=25198&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=25198&r=support Expected behavior: http://bugs.php.net/fix.php?id=25198&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=25198&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=25198&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=25198&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=25198&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=25198&r=dst IIS Stability: http://bugs.php.net/fix.php?id=25198&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=25198&r=gnused
#19779 [Bgs->Opn]: pspell causes mod_cgi not work
ID: 19779
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Bogus
+Status: Open
-Bug Type: Reproducible crash
+Bug Type: *Web Server problem
Operating System: debian potato i386
-PHP Version: 4.2.1
+PHP Version: 4.2.3
New Comment:
i want to use pspell functions in php. so i installed pspell & aspell,
compiled php with "./configure --with-apxs=/usr/bin/apxs
--with-pspell". now the pspell functions work, but my mod_cgi not
longer (i use php as apache module). if i run the apache with pspell
compiled php, a call to an url /cgi-bin/test.pl gives me an internal
error in the browser. the apache error log says:
[Sun Oct 6 16:19:18 2002] [error] [client 80.135.xxx.xxx] Premature
end of script headers: /var/www/cgi-bin/test.pl
where test.pl just contains:
#!/usr/bin/perl
print "Content-type: text/html\n\n";
print "hello\n";
if i compile without pspell ("./configure --with-apxs=/usr/bin/apxs")
the call returns "hello" as expected.
i have reproduced this bug with php 4.1.2 & 4.2.3. the apache version
is 1.3.9
Previous Comments:
[2002-10-06 10:22:04] [EMAIL PROTECTED]
Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php
If you can provide more information, feel free to add it
to this bug and change the status back to "Open".
Thank you for your interest in PHP.
[2002-10-06 10:09:56] [EMAIL PROTECTED]
hi,
i use php as an apache module. if i compile --with-pspell my perl
cgi-bins are not working (i got 500 - internal errors, the log says
"premature end of script headers") this error occurs also in php
4.2.3.
my configure options are ./configure --with-apxs=/usr/bin/apxs
--with-pspell.
without pspell cgis working fine.
Greetings, Thomas.
--
Edit this bug report at http://bugs.php.net/?id=19779&edit=1
#19779 [NEW]: pspell causes mod_cgi not work
From: [EMAIL PROTECTED] Operating system: debian potato i386 PHP version: 4.2.1 PHP Bug Type: Reproducible crash Bug description: pspell causes mod_cgi not work hi, i use php as an apache module. if i compile --with-pspell my perl cgi-bins are not working (i got 500 - internal errors, the log says "premature end of script headers") this error occurs also in php 4.2.3. my configure options are ./configure --with-apxs=/usr/bin/apxs --with-pspell. without pspell cgis working fine. Greetings, Thomas. -- Edit bug report at http://bugs.php.net/?id=19779&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=19779&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=19779&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=19779&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=19779&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=19779&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=19779&r=support Expected behavior: http://bugs.php.net/fix.php?id=19779&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=19779&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=19779&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=19779&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=19779&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=19779&r=dst IIS Stability: http://bugs.php.net/fix.php?id=19779&r=isapi
Bug #17287: safe mode is not full safe.
From: [EMAIL PROTECTED]
Operating system: Linux + apache 1.3
PHP version: 4.2.0
PHP Bug Type: *General Issues
Bug description: safe mode is not full safe.
On set_time_limit documentation web page stands:
set_time_limit() has no effect when PHP is running in safe mode. There is
no workaround other than turning off safe mode or changing the time limit
in the configuration file.
which is false, becouse You may do: ini_set("max_execution_time", "any
value") and it success even in safe_mode.
I consider it as a bug.
I guess this will work for memory_limit also.
Raven
--
Edit bug report at http://bugs.php.net/?id=17287&edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=17287&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=17287&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=17287&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=17287&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=17287&r=support
Expected behavior: http://bugs.php.net/fix.php?id=17287&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=17287&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=17287&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=17287&r=globals
