[PHP-DEV] SMP machines and shared memory

2002-03-18 Thread Warwick Poole

I dont know if this is the correct forum to ask this question, but I
have spent a good day trying to find the answer to this with no real
success, so I thought I would try the source...the PHP developers.

I am building a cluster of 3 webservers, which are going to serve a
group of PHP (with some Perl scripts as well) websites. Its a high load
environment so I have gone with SMP machines (dual Processor i686, 1GB
RAM, running a tuned RedHat 7.2 with kernel 2.4.18 with tweaks). 

I am trying to tweak the OS, Apache and PHP as far as I possibly can. I
want to use Shared Memory for the session handlers in PHP, so I have
compiled with --with-mm and set session.save_handler=mm in php.ini.

I have been told that PHP has serious concurrency bugs when using SMP
machines and shared memory. I cant find this documented anywhere.
However I am told that the current-stable 4.1.2 still has issues with
SMP and SHM whereas the CVS version (which built as 4.2.1-dev on my
machine) has resolved this issue.

What is the current status regarding this? Any information that you can
share would be greatly appreciated.

Thanks
Warwick Poole 

-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php




[PHP-DEV] Bug #15362: date(r) returns wrong timezone offset, can cause crash

2002-02-03 Thread warwick

From: [EMAIL PROTECTED]
Operating system: Linux 6.2 and 7.2
PHP version:  4.1.1
PHP Bug Type: Date/time related
Bug description:  date(r) returns wrong timezone offset, can cause crash

I have tested both PHP 4.1.1 and PHP 4.05 and the following occurs for
both.

The date('r') call returns the wrong timezone offset (in my case
+101800) which causes a buffer overflow in datetime.c

The date(Z) call correctly returns the timezone offset number of seconds
(630 in my case).

The undocumented (in the PHP manual anyway) option to strftime('%z')
returns the correct value of +1030.

The timezone abbreviation (CST in my case) is correctly returned with
both the strftime(%Z) and date(T) calls.
  
This will often cause the process to seg fault and die, althought on more
complex pages, this becomes quite consistant.

With the PHP compile option '--enable-debug', the following is reported in
the Apache error log:

---
zend_execute_API.c(274) : Block 0x0813EDA0 status:
zend_variables.c(44) : Actual location (location was relayed)
Beginning:  OK (allocated on datetime.c:331, 32 bytes)
  End:  Overflown (magic=0x2A8F0030 instead of 0x2A8FCC84)
2 byte(s) overflown
---

For PHP 4.1.1 the configure line is:
./configure --with-mysql=/usr/local/mysql --enable-track-vars
--with-apxs=/usr/local/apache/bin/apxs
--with-config-file-path=/usr/local/apache/conf --enable-bcmath --with-zlib
--with-xml --with-gettext --with-imap=../imap --with-mcrypt
--with-ldap=/usr/local --enable-ftp --without-gd --enable-debug

(Will be used for Horde's IMP webmail system)

-- 
Edit bug report at http://bugs.php.net/?id=15362edit=1
-- 
Fixed in CVS:http://bugs.php.net/fix.php?id=15362r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=15362r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=15362r=needtrace
Try newer version:   http://bugs.php.net/fix.php?id=15362r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=15362r=support
Expected behavior:   http://bugs.php.net/fix.php?id=15362r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=15362r=notenoughinfo


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php




[PHP-DEV] Bug #13259: Unsetting a global var inside a function not working (can crash)

2001-09-11 Thread warwick

From: [EMAIL PROTECTED]
Operating system: Linux (Redhat 7.1  6.2)
PHP version:  4.0.6
PHP Bug Type: Reproducible crash
Bug description:  Unsetting a global var inside a function not working (can crash)

In a (bad) block of code I found the HTTP process to crash every time with
the Zend Optimizer (v1.1.0) enabled in PHP 4.0.6.  The same version of Zend
Optimizer does not crash in 4.0.5, however I think this is more a PHP issue
than the Optimizer's.  

Code sample:

?php
$globalVar = Hello world;
clearGlobal();
echo After clear = $globalVar;

function clearGlobal()
{
global $globalVar;
unset ($GLOBALS['globalVar']);
}
?

With or without the Zend Optimizer enabled, the 'echo' statement displays
crap (in both 4.0.5  4.0.6), rather than an empty value.  However, with
the Zend Optimizer enabled it actually causes the HTTP process to crash in
4.0.6. 

My build command for PHP is currently:
./configure  --with-mysql=/usr/local/mysql --enable-track-vars
--with-apxs=/usr/local/apache/bin/apxs
--with-config-file-path=/usr/local/apache/conf --with-zlib

(I have rebuilt PHP without the zlib extension and it makes no
difference)

---
GDB Backtrace:

Starting program: /usr/local/apache-1.3.12/bin/httpd -X

Program received signal SIGSEGV, Segmentation fault.
0x4025dee5 in zend_reverse_table ()
   from /usr/local/apache/libexec/ZendOptimizer.so
(gdb) bt
#0  0x4025dee5 in zend_reverse_table ()
   from /usr/local/apache/libexec/ZendOptimizer.so
#1  0x40264513 in zend_reverse_table ()
   from /usr/local/apache/libexec/ZendOptimizer.so
#2  0x40271b35 in zend_reverse_table ()
   from /usr/local/apache/libexec/ZendOptimizer.so
#3  0x4027501d in zend_oe () from
/usr/local/apache/libexec/ZendOptimizer.so
#4  0x403b7130 in zend_execute_scripts (type=8, file_count=3) at
zend.c:752
#5  0x403c85db in php_execute_script (primary_file=0xb818) at
main.c:1206
#6  0x403c4e86 in apache_php_module_main (r=0x80ef48c,
display_source_mode=0)
at sapi_apache.c:89
#7  0x403c5811 in send_php (r=0x80ef48c, display_source_mode=0,
filename=0x0)
at mod_php4.c:536
#8  0x403c583a in send_parsed_php (r=0x80ef48c) at mod_php4.c:547
#9  0x080542e3 in ap_invoke_handler () at eval.c:41
#10 0x08067819 in process_request_internal () at eval.c:41
#11 0x0806787c in ap_process_request () at eval.c:41
#12 0x0805f11e in child_main () at eval.c:41
#13 0x0805f2ac in make_child () at eval.c:41
#14 0x0805f409 in startup_children () at eval.c:41
#15 0x0805fa36 in standalone_main () at eval.c:41
#16 0x080601c3 in main () at eval.c:41
#17 0x4009a177 in __libc_start_main (main=0x805fe7c main, argc=2, 
ubp_av=0xba3c, init=0x804e864 _init, fini=0x809419c _fini, 
rtld_fini=0x4000e184 _dl_fini, stack_end=0xba34)
at ../sysdeps/generic/libc-start.c:129

-- 
Edit bug report at: http://bugs.php.net/?id=13259edit=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]