You can subscribe to this list here.
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(51) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2005 |
Jan
(31) |
Feb
(8) |
Mar
(51) |
Apr
(27) |
May
(31) |
Jun
(18) |
Jul
(37) |
Aug
(5) |
Sep
|
Oct
(8) |
Nov
(20) |
Dec
(29) |
| 2006 |
Jan
(36) |
Feb
(38) |
Mar
(30) |
Apr
(24) |
May
(29) |
Jun
(8) |
Jul
(13) |
Aug
(28) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Bart V. <bar...@zo...> - 2006-01-10 18:26:52
|
Hello everyone, CVS has been branched. Normal development towards 0.9.4 will continue in head. The branch PHP_5_1 was create for php 5.1 compatibility development. Hans will soon commit the current patch that Hans and Lyle have been working on. This patch is based on a patch I created from the ones Xuefer made a few months ago when php 5.1 was still in development. What is the planning? * A next rc for 0.9.4 is expected in the 6th week of this year. This way I hope to release 0.9.4 before the end of february. * 0.9.5 will be fully dedicated to php 5.1. I have no idea when to expect this one, but I guess this won't be far after 0.9.4 This release will make eA compatible with all php version. The encoder won't be fixed for php 5 or php 5.1. * 0.9.6 try to get the encoder working again for all php version but if this is going to happen is unsure. * 1.0 Get the concurrency bug out of eAccelerator. This is about the biggest issue we are facing at the moment. I hope to get it out of the door before the summer starts. What about the rewrite? This is going to take a while. I think it's best to get the current eA stable and then start working on a new php accelerator with a new code base. When this is ready we will brings at version 2.0 Other stuff that needs to be done? - Improve documentation - Migrate the development process to trac. Sourceforge is getting to unstable and to slow. And a happy new year for everyone! gr, Bart --=20 Bart Vanbrabant <bar...@zo...> PGP fingerprint: 093C BB84 17F6 3AA6 6D5E FC4F 84E1 FED1 E426 64D1 |
|
From: Ramon v. A. <ra...@hy...> - 2006-01-10 11:35:25
|
Hi All,
This is the reproducable test-case for the bug on our environment.
Environment:
Gentoo Linux, apache2.0.54, php-5.1.1 and eaccelerator-0.9.4-rc1 from
the website patched with this patchfile: eaccel-php51-patch-29122005.diff
eaccelerator compiled with following configure:
./configure --enable-eaccelerator=shared
--with-php-config=$PHP_PREFIX/bin/php-config
Testcase reproduced with following settings in php.ini for eaccelerator:
zend_extension=/usr/lib/php5/lib/php/extensions/no-debug-non-zts-20050922/eaccelerator.so
eaccelerator.shm_size="32"
eaccelerator.cache_dir="/var/cache/eaccelerator"
eaccelerator.enable="1"
eaccelerator.optimizer="0"
eaccelerator.debug="1"
eaccelerator.check_mtime="1"
eaccelerator.filter=""
eaccelerator.shm_max="0"
eaccelerator.shm_ttl="0"
eaccelerator.shm_prune_period="0"
eaccelerator.shm_only="0"
eaccelerator.compress="0"
eaccelerator.compress_level="9"
eaccelerator.keys="shm_and_disk"
eaccelerator.sessions="shm_and_disk"
eaccelerator.content="shm_and_disk"
For more info mail me, or contact me on irc.
If replying to the list please CC my collegue boris on this as well:
boris at hyves dot nl
-------- Original Message --------
This is working it outputs 14 as expected.
<?PHP
//require_once('a.php');
abstract class classA {
public static $numColumns = 13;
}
class classb extends classa {
}
$a = 1;
$a = $a + classb::$numColumns;
echo($a);
?>
However if I create a file called a.php containing:
<?PHP
abstract class classA {
public static $numColumns = 13;
}
?>
and I change the above code to
<?PHP
require_once('a.php');
class classb extends classa {
}
$a = 1;
$a = $a + classb::$numColumns;
echo($a);
?>
I get the error:
[Tue Jan 10 12:22:41 2006] [error] [client 82.93.88.107] PHP Fatal
error: Access to undeclared static property: classb::$numColumns in
/var/www/hyves/root/b.php on line 15
Grtz Ramon & Boris
-
mail: ra...@hy...
gsm: +31 (0) 6 48261300
msn: rja...@ho...
www: http://ramon71.hyves.nl
|
|
From: Geisel S. <ge...@4u...> - 2006-01-09 11:10:46
|
Hi people!
The eaccelerator page is down. How I can help you?
Bye!
|
|
From: OpenMacNews <ope...@gm...> - 2006-01-02 21:27:27
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 hi hans, > Yes we are aware of these problems. Neither current CVS HEAD nor eA > 0.9.4-rc1 works with php-5.1.1. We're working on it :) gr8! good to see the project alive-n-well :-) (i'd given up on zend and turck-in-transition a while ago ...) i'll be lurking here while i try to ramp up my site/functions ... if there's anything eAcc-related ne1 here would like bounced around on OSX, please let me know. cheers, richard - -- /"\ \ / ASCII Ribbon Campaign X against HTML email, vCards / \ & micro$oft attachments [GPG] OpenMacNews at gmail dot com fingerprint: 50C9 1C46 2F8F DE42 2EDB D460 95F7 DDBD 3671 08C6 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (Darwin) iEYEAREDAAYFAkO5mowACgkQlffdvTZxCMZuBwCfWZPg5EswNRtEtN+hHK6K/G3L gkMAn3MP56RgCwzFkAmnsW6EfxcgLdwR =oBPM -----END PGP SIGNATURE----- |
|
From: Hans R. <ha...@pa...> - 2006-01-02 21:05:39
|
Yes we are aware of these problems. Neither current CVS HEAD nor eA 0.9.4-rc1 works with php-5.1.1. We're working on it :) Greetings, Hans Rakers OpenMacNews wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: RIPEMD160 > >hi all, > >giving a 1st try at building eAccelerator ... > >i've php511 installed on OSX 10.4.3. yes, i know it's not-yet-fully-compatible ... i'll see what >i can help on this platform. > >co'ing latest eAccelerator head, ./configure's OK, but 'make' fails at: > >/usr/ports/eaccelerator/optimize.c: In function 'compute_live_var': >/usr/ports/eaccelerator/optimize.c:253: error: 'ZEND_UNSET_DIM_OBJ' undeclared (first use in >this function) >/usr/ports/eaccelerator/optimize.c:253: error: (Each undeclared identifier is reported only once >/usr/ports/eaccelerator/optimize.c:253: error: for each function it appears in.) >/usr/ports/eaccelerator/optimize.c:260: error: 'ZEND_JMP_NO_CTOR' undeclared (first use in this >function) >/usr/ports/eaccelerator/optimize.c: In function 'optimize_jmp': >/usr/ports/eaccelerator/optimize.c:1282: error: 'ZEND_JMP_NO_CTOR' undeclared (first use in this >function) >/usr/ports/eaccelerator/optimize.c: In function 'optimize_bb': >/usr/ports/eaccelerator/optimize.c:2446: error: 'ZEND_UNSET_DIM_OBJ' undeclared (first use in >this function) >/usr/ports/eaccelerator/optimize.c: In function 'build_cfg': >/usr/ports/eaccelerator/optimize.c:2724: error: 'ZEND_JMP_NO_CTOR' undeclared (first use in this >function) >/usr/ports/eaccelerator/optimize.c:2843: error: 'ZEND_UNSET_DIM_OBJ' undeclared (first use in >this function) >make: *** [optimize.lo] Error 1 > > >dunno (yet) if this is related to: > > Re: PHP 5.1 compatibility patch > http://sourceforge.net/mailarchive/message.php?msg_id=14092134 > >thoughts/comments? > >cheers, > >richard > >- -- > >/"\ >\ / ASCII Ribbon Campaign > X against HTML email, vCards >/ \ & micro$oft attachments > >[GPG] OpenMacNews at gmail dot com >fingerprint: 50C9 1C46 2F8F DE42 2EDB D460 95F7 DDBD 3671 08C6 >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v1.4.2 (Darwin) > >iEYEAREDAAYFAkO5kmkACgkQlffdvTZxCMYo1ACfY7EaTaEIf8ArrFkGC586kmQo >C/gAnjcCGMSRfkdU/A8sqAcAPmftjb3X >=OIwt >-----END PGP SIGNATURE----- > > > >------------------------------------------------------- >This SF.net email is sponsored by: Splunk Inc. Do you grep through log files >for problems? Stop! Download the new AJAX search engine that makes >searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! >http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click >_______________________________________________ >eAccelerator-developers mailing list >eAc...@li... >https://lists.sourceforge.net/lists/listinfo/eaccelerator-developers > > |
|
From: OpenMacNews <ope...@gm...> - 2006-01-02 20:52:37
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 hi all, giving a 1st try at building eAccelerator ... i've php511 installed on OSX 10.4.3. yes, i know it's not-yet-fully-compatible ... i'll see what i can help on this platform. co'ing latest eAccelerator head, ./configure's OK, but 'make' fails at: /usr/ports/eaccelerator/optimize.c: In function 'compute_live_var': /usr/ports/eaccelerator/optimize.c:253: error: 'ZEND_UNSET_DIM_OBJ' undeclared (first use in this function) /usr/ports/eaccelerator/optimize.c:253: error: (Each undeclared identifier is reported only once /usr/ports/eaccelerator/optimize.c:253: error: for each function it appears in.) /usr/ports/eaccelerator/optimize.c:260: error: 'ZEND_JMP_NO_CTOR' undeclared (first use in this function) /usr/ports/eaccelerator/optimize.c: In function 'optimize_jmp': /usr/ports/eaccelerator/optimize.c:1282: error: 'ZEND_JMP_NO_CTOR' undeclared (first use in this function) /usr/ports/eaccelerator/optimize.c: In function 'optimize_bb': /usr/ports/eaccelerator/optimize.c:2446: error: 'ZEND_UNSET_DIM_OBJ' undeclared (first use in this function) /usr/ports/eaccelerator/optimize.c: In function 'build_cfg': /usr/ports/eaccelerator/optimize.c:2724: error: 'ZEND_JMP_NO_CTOR' undeclared (first use in this function) /usr/ports/eaccelerator/optimize.c:2843: error: 'ZEND_UNSET_DIM_OBJ' undeclared (first use in this function) make: *** [optimize.lo] Error 1 dunno (yet) if this is related to: Re: PHP 5.1 compatibility patch http://sourceforge.net/mailarchive/message.php?msg_id=14092134 thoughts/comments? cheers, richard - -- /"\ \ / ASCII Ribbon Campaign X against HTML email, vCards / \ & micro$oft attachments [GPG] OpenMacNews at gmail dot com fingerprint: 50C9 1C46 2F8F DE42 2EDB D460 95F7 DDBD 3671 08C6 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (Darwin) iEYEAREDAAYFAkO5kmkACgkQlffdvTZxCMYo1ACfY7EaTaEIf8ArrFkGC586kmQo C/gAnjcCGMSRfkdU/A8sqAcAPmftjb3X =OIwt -----END PGP SIGNATURE----- |
|
From: <rue...@to...> - 2005-12-27 12:20:37
|
eac...@li... <> wrote on :
> When you get here, please type bt. It will generate a backtrace.
Starting program: /usr/sbin/httpd -X
Reading symbols from shared object read from target memory...done.
Loaded system supplied DSO at 0xffffe000
[Thread debugging using libthread_db enabled]
[New Thread -1213397312 (LWP 11118)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1213397312 (LWP 11118)]
_efree (ptr=3D0x0) at /usr/src/php-5.1.1/Zend/zend_alloc.c:286
286 CALCULATE_REAL_SIZE_AND_CACHE_INDEX(p->size);
(gdb) bt
#0 _efree (ptr=3D0x0) at /usr/src/php-5.1.1/Zend/zend_alloc.c:286
#1 0xb7900d0b in destroy_zend_class (pce=3D0x0) at
/usr/src/php-5.1.1/Zend/zend_opcode.c:168
#2 0xb7910ca5 in zend_hash_del_key_or_index (ht=3D0x825de00, =
arKey=3DVariable
"arKey" is not available.
) at /usr/src/php-5.1.1/Zend/zend_hash.c:490
#3 0xb791118c in zend_hash_reverse_apply (ht=3D0x825de00,
apply_func=3D0xb78fd504 <is_not_internal_class>)
at /usr/src/php-5.1.1/Zend/zend_hash.c:736
#4 0xb78fe051 in shutdown_executor () at
/usr/src/php-5.1.1/Zend/zend_execute_API.c:264
#5 0xb79085f8 in zend_deactivate () at =
/usr/src/php-5.1.1/Zend/zend.c:835
#6 0xb78d4ca4 in php_request_shutdown (dummy=3D0x0) at
/usr/src/php-5.1.1/main/main.c:1268
#7 0xb798a38a in php_handler (r=3D0x8348dd0) at
/usr/src/php-5.1.1/sapi/apache2handler/sapi_apache2.c:443
#8 0x080676ce in ap_run_handler (r=3D0x8348dd0) at config.c:152
#9 0x08067a46 in ap_invoke_handler (r=3D0x8348dd0) at config.c:364
#10 0x08065199 in ap_process_request (r=3D0x8348dd0) at =
http_request.c:249
#11 0x08060bd9 in ap_process_http_connection (c=3D0x833e970) at
http_core.c:251
#12 0x0806feda in ap_run_process_connection (c=3D0x833e970) at =
connection.c:43
#13 0x08065e6e in child_main (child_num_arg=3DVariable "child_num_arg" =
is not
available.
) at prefork.c:610
#14 0x08066021 in make_child (s=3D0x809ce58, slot=3D0) at prefork.c:650
#15 0x080660ea in startup_children (number_to_start=3D5) at =
prefork.c:722
#16 0x080668ac in ap_mpm_run (_pconf=3D0x809b0a8, plog=3D0x80c5150, =
s=3D0x809ce58)
at prefork.c:941
#17 0x0806bb7f in main (argc=3D2, argv=3D0xbf824e44) at main.c:618
--=20
Mit freundlichem Gru=DF
S=F6nke Ruempler
Technik
top concepts Internetmarketing GmbH
Am Steinkamp 7 - D-21684 Stade - Germany
------------------------------------------------------------
http://www.topconcepts.de Tel. +49 1805 9977 501*
mail: rue...@to... Fax. +49 1805 9977 502*
------------------------------------------------------------
SMS Versand ab 9.9 Cent: http://sms-gw.topconcepts.de
------------------------------------------------------------
Handelsregister: AG Tostedt HRB 100687 - UstId: DE 213645563
------------------------------------------------------------
*) EUR 0,12/Min. (CNS24)
------------------------------------------------------------
--> http://efn.no/html-bad.html
--> http://learn.to/quote
|
|
From: Bart V. <bar...@zo...> - 2005-12-27 12:16:56
|
Hans Rakers wrote: > Bart Vanbrabant wrote: > >> S=F6nke Ruempler wrote: >> =20 >> >>> eac...@li... <> wrote on : >>> >>> =20 >>> =20 >>>> See http://httpd.apache.org/dev/debugging.html >>>> >>>> The way i do it is with gdb, running apache in single thread >>>> mode (run >>>> -X in gdb) >>>> >>>> You will probably need to isolate your development/debugging >>>> work on a >>>> webserver that does not serve any other reqs at that time. >>>> =20 >>> Thx for instructions. >>> >>> Here the first output: >>> >>> (gdb) file /usr/sbin/httpd >>> Reading symbols from /usr/sbin/httpd...done. >>> Using host libthread_db library "/lib/libthread_db.so.1". >>> (gdb) set args -X >>> (gdb) run >>> Starting program: /usr/sbin/httpd -X >>> Reading symbols from shared object read from target memory...done. >>> Loaded system supplied DSO at 0xffffe000 >>> [Thread debugging using libthread_db enabled] >>> [New Thread -1213249856 (LWP 18670)] >>> >>> Program received signal SIGSEGV, Segmentation fault. >>> [Switching to Thread -1213249856 (LWP 18670)] >>> _efree (ptr=3D0x0) at /usr/src/php-5.1.1/Zend/zend_alloc.c:286 >>> 286 CALCULATE_REAL_SIZE_AND_CACHE_INDEX(p->size); >>> (gdb) >>> =20 >>> =20 >> >> When you get here, please type bt. It will generate a backtrace. >> >> g, >> >> Bart >> >> =20 >> > > Its exactly the same point where it crashes here. I already have a > backtrace of this particular case. This one is from > eaccelerator.php?dump=3D with Smarty classes in the cache. Looks to me > like the class entries get screwed somewhere. > > > Program received signal SIGSEGV, Segmentation fault. > _efree (ptr=3D0x0) at /usr/src/php-5.1.1/Zend/zend_alloc.c:286 > 286 CALCULATE_REAL_SIZE_AND_CACHE_INDEX(p->size); > (gdb) bt > #0 _efree (ptr=3D0x0) at /usr/src/php-5.1.1/Zend/zend_alloc.c:286 > #1 0xb7429450 in dump_op_array (p=3D0xb640c8b8) at > /usr/src/eaccelerator-cvs/eaccelerator/webui.c:801 > #2 0xb742afb7 in eaccelerator_dump_all () at > /usr/src/eaccelerator-cvs/eaccelerator/webui.c:1173 > #3 0xb742c534 in zif_eaccelerator (ht=3D0, return_value=3D0x81b1854, > return_value_ptr=3D0x0, this_ptr=3D0x0, return_value_used=3D0) at > /usr/src/eaccelerator-cvs/eaccelerator/webui.c:1651 > #4 0xb7b68b33 in zend_do_fcall_common_helper_SPEC > (execute_data=3D0xbfaa4dc0) at zend_vm_execute.h:188 > #5 0xb7b68389 in execute (op_array=3D0x81b16a4) at zend_vm_execute.h:8= 8 > #6 0xb7b43f7c in zend_execute_scripts (type=3D8, retval=3D0x0, > file_count=3D3) at /usr/src/php-5.1.1/Zend/zend.c:1090 > #7 0xb7b0977f in php_execute_script (primary_file=3D0xbfaa7140) at > /usr/src/php-5.1.1/main/main.c:1704 > #8 0xb7bc56be in apache_php_module_main (r=3D0x81a708c, > display_source_mode=3D0) at /usr/src/php-5.1.1/sapi/apache/sapi_apache.= c:53 > #9 0xb7bc6237 in send_php (r=3D0x81a708c, display_source_mode=3D0, > filename=3D0x0) at /usr/src/php-5.1.1/sapi/apache/mod_php5.c:644 > #10 0xb7bc63f2 in send_parsed_php (r=3D0x81a708c) at > /usr/src/php-5.1.1/sapi/apache/mod_php5.c:659 > #11 0x0805411f in ap_invoke_handler () > #12 0x080691c7 in process_request_internal () > #13 0x08069226 in ap_process_request () > #14 0x08060236 in child_main () > #15 0x080603de in make_child () > #16 0x08060544 in startup_children () > #17 0x08060be4 in standalone_main () > #18 0x08061402 in main () Maybe this piece of code is usefull. I got it from segv a while ago. It's quite hacky and it doesn't work with php5.1 anymore. http://zoeloelip.be/ea/dprint.c Take a look at the last function: dprint_compiler_retval It print's out the op_array and the function hashtable and class hashtabl= e. It does this in the way vimdiff can show very nice. You can print out = these variables after compilation, when it's returned from cache, after o= ptimisation. This way you can track what parts are changed by eAccelerato= r. I hope this helps. g, Bart --=20 Bart Vanbrabant <bar...@zo...> PGP fingerprint: 093C BB84 17F6 3AA6 6D5E FC4F 84E1 FED1 E426 64D1 |
|
From: Hans R. <ha...@pa...> - 2005-12-27 11:56:10
|
Bart Vanbrabant wrote: >Sönke Ruempler wrote: > > >>eac...@li... <> wrote on : >> >> >> >> >>>See http://httpd.apache.org/dev/debugging.html >>> >>>The way i do it is with gdb, running apache in single thread >>>mode (run >>>-X in gdb) >>> >>>You will probably need to isolate your development/debugging >>>work on a >>>webserver that does not serve any other reqs at that time. >>> >>> >>> >>Thx for instructions. >> >>Here the first output: >> >>(gdb) file /usr/sbin/httpd >>Reading symbols from /usr/sbin/httpd...done. >>Using host libthread_db library "/lib/libthread_db.so.1". >>(gdb) set args -X >>(gdb) run >>Starting program: /usr/sbin/httpd -X >>Reading symbols from shared object read from target memory...done. >>Loaded system supplied DSO at 0xffffe000 >>[Thread debugging using libthread_db enabled] >>[New Thread -1213249856 (LWP 18670)] >> >>Program received signal SIGSEGV, Segmentation fault. >>[Switching to Thread -1213249856 (LWP 18670)] >>_efree (ptr=0x0) at /usr/src/php-5.1.1/Zend/zend_alloc.c:286 >>286 CALCULATE_REAL_SIZE_AND_CACHE_INDEX(p->size); >>(gdb) >> >> >> > >When you get here, please type bt. It will generate a backtrace. > >g, > >Bart > > > Its exactly the same point where it crashes here. I already have a backtrace of this particular case. This one is from eaccelerator.php?dump= with Smarty classes in the cache. Looks to me like the class entries get screwed somewhere. Program received signal SIGSEGV, Segmentation fault. _efree (ptr=0x0) at /usr/src/php-5.1.1/Zend/zend_alloc.c:286 286 CALCULATE_REAL_SIZE_AND_CACHE_INDEX(p->size); (gdb) bt #0 _efree (ptr=0x0) at /usr/src/php-5.1.1/Zend/zend_alloc.c:286 #1 0xb7429450 in dump_op_array (p=0xb640c8b8) at /usr/src/eaccelerator-cvs/eaccelerator/webui.c:801 #2 0xb742afb7 in eaccelerator_dump_all () at /usr/src/eaccelerator-cvs/eaccelerator/webui.c:1173 #3 0xb742c534 in zif_eaccelerator (ht=0, return_value=0x81b1854, return_value_ptr=0x0, this_ptr=0x0, return_value_used=0) at /usr/src/eaccelerator-cvs/eaccelerator/webui.c:1651 #4 0xb7b68b33 in zend_do_fcall_common_helper_SPEC (execute_data=0xbfaa4dc0) at zend_vm_execute.h:188 #5 0xb7b68389 in execute (op_array=0x81b16a4) at zend_vm_execute.h:88 #6 0xb7b43f7c in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/src/php-5.1.1/Zend/zend.c:1090 #7 0xb7b0977f in php_execute_script (primary_file=0xbfaa7140) at /usr/src/php-5.1.1/main/main.c:1704 #8 0xb7bc56be in apache_php_module_main (r=0x81a708c, display_source_mode=0) at /usr/src/php-5.1.1/sapi/apache/sapi_apache.c:53 #9 0xb7bc6237 in send_php (r=0x81a708c, display_source_mode=0, filename=0x0) at /usr/src/php-5.1.1/sapi/apache/mod_php5.c:644 #10 0xb7bc63f2 in send_parsed_php (r=0x81a708c) at /usr/src/php-5.1.1/sapi/apache/mod_php5.c:659 #11 0x0805411f in ap_invoke_handler () #12 0x080691c7 in process_request_internal () #13 0x08069226 in ap_process_request () #14 0x08060236 in child_main () #15 0x080603de in make_child () #16 0x08060544 in startup_children () #17 0x08060be4 in standalone_main () #18 0x08061402 in main () |
|
From: Bart V. <bar...@zo...> - 2005-12-27 11:46:38
|
S=F6nke Ruempler wrote: > eac...@li... <> wrote on : > > =20 >> See http://httpd.apache.org/dev/debugging.html >> >> The way i do it is with gdb, running apache in single thread >> mode (run >> -X in gdb) >> >> You will probably need to isolate your development/debugging >> work on a >> webserver that does not serve any other reqs at that time. >> =20 > > Thx for instructions. > > Here the first output: > > (gdb) file /usr/sbin/httpd > Reading symbols from /usr/sbin/httpd...done. > Using host libthread_db library "/lib/libthread_db.so.1". > (gdb) set args -X > (gdb) run > Starting program: /usr/sbin/httpd -X > Reading symbols from shared object read from target memory...done. > Loaded system supplied DSO at 0xffffe000 > [Thread debugging using libthread_db enabled] > [New Thread -1213249856 (LWP 18670)] > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread -1213249856 (LWP 18670)] > _efree (ptr=3D0x0) at /usr/src/php-5.1.1/Zend/zend_alloc.c:286 > 286 CALCULATE_REAL_SIZE_AND_CACHE_INDEX(p->size); > (gdb) > =20 When you get here, please type bt. It will generate a backtrace. g, Bart --=20 Bart Vanbrabant <bar...@zo...> PGP fingerprint: 093C BB84 17F6 3AA6 6D5E FC4F 84E1 FED1 E426 64D1 |
|
From: <rue...@to...> - 2005-12-27 11:13:30
|
eac...@li... <> wrote on : > See http://httpd.apache.org/dev/debugging.html > > The way i do it is with gdb, running apache in single thread > mode (run > -X in gdb) > > You will probably need to isolate your development/debugging > work on a > webserver that does not serve any other reqs at that time. Thx for instructions. Here the first output: (gdb) file /usr/sbin/httpd Reading symbols from /usr/sbin/httpd...done. Using host libthread_db library "/lib/libthread_db.so.1". (gdb) set args -X (gdb) run Starting program: /usr/sbin/httpd -X Reading symbols from shared object read from target memory...done. Loaded system supplied DSO at 0xffffe000 [Thread debugging using libthread_db enabled] [New Thread -1213249856 (LWP 18670)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1213249856 (LWP 18670)] _efree (ptr=0x0) at /usr/src/php-5.1.1/Zend/zend_alloc.c:286 286 CALCULATE_REAL_SIZE_AND_CACHE_INDEX(p->size); (gdb) > The segfault on restore problem is one of the problems i have > remaining. Simple scripts work fine, even phpMyAdmin works, but > complex class usage/OOP constructions still seem to fail on restore. Yep - I've experienced exactly the same here. > Could you please test if the problem persists with the > optimizer turned off? The optimizer is turned off as well as sessions etc. |
|
From: Hans R. <ha...@pa...> - 2005-12-27 10:15:25
|
Hi Sönke, See http://httpd.apache.org/dev/debugging.html The way i do it is with gdb, running apache in single thread mode (run -X in gdb) You will probably need to isolate your development/debugging work on a webserver that does not serve any other reqs at that time. The segfault on restore problem is one of the problems i have remaining. Simple scripts work fine, even phpMyAdmin works, but complex class usage/OOP constructions still seem to fail on restore. Could you please test if the problem persists with the optimizer turned off? Thanks for your effort, Hans Sönke Ruempler wrote: >Hi Hans, > >eac...@li... <> wrote on : > > > >>I've done some work on it in collaboration with Bart vanBrabant aka >>zoeloelip. There is a preliminary patch at >>http://home.parse.nl/~hans/eaccel/ >> >>Note that this is a work in progress. Your milage may vary. >> >>Please report your succes/failure/suggestions. >> >> > >Thx for your work! Yeah I couldn't wait to try the patch. ;) > >Caching seems to work: > >eAccelerator >eAccelerator support enabled >Version 0.9.4-rc1 >Caching Enabled true >Optimizer Enabled false >Memory Size 33,554,392 Bytes >Memory Available 15,292,320 Bytes >Memory Allocated 18,262,072 Bytes >Cached Scripts 289 >Removed Scripts 0 >Cached Keys 0 > >Directive Local Value Master Value >eaccelerator.cache_dir /tmp/eaccelerator /tmp/eaccelerator >eaccelerator.check_mtime 1 1 >eaccelerator.compress 1 1 >eaccelerator.compress_level 0 0 >eaccelerator.debug 0 0 >eaccelerator.enable 1 1 >eaccelerator.filter no value no value >eaccelerator.keys shm_and_disk shm_and_disk >eaccelerator.log_file no value no value >eaccelerator.name_space no value no value >eaccelerator.optimizer 0 0 >eaccelerator.shm_max 0 0 >eaccelerator.shm_only 0 0 >eaccelerator.shm_prune_period 0 0 >eaccelerator.shm_size 0 0 >eaccelerator.shm_ttl 0 0 > > >But restoring and executing the bytecode (as doing a second request to a >page) makes the apache (2.0) segfault. > >I tried this primarily with mediawiki software. Is there a way to generate >backtraces like gdb in apache? Or how can we help you for further >developement / bugfixing? > >soenke > > > >------------------------------------------------------- >This SF.net email is sponsored by: Splunk Inc. Do you grep through log files >for problems? Stop! Download the new AJAX search engine that makes >searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! >http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click >_______________________________________________ >eAccelerator-developers mailing list >eAc...@li... >https://lists.sourceforge.net/lists/listinfo/eaccelerator-developers > > |
|
From: <rue...@to...> - 2005-12-27 10:06:00
|
Hi Hans, eac...@li... <> wrote on : > I've done some work on it in collaboration with Bart vanBrabant aka > zoeloelip. There is a preliminary patch at > http://home.parse.nl/~hans/eaccel/ > > Note that this is a work in progress. Your milage may vary. > > Please report your succes/failure/suggestions. Thx for your work! Yeah I couldn't wait to try the patch. ;) Caching seems to work: eAccelerator eAccelerator support enabled Version 0.9.4-rc1 Caching Enabled true Optimizer Enabled false Memory Size 33,554,392 Bytes Memory Available 15,292,320 Bytes Memory Allocated 18,262,072 Bytes Cached Scripts 289 Removed Scripts 0 Cached Keys 0 Directive Local Value Master Value eaccelerator.cache_dir /tmp/eaccelerator /tmp/eaccelerator eaccelerator.check_mtime 1 1 eaccelerator.compress 1 1 eaccelerator.compress_level 0 0 eaccelerator.debug 0 0 eaccelerator.enable 1 1 eaccelerator.filter no value no value eaccelerator.keys shm_and_disk shm_and_disk eaccelerator.log_file no value no value eaccelerator.name_space no value no value eaccelerator.optimizer 0 0 eaccelerator.shm_max 0 0 eaccelerator.shm_only 0 0 eaccelerator.shm_prune_period 0 0 eaccelerator.shm_size 0 0 eaccelerator.shm_ttl 0 0 But restoring and executing the bytecode (as doing a second request to a page) makes the apache (2.0) segfault. I tried this primarily with mediawiki software. Is there a way to generate backtraces like gdb in apache? Or how can we help you for further developement / bugfixing? soenke |
|
From: Hans R. <ha...@pa...> - 2005-12-27 09:48:03
|
Hello, I've done some work on it in collaboration with Bart vanBrabant aka zoeloelip. There is a preliminary patch at http://home.parse.nl/~hans/eaccel/ Note that this is a work in progress. Your milage may vary. Please report your succes/failure/suggestions. Greetings, Hans Rakers Sönke Ruempler wrote: >Hi, > >I hope you all had a few happy und relaxing christmas holidays :) > >Just some PITA question: did anyone proceed with the bugfixing of the >segfaults? I'd be proud to test and help hunting. ;) > >-- > >soenke > > > >------------------------------------------------------- >This SF.net email is sponsored by: Splunk Inc. Do you grep through log files >for problems? Stop! Download the new AJAX search engine that makes >searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! >http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click >_______________________________________________ >eAccelerator-developers mailing list >eAc...@li... >https://lists.sourceforge.net/lists/listinfo/eaccelerator-developers > > |
|
From: <rue...@to...> - 2005-12-27 09:17:11
|
Hi, I hope you all had a few happy und relaxing christmas holidays :) Just some PITA question: did anyone proceed with the bugfixing of the segfaults? I'd be proud to test and help hunting. ;) -- soenke |
|
From: Hans R. <ha...@pa...> - 2005-12-13 22:37:02
|
Hi John, Previously posted patches were mostly incomplete attempts at 5.1 compatibility. I've been working on it for the past few days and have made some progress. Simple scripts work and get cached and restored from cache properly now, but big things like phpMyAdmin still result in segfaults and the like. But i do think the biggest hurdle has been taken and it just needs some small fixes. The code needs some cleanup though, since it's swarming with debug output :) I have mailed Bart vanBrabant about my progress last night but i havent heard from him since. I think he's busy (he told me before that he'd be rather busy with his studies). I'm willing to share my progress with the list once i have some stability and i've done some cleaning up! Greetings, Hans Rakers John Reuning wrote: >I'm new to the list and just read the thread on efforts to get >eaccelerator to run with php 5.1. Unfortunately, sf.net's mailman ate >the attachments and truncated the posts in the list archives. If >someone has the patch(es) and can email them to me, I'd be grateful. I >have a day or two to work on php 5.1 support if anyone's interested. > >Thanks, > >-jrr > > >------------------------------------------------------- >This SF.net email is sponsored by: Splunk Inc. Do you grep through log files >for problems? Stop! Download the new AJAX search engine that makes >searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! >http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click >_______________________________________________ >eAccelerator-developers mailing list >eAc...@li... >https://lists.sourceforge.net/lists/listinfo/eaccelerator-developers > > |
|
From: John R. <jre...@lu...> - 2005-12-13 19:51:41
|
I'm new to the list and just read the thread on efforts to get eaccelerator to run with php 5.1. Unfortunately, sf.net's mailman ate the attachments and truncated the posts in the list archives. If someone has the patch(es) and can email them to me, I'd be grateful. I have a day or two to work on php 5.1 support if anyone's interested. Thanks, -jrr |
|
From: Denny R. <den...@si...> - 2005-12-09 16:33:38
|
hi folks, i've received a "thank you"-email from www.moviemaze.de markus thanks eaccelerator - the "old" servers runs now a little smoother ;-) greetings from munich, bavarian denny -------- Original Message -------- Subject: eAccelerator im Einsatz Date: Thu, 08 Dec 2005 23:18:59 +0100 From: Markus Ostertag <mar...@mo...> Reply-To: mar...@mo... To: dr...@us... Hi, ich wollte Dir und dem Team für die gute Arbeit an eAccelerator danken. Wir von MovieMaze.de setzen seit einigen Wochen nun auch eAccelerator auf unseren 3 Linux-Servern mit Apache 2 ein. Mit 4 Mio. PIs im Monat musste der etwas altersschwache Webserver Einiges durch machen, doch die CPU-Last ging dank Euch enorm zurück! Gruß Markus -- ---------------------------------------------- Markus Ostertag eMail: mar...@mo... http://www.moviemaze.de ---------------------------------------------- |
|
From: Hans R. <ha...@pa...> - 2005-12-07 14:22:05
|
I'm running eA 0.9.3 and ZO 2.5.10a on apache2/php-4.4.0 on a bunch of loadbalanced production boxes, which works like a charm! Just remember to put the ZO stuff after eA in your php.ini. Greets, Hans Rakers Olivier Mueller wrote: >Hello, > >Just wondering if anybody around is using eaccelerator on production >servers where zend optimizer is also active? Is it still stable? >(I'd need the zend part for encoded files...). > >regards, >Olivier > >PS: eA is great :) > > > >------------------------------------------------------- >This SF.net email is sponsored by: Splunk Inc. Do you grep through log files >for problems? Stop! Download the new AJAX search engine that makes >searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! >http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click >_______________________________________________ >eAccelerator-developers mailing list >eAc...@li... >https://lists.sourceforge.net/lists/listinfo/eaccelerator-developers > > |
|
From: Olivier M. <om-...@om...> - 2005-12-07 14:16:11
|
Hello, Just wondering if anybody around is using eaccelerator on production servers where zend optimizer is also active? Is it still stable? (I'd need the zend part for encoded files...). regards, Olivier PS: eA is great :) |
|
From: Yvan T. <yva...@m4...> - 2005-12-06 11:52:59
|
> I've found a memory allocation bug with a script from me. Maybe some of > the error other people get are due to this bug. But I'm not shure. > Always make shure when you test, that you remove the on disk cache files > everytime you test a new version. What about the in-memory cache ? Perhaps there's a problem (see my previous mail) when I just restart Apache (doing "restart" and not "stop and start"). I've got nothing on disk and it seems the problem is a bad cache of the first opcode until I clean/clear the cache (in-memory, because shm_only is 1). Regards, Yvan. |
|
From: <rue...@to...> - 2005-12-06 11:34:37
|
Hi, eac...@li... <> wrote on : > I've found a memory allocation bug with a script from me. > Maybe some of > the error other people get are due to this bug. But I'm not shure. > Always make shure when you test, that you remove the on disk cache > files everytime you test a new version. Yeah, only SHM is used, no optimizer, no compression, just memory caching. |
|
From: Bart V. <bar...@zo...> - 2005-12-06 11:19:05
|
Bart Vanbrabant wrote: > Bart Vanbrabant wrote: > =20 >> Hello, >> >> There are indeed quite some pieces missing in your patch. I've attache= d >> the patch I've been working on. It's not stable either. >> It's based on a patch from about a half year old when php5.1 was still= >> in alpha state and the eA code wasn't refactored yet. >> >> cheers, >> >> Bart >> >> =20 >> =20 > By the way. When you disable the optimizer this patch does work. > > =20 I've found a memory allocation bug with a script from me. Maybe some of the error other people get are due to this bug. But I'm not shure. Always make shure when you test, that you remove the on disk cache files everytime you test a new version. Cheers, Bart --=20 Bart Vanbrabant <bar...@zo...> PGP fingerprint: 093C BB84 17F6 3AA6 6D5E FC4F 84E1 FED1 E426 64D1 |
|
From: Yvan T. <yva...@m4...> - 2005-12-06 11:10:40
|
Hello Bart, I've just tried your patch against the current CVS version (ok, the = 22-nov's one ;-) It's very strange : - if the optimizer is on, it fails (as expected, so it's not a problem, = I disable it) - when I launch a script, the first execution is OK (as the opcode it = stored in the cache, and it's been compiled from the real source). The second execution dies with seg fault, and so on for the next executions. - but, when I use the Clear button in the "eaccelerator()" output in a = php file (which shows the state of EA), then the script is put out of the = cache, I run it (first time so it must be ok), it's ok, second time : no seg = fault !! And no more seg faults... I can't really understand this... I've disabled the compression option = too (no effect it seems). HTH, Yvan. -----Message d'origine----- De=A0: eac...@li... [mailto:eac...@li...] De la part = de Bart Vanbrabant Envoy=E9=A0: mardi 6 d=E9cembre 2005 11:14 =C0=A0: eac...@li... Objet=A0: Re: [eAccelerator-developers] PHP 5.1 compatibility patch Bart Vanbrabant wrote: > Hello, > > There are indeed quite some pieces missing in your patch. I've = attached > the patch I've been working on. It's not stable either. > It's based on a patch from about a half year old when php5.1 was still > in alpha state and the eA code wasn't refactored yet. > > cheers, > > Bart > > =20 By the way. When you disable the optimizer this patch does work. --=20 Bart Vanbrabant <bar...@zo...> PGP fingerprint: 093C BB84 17F6 3AA6 6D5E FC4F 84E1 FED1 E426 64D1 |
|
From: <rue...@to...> - 2005-12-06 11:04:15
|
Hi Bart, eac...@li... <> wrote on : > By the way. When you disable the optimizer this patch does work. Nice to hear that there is some work on PHP 5.1 Support. Still getting segfaults: [Tue Dec 06 11:56:49 2005] [notice] Apache/2.0.54 (Unix) PHP/5.1.1 configured -- resuming normal operations Going to compile!Going to compile!Going to compile!Going to compile!Going to compile!Going to compile!Going to compile!Going to compile!Going to compile!Goin Going to compile!Going to compile!Going to compile!Going to compile![Tue Dec 06 11:57:02 2005] [notice] child pid 11903 exit signal Segmentation fault (11) Going to compile![Tue Dec 06 11:57:08 2005] [notice] child pid 11904 exit signal Segmentation fault (11) [Tue Dec 06 11:57:49 2005] [notice] caught SIGTERM, shutting down [Tue Dec 06 11:57:49 2005] [warn] module php5_module is already loaded, skipping [Tue Dec 06 11:57:49 2005] [notice] Apache/2.0.54 (Unix) PHP/5.1.1 configured -- resuming normal operations Going to compile! [Tue Dec 06 11:58:20 2005] [notice] caught SIGTERM, shutting down [Tue Dec 06 11:58:21 2005] [warn] module php5_module is already loaded, skipping [Tue Dec 06 11:58:21 2005] [notice] Apache/2.0.54 (Unix) PHP/5.1.1 configured -- resuming normal operations Going to compile! Going to compile!Going to compile!Going to compile!Going to compile![Tue Dec 06 11:58:35 2005] [notice] child pid 12005 exit signal Segmentation fault (11) Going to compile! [Tue Dec 06 11:58:38 2005] [notice] child pid 12006 exit signal Segmentation fault (11) [Tue Dec 06 11:58:57 2005] [notice] SIGHUP received. Attempting to restart If you need more debug information, just drop me an e-mail. -- soenke |