Hello,
I am seeing Apache segmentation faults with some processes which turn
out to be php related. This is a newly upgraded Apache from Apache
2.0.54 to Apache 2.0.55. The scripts that are failing with the new
Apache work with no problems with the old Apache.
Traceback from Apache is below.
Let me know if I should provide any more info. php version is 4.3.10,
and linux distro is fedora core 3 - php and apache are both compiled
from source, not installed from rpm.
Thanks,
Kristina
#0 (ht=0xb7d247a0, h=4, pData=0xbfffec70,
nDataSize=12, pDest=0x0, flag=1) at
/
nIndex = 4
p = (Bucket *) 0x7068702e
#1 0xb7c6bf23 in zend_list_insert (ptr=0x9b57ba4, type=162888612)
at /
index = 4
le = {ptr = 0xda1a0c4, type = 2, refcount = 1}
#2 0xb7c6c05e in zend_register_resource (rsrc_result=0x0,
rsrc_pointer=0xda1a0c4,
rsrc_type=2) at /
rsrc_id = 162888612
#3 0xb7c452f8 in _php_stream_alloc (ops=0x9b57ba4, abstract=0x9b57ba4,
persistent_id=0x0, mode=0xb762f895 "rb")
at /
le = {ptr = 0x24, type = 1126289980, refcount = 797960056}
ret = (php_stream *) 0xda1a0c4
#4 0xb7c46b06 in _php_stream_fopen_from_fd (fd=16, mode=0xb762f895 "rb",
persistent_id=0x0) at /
self = (php_stdio_stream_data *) 0x9c0871c
stream = (php_stream *) 0x9c08730
sb = {st_dev = 16, __pad1 = 0, st_ino = 3230021650, st_mode = 33188,
st_nlink = 1, st_uid = 42807, st_gid = 100, st_rdev = 0, __pad2 = 0,
st_size = 1179, st_blksize = 32768, st_blocks = 8, st_atim = {tv_sec
= 1124473602,
tv_nsec = 315743024}, st_mtim = {tv_sec = 1126289980, tv_nsec = 797960056},
st_ctim = {tv_sec = 1126289980, tv_nsec = 799959752}, __unused4 = 0,
__unused5 = 0}
#5 0xb7c46c9d in _php_stream_fopen (
filename=0xda143d8 "/",
mode=0xb762f895 "rb",
opened_path=0xbffff1a8, options=165)
at /
realpath = 0xd993454 "/mnt/nfs/STJSEPHGC/eventsdb.php"
st = {st_dev = 16, __pad1 = 0, st_ino = 3230021650, st_mode = 33188,
st_nlink = 1, st_uid = 42807, st_gid = 100, st_rdev = 0, __pad2 = 0,
st_size = 1179, st_blksize = 32768, st_blocks = 8, st_atim = {tv_sec
= 1124473602,
tv_nsec = 315743024}, st_mtim = {tv_sec = 1126289980, tv_nsec = 797960056},
st_ctim = {tv_sec = 1126289980, tv_nsec = 799959752}, __unused4 = 0,
__unused5 = 0}
open_flags = 0
fd = 16
ret = (php_stream *) 0x0
persistent = 16
persistent_id = 0x0
#6 0xb7c47fb5 in php_plain_files_stream_opener (wrapper=0xb7cf3dc4,
path=0xda143d8 "/", mode=0xb762f895 "rb",
options=165, opened_path=0xbffff1a8, context=0x0)
at /
No locals.
#7 0xb7c485dc in _php_stream_open_wrapper_ex (
path=0xda143d8 "/", mode=0xb762f895 "rb",
options=173, opened_path=0xa5, context=0x0)
at /
stream = (php_stream *) 0x0
wrapper = (php_stream_wrapper *) 0xb7cf3dc4
path_to_open = 0xda143d8 "/"
#8 0xb75d84ce in ? ()
from /home/sys/Zend/lib//php-4.3.x/Z
No symbol table info available.
#9 0x0da143d8 in ? ()
No symbol table info available.
#10 0xb762f895 in ? ()
from /home/sys/Zend/lib//php-4.3.x/Z
No symbol table info available.
<returnto continue, or q <returnto quit
#11 0x000000ad in ? ()
No symbol table info available.
#12 0xbffff1a8 in ? ()
No symbol table info available.
#13 0x00000000 in ? ()
No symbol table info available.

I have had various problems with upgrading one or the other, until I took it
as a rule to recompile both upon an upgrade. the machine I do things
completely manually on [which has it's drawbacks], I generally also upgrade
to the current version of PHP together with any Apache update, and
vice-versa. The current 4.x version is 4.4.1 [although on a FreeBSD install I
had some issues and downgraded to 4.4.0, but this behaviour hasn't been
confirmed outside of FreeBSD until now] - perhaps try recompiling PHP to the
current 4.x version (or if you feel up to it, upgrade to the 5.x versions?),
and see if it helps? Resolved a lot of my problems in the past

Thursday 17 November 2005 22:31, kristina clair wrote:
2.0.54 to Apache 2.0.55. The scripts that are failing with the new
Apache work with no problems with the old Apache.

I actually did that before emailing about php 4.3.10. With php 4.4.1,
the traceback is different:

Reading symbols from /
Loaded symbols for /
Error while reading shared library symbols:
No such file or directory.
Reading symbols from /
Loaded symbols for /
#0 0xb7ca0c15 in php_handler (r=0xda05f90)
at /
if (parent_req && strcmp(parent_req->handler,
PHP_MAGIC_TYPE) && strcmp(parent_req->handler, PHP_SURCE_MAGIC_TYPE)
&& strcmp(parent_req->handler, PHP_SCRIPT)) {
warning: not using untrusted file ".gdbinit"

(gdb) bt full
#0 0xb7ca0c15 in php_handler (r=0xda05f90)
at /
orig_bailout = {{__jmpbuf = {0, 0, 0, 0, 0, 0}, __mask_was_saved = 0,
__saved_mask = {__val = {0 <repeats 32 times>}}}}
ctx = (php_struct *) 0xd9e9a80
conf = Variable "conf" is not available.
(gdb)

11/17/05, Max Belushkin <m.belushkin (AT) fz-juelich (DOT) dewrote:
I have had various problems with upgrading one or the other, until I took it
as a rule to recompile both upon an upgrade. the machine I do things
completely manually on [which has it's drawbacks], I generally also upgrade
to the current version of PHP together with any Apache update, and
vice-versa. The current 4.x version is 4.4.1 [although on a FreeBSD install I
had some issues and downgraded to 4.4.0, but this behaviour hasn't been
confirmed outside of FreeBSD until now] - perhaps try recompiling PHP to the
current 4.x version (or if you feel up to it, upgrade to the 5.x versions?),
and see if it helps? Resolved a lot of my problems in the past

Thursday 17 November 2005 22:31, kristina clair wrote:
2.0.54 to Apache 2.0.55. The scripts that are failing with the new
Apache work with no problems with the old Apache.

has anyone here used wget or similar command to redirect/reflect a
live stream data from one server to another server ?
I wanted to use each server's upload bandwidth to transfer a live
stream to a new server

that way, my hope is that I can balance the bandwidth load a bit
between servers for users in different areas.
Would it just be a question of duplicating the headers of the
incoming file and redirecting it to another server?

I am 'fishing' a bit so any help from those who use php with live
streaming is appreciated.

Server side:
live stream is encoded and sent to
streaming server 1 in Los Angeles which sends the data to
streaming server 2 in Chicago which sends the data to
streaming server 3 in Mexico City

Client Side:
The below is pretty simple to do :)
When the user tries to access the live broadcast stream, a php script
determines the nearest non-overloaded server.
In this case, the user is directed to the live stream on server two
in Chicago

many thanks

g

11/17/05, Marco Kaiser <marco.kaiser (AT) gmail (DOT) comwrote:
Hi Kristina,

try to disable / remove the Zend Extension (ZendExtensionManager etc.
[ZEND] and all below in your php.ini).

try if php segfault again without the Zend Products loaded.

Hello,

After removing Zend, I get the same error, minus the Zend errors:

#0 0xb7e20c15 in php_handler (r=0xda0cf10)
at /
if (parent_req && strcmp(parent_req->handler,
PHP_MAGIC_TYPE) && strcmp(parent_req->handler, PHP_SURCE_MAGIC_TYPE)
&& strcmp(parent_req->handler, PHP_SCRIPT)) {
warning: not using untrusted file ".gdbinit"

(gdb) bt full
#0 0xb7e20c15 in php_handler (r=0xda0cf10)
at /
orig_bailout = {{__jmpbuf = {0, 0, 0, 0, 0, 0}, __mask_was_saved = 0,
__saved_mask = {__val = {0 <repeats 32 times>}}}}
ctx = (php_struct *) 0xd9f0578
conf = Variable "conf" is not available.
(gdb)

Thanks,
Kristina

Hi Kristina,
have you tried the lates cvs snap? I know there was some problems with
apache2 and mod_rewrite maybe it is solve in CVS.

Hi,

I just installed the latest available snap, and now I'm seeing a zend
error, but not a sapi error:

Reading symbols from /
Loaded symbols for /
Error while reading shared library symbols:
No such file or directory.
Reading symbols from /
Loaded symbols for /
#0 _efree (ptr=0x0)
at /
242 (p->size);

(gdb) bt full
#0 _efree (ptr=0x0)
at /
p = (zend_mem_header *) 0xfffffff4
cache_index = Variable "cache_index" is not available.
(gdb)

I think there are two things worth noting:
1. /home/sys/Zend is a separate installation of Zend does this
need to be updated as well?
2. this segfault is only happening for one script, as far as we know.
Is there anything I should look for in this script to narrow things
down?

Thanks,
Kristina

11/21/05, Marco Kaiser <marco.kaiser (AT) gmail (DOT) comwrote:
Hi Kristina,

have you tried the lates cvs snap? I know there was some problems with
apache2 and mod_rewrite maybe it is solve in CVS.

Hi Kristina,
I think there is no version available for 5.1.0-cvs. Try to remove the
Zend Extensions and give me please feedback.
I just installed the latest available snap, and now I'm seeing a zend
error, but not a sapi error:

Hi,

When I said I installed the latest available snapshot, I meant I
installed the latest available snap in the 4.4.x tree - so, the
version I installed was

Kristina

11/21/05, Marco Kaiser <marco.kaiser (AT) gmail (DOT) comwrote:
Hi Kristina,

I think there is no version available for 5.1.0-cvs. Try to remove the
Zend Extensions and give me please feedback.

I just installed the latest available snap, and now I'm seeing a zend
error, but not a sapi error:

Hi Kristina,

When I said I installed the latest available snapshot, I meant I
installed the latest available snap in the 4.4.x tree - so, the
version I installed was

tha Zend API changed so your installed zend products doenst work with
cvs version of php. Disable alle Zend Stuff in you php.ini and tell me
if this error still happen.

11/21/05, Marco Kaiser <marco.kaiser (AT) gmail (DOT) comwrote:
Hi Kristina,

When I said I installed the latest available snapshot, I meant I
installed the latest available snap in the 4.4.x tree - so, the
version I installed was

tha Zend API changed so your installed zend products doenst work with
cvs version of php. Disable alle Zend Stuff in you php.ini and tell me
if this error still happen.

After disabling Zend in php.ini, I get:

#0 0xb7df5ee9 in yy_push_state (new_state=1)
at
5831 yy_start_stack[yy_start_stack_ptr++] = YY_START;
(gdb) bt full
#0 0xb7df5ee9 in yy_push_state (new_state=1)
at
new_size = Variable "new_size" is not available.
(gdb)

php is, of course, still installing its own zend extension. But all
of the lines pertaining to Zend were indeed removed from php.ini.

Thanks,
Kristina

Hi again,

I tried compiling and installing php 4.4.1 with Apache 2.0.54, out of
curiosity (because php 4.3.10 and Apache 2.0.54 didn't give me any
problems).

With this combination, I still get a segmentation fault with at least
one php script. The gdb backtrace is:
#0 0xb7e207c1 in php_handler (r=0xda16ca8)
at /
538 if (parent_req && strcmp(parent_req->handler,
PHP_MAGIC_TYPE) && strcmp(parent_req->handler, PHP_SURCE_MAGIC_TYPE)
&& strcmp(parent_req->handler, PHP_SCRIPT)) {
(gdb) bt full
#0 0xb7e207c1 in php_handler (r=0xda16ca8)
at /
orig_bailout = {{__jmpbuf = {0, 0, 0, 0, 0, 0},
__mask_was_saved = 0, __saved_mask = {__val = {
0 <repeats 32 times>}}}}
ctx = (php_struct *) 0xda08818
conf = Variable "conf" is not available.

I think it is worth reiterating that this is only happening with one
script, to our knowledge. The actual file being served is a .shtml
file which includes a php script. I looked at the php script, and it
looks like a pretty straightforward database access script, using
mysql. Is there anything I should look for in that script?

Thanks,
Kristina

11/17/05, kristina clair <kclair (AT) gmail (DOT) comwrote:
I actually did that before emailing about php 4.3.10. With php 4.4.1,
the traceback is different:

Reading symbols from /
Loaded symbols for /
Error while reading shared library symbols:
.//home/sys/Zend/etc/pfpro.so: No such file or directory.
Reading symbols from /
Loaded symbols for /
#0 0xb7ca0c15 in php_handler (r=0xda05f90)
at /
if (parent_req && strcmp(parent_req->handler,
PHP_MAGIC_TYPE) && strcmp(parent_req->handler, PHP_SURCE_MAGIC_TYPE)
&& strcmp(parent_req->handler, PHP_SCRIPT)) {
warning: not using untrusted file ".gdbinit"

(gdb) bt full
#0 0xb7ca0c15 in php_handler (r=0xda05f90)
at /
orig_bailout = {{__jmpbuf = {0, 0, 0, 0, 0, 0}, __mask_was_saved = 0,
__saved_mask = {__val = {0 <repeats 32 times>}}}}
ctx = (php_struct *) 0xd9e9a80
conf = Variable "conf" is not available.
(gdb)

11/17/05, Max Belushkin <m.belushkin (AT) fz-juelich (DOT) dewrote:
I have had various problems with upgrading one or the other, until I took it
as a rule to recompile both upon an upgrade. the machine I do things
completely manually on [which has it's drawbacks], I generally also upgrade
to the current version of PHP together with any Apache update, and
vice-versa. The current 4.x version is 4.4.1 [although on a FreeBSD install I
had some issues and downgraded to 4.4.0, but this behaviour hasn't been
confirmed outside of FreeBSD until now] - perhaps try recompiling PHP to the
current 4.x version (or if you feel up to it, upgrade to the 5.x versions?),
and see if it helps? Resolved a lot of my problems in the past

Thursday 17 November 2005 22:31, kristina clair wrote:
2.0.54 to Apache 2.0.55. The scripts that are failing with the new
Apache work with no problems with the old Apache.